Anteo Group's first edition of Anteo Java News, Anteo Group's Newsletter for the Java Professional, was a huge success! We appreciate and welcome all of your comments and submissions as we are tailoring the newsletter for you. Please send any comments and/or submissions for future articles to Anteo Group Marketing. To receive Anteo Java News by email, contact us.

Thanks and enjoy!

Supporting Applications Using Service Oriented Architectures
By: John Neal

Industry Problems

The general problem seen in the large enterprise systems in existence today can be simplified by looking at how they are currently designed. Distributed systems are really too difficult and static. The average development teams connect the pieces together mostly be shear will and effort and rarely take the time on how to utilize their existing platforms more efficiently. They look mostly on how to connect the dots, using methods such as RMI and maybe a smattering of web services, rather on how to service the changing environment, how to better utilize services and administer. Distributed applications become unusable when they crash or change location, and the average developer does not take into account on how to redistribute or work around the network difficulties when locations change.

What We Need

What we need to solve this problem is a new generation of platforms designed to support these distributed and changing applications. We want to first take a generic approach to supporting these systems by introducing application and content based services. We next need to look to open source and third party approaches such as found in the J2EE and open source projects, i.e., frameworks such as struts and Java Server Faces, web services such as SAAJ and JAX-RPC and the like. We also have to go one step further and look for an introduction of network based services to support our underlying J2EE infrastructure.

Service Delivery Components

The following diagram outlines the different components needed to provide a dynamic service delivery framework based on J2EE standards.

Figure 1

Inventory Management

The Inventory Manager stores the service provider's current inventory of resources (physical, logical and virtual). It includes networking equipment, site information, network clouds, servers, etc. This information is required by the Service Delivery infrastructure to understand what resources are available to support customer requests. The Planning & Development tools also use inventory information to identify available capacity and resources used for network and service planning. Additionally, the Service Assurance systems rely on an accurate Inventory database to localize faults, identify impacts, re-provision networks and elements for service restoration and enable accurate access to network information for field technicians.

Configuration Management

A Configuration Management system is needed for management and maintenance of hardware/software configurations, topology and logical resources in the network (retrieval of the configuration and status of the network elements). The system has the ability to identify changes to the network and services as a result of changes in configuration. The configuration information is used by inventory management applications to track individual pieces of equipment and related data as a provisioning interface. Networks, elements and services are provisioned based on their configuration data.

Workflow Management

Workflow has its foundation in the idea that business processes are actually sets of tasks done in a prescribed order that incorporate information from various sources. Workflow Management systems concentrate on managing the flow of information as it is processed, shared, manipulated, and compiled. This implementation of workflow is primarily concerned with automating existing operations. The Workflow tool is responsible for identifying, tracking and optimizing all processes necessary for the planning, development, delivery and assurance of the networks and services. Real-time interfaces with other network management systems ensure accuracy of statuses and minimize time required for process execution.

Design & Assign

The function of Design & Assign is to reserve the necessary network resources (physical and logical) that are needed to provision/activate a service. This would include reserving physical circuit components such as ports on a router, circuit channels, etc. This also includes Design & Assign resources from application services and Policy Management (e.g. dynamic PDP context allocation) and Mobile-IP assignments. Design & Assign functions require real-time and accurate inventory, configuration and capacity information to make the necessary resource reservations.

Service Delivery Plane

The Service Delivery Plane serves as the communications plane for all service delivery activities and data flows. This may be based on JINI or EJB/RMI, and may utilize web services such as JAX-RPC and JAXB for delivering information between system boundaries. The plane functions as a common messaging bus for exchange of data and information used by the various service delivery systems. The plane also provides the necessary interfaces with network management systems outside the service delivery infrastructure.

Network Provisioning & Activation

The Activation and Provisioning process generates the actual commands required to put the service elements into production. It receives the resource assignments from the Design/Assign function and provides the appropriate commands to the involved network elements, either directly or through an element management system. Configuration information is used to provision the elements for the enablement of appropriate services.

GIS (Georgraphic Information System) / Topology

The GIS/Topology tool allows various network management systems (such as Inventory, Fault, etc.) to overlay network and element information (such as inventory locations, alarms, etc.) with geographic and topological maps. These graphical views further aid in the planning, development, delivery and assurance of the networks and services.

Auto-Discovery

The Auto-Discovery tool provides a mechanism to identify what and when new resources, elements and configurations are added to the network, and can be implemented using JINI based solutions. The discovery of this information is reconciled with the data stored in the Inventory and Configuration systems to synchronize and maintain accurate data stores. Auto-Discovery and Reconciliation are critical to ensuring that services are delivered efficiently and properly.

In the next issue of Anteo Java News, Neal provides us with a real world example of "Supporting Applications Using Service Oriented Architectures."

Output Artifact and Build Management with Maven
By: Matthew Daniel

In the "Dark Ages" of Java development, software engineers would use makefiles to control their build process and manage their dependencies. Ant, the current reigning king of Java build management, even proclaims itself to be "Make, but without Make's wrinkles." There are times to use makefiles, there are times to use Ant and there are times to tackle the build and artifact management problem with a more structured approach. This article is about the latter of these.

Herein, we'll cover what Maven is, what problems Maven is designed to solve and why it represents the pinnacle of build and artifact management tools. This will not be a Maven tutorial, so you should definitely visit Maven's website at http://maven.apache.org/ to learn the finer details of Maven.

The Java application, Maven, provides a safe, up-to-date and repeatable environment in which a build process may run. While it is written in Java, and Java-centric in its goals, it is possible to manage non-Java projects using Maven as well. Its website and document generation tools alone elevate it above any home-grown tool you may be using now. Maven leverages Ant and expands on Ant's build configuration system. Therefore, if you are familiar with Ant's "build.xml" then you are equipped with both the concepts and a great deal of the syntax for Maven as well.

Artifact management is not a problem that is unique to software engineering, but certainly represents a major obstacle in day to day work. If you have ever heard the expression "DLL Hell" or have worked with many of the popular OpenSource frameworks, then you have encountered the problem of how to meet your software's needs at both build and run time. Your software produces some deliverable artifact (usually a JAR or other J2EE artifact) that depends upon other Java artifacts and may, itself, be a dependent of a larger project. The issue is how to manage the relationships between these actors in a repeatable and uniform way.

Maven solves this problem through declarations of intent instead of a recipe of steps and ingredients. You declare the name and identifying version of your dependencies while simultaneously publishing what you provide (both name and artifact type) and your version number. Maven uses an artifact repository to store its deliverables (including multiple versions). The master repository is hosted by http://ibiblio.org/maven, but the repositories may be hierarchical and are ultimately terminated at your local machine's repository.

The benefit of declarative dependency management and a tool that is dependency-aware is that each machine which participates in the build process behaves in a repeatable manner. No more worrying about DOS or Unix pathnames, local caches of JARs or associated build "wrinkles." Maven does not treat these repositories as read-only. Once your artifact is built, it can be [optionally simultaneously] published to any level of the repository hierarchy you wish. Now, your builds are instantaneously available to your other projects, workgroup or organization just as fast as you can IM your colleagues that you've finished with it.

Daniel concludes his analysis of Maven with "Deliverable Artificats and Build Management with Maven" in the next issue of Anteo Java News.

Applying JAVA Using Best Practices: Part II
By: Vishy Dasari

In the fall edition of Anteo Java News, Dasari explained how JAVA is much more than a programming language. While our readers know THAT, Dasari delves into best practices for Java from architecture to software. "Applying JAVA Using Best Practices: Part II" uncovers the Best Practices for Enterprise JAVA, Deployment, Application Management, and Open-source Software Components.

Enterprise JAVA

A typical enterprise JAVA application would be offered via corporate wide portal. Let us say there is a Business to Employee (B2E) portal that offers an application with HR functionality (e.g. Performance Management Review). Below are the best practices for each aspect of the developement process, all of which are made possible by JAVA enterprise features.

• The portal could be developed using JAVA Portlets and the application could have three web, business and enterprise-information-systems (EIS) tiers in its architecture.
• The web tier could have MVC patterns in its design model that would be implemented using Struts and Tiles framework. Similarly, the business tier could have declarative business rules, processes and other business objects in its design model.
• The business rules would be realized via third party rules based engine with JAVA API.
• The business processes could be documented by via XML that would be consumed and enacted by COTS business process engine. The EIS tier could have ability to interface to both relational database systems via JDBC and legacy systems (IBM Mainframes) via JCA.
• The application could send out email notifications via JAVA Mail API. The application could achieve single sign-on security by participating itself in the corporate-wide security model. Thus, the application has the capability to re-use the users, roles and the organizational model.

Deployment

One of the complex areas within the JAVA based software development is the deployment of the application to one or more of the application servers (J2EE containers). Before deploying the application the system architecture must be defined tailored to specific planned capacity. The system architecture would say if the application needs a clustered and load-balanced environment or a simple one monolithic server hardware running many JAVA processes is good enough.

The system architecture should be separated from the application architecture. The J2EE packaging model allows assembling of various JAVA components as enterprise archive (EAR) files that can be deployed to targeted application server nodes. The whole application is archived as one single file to guaranteeing the integrity of the application resources packaged within. The EAR file can be deployed to any application server type running on any operating system is the best part of the Java deployment model. Use the deployment descriptors to configure application features instead of using any hard-coded values in the source.

Application Management

When designing an enterprise application, the manageability requirements must be understood well in advance. Does the application require active monitoring? Does the application require dynamic configurability? What is the scalability, availability and reliability of the deployed software application? It's not possible to address these critical issues after the software application has been deployed. The manageability cannot be added to the existing system on an after thought basis.

Dasari will tackle the Best Practices for Enterprise JAVA, Deployment, Application Management, and Open-source Software Components in the next issue of Anteo Java News.

The best practice is to build web, business and data access components over a system infrastructure. The system infrastructure should be chosen based on Quality of Service (QoS) needs. For example, a J2EE container that offers manageable API via JMX might be good enough for most of our needs. If you have specific security (e.g. audit trails) needs or high performance using specialized caches then we may have to use third party middleware components (e.g. SpiritSoft). The business components may have to offer two interfaces, one to offer the normative functionality and the other to facilitate the manageability of the component.

Open-source Software Components

We are living in an age where we have access to unbelievable numbers of open and free software components. We must leverage from these open systems by making it part of our process to identify the right component to match our software project needs. Some of the open software components that are immensely popular are Apache Web Server, Apache Tomcat Web Container, JBOSS (for complete J2EE support), Struts, and Tiles. For many projects it is just enough to design a simple J2EE application and deploy it to Apache Tomcat while keeping the data persisted on MySQL relational database server. The argument that open systems do not have good support is a myth. We have the option of buying support from third party or dig into the open source ourselves.

Conclusion

The idea of J2EE development is to practice simplicity on our designs and be open to review from vast community. We should immerse ourselves in to the fun of software development (while applying everything that JAVA platform offers). While enjoying this fun we should strive to meet the functional requirements promised by our analysts to the business owners.

Current Openings

For our most current openings, click here.

back to newsletters >

For more information about the Anteo Group, contact us.