Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
We have seen the maturing of information management as the World Wide Web has grown from static hyperlinked documents to a mix of static and dynamic content. Along with this, we have seen the evolution of the application server, focused upon providing Web access to legacy data stores and dynamically generated content.
First-generation application servers were focused upon providing a rapid development approach to Common Gateway Interface (CGI) solutions. Second-generation application servers used Java and the growing J2EE specification to provide a uniform, cross-platform approach to building Web applications. As more APIs were rolled into J2EE and as acceptance of J2EE has grown, users have found better ways of designing and building Web applications.
As more and more features get rolled into these J2EE application servers, spurred both by user demand and the competition of vendors busy distinguishing themselves in the marketplace, a new architecture is being pushed by several companies. These companies identify the need for J2EE application servers and the solutions built on them to be adaptable and flexible to new technologies. As the J2EE specification grows, along with Web services, the need for a services oriented approach to application servers and applications is necessary to keep vendors and enterprise development groups responsive and iterative in their deployment.
A Services Oriented Approach specifies that an application is made up from a set of independent but cooperating subsystems or services. Such a framework isolates each service and exposes only the necessary declared interfaces to other services. This not only allows architects to organize and reduce dependencies in their products, but also provides for a tailored mix of services in the deployed environment. This approach can be used to support existing requirements, as well as provide a foundation for extending the platform to meet specific business demands.
Application servers are an example of how SOA can be used. By decomposing the application server into services, a server can be scaled down in footprint by removing the unused services for a given solution. Also as new services are needed to support enterprise applications, they can be added into the server. Standard J2EE APIs, such as the J2EE Connector Architecture (JCA), and JMX support the interaction, deployment, and administration of services in the J2EE application server environment. Application servers using this model can adapt more rapidly, and provide new services to customers without having to wait for an entire new specification to be implemented by the vendors themselves. Examples of servers that use this approach include the HP Application Server, Lutris EAS, and the Jboss open source application server.
| The service-oriented approach provides an extremely modular architecture and supports advanced plug-and-play capabilities. |
The Services Oriented Approach also benefits enterprise applications both directly, and through third-party service offerings. Enterprise development groups are encouraged to build and deploy application modules as services that other applications can leverage and reuse. The SOA also encourages third-party services that application servers can utilize. One such example is TIBCO’s TIB/Adapter for EJB, that lets customers tie their business logic inside application servers to services resident in outside applications, suc as SAP R/3, PeopleSoft, Oracle, Siebel, and other COTS and custom applications.
Standardization of SOA is progressing through efforts such as the Java Services Framework (JSF). This effort, which is part of the Java Community Process (JCP) as Java Specification Request (JSR) 111, is focused upon creating an API that enables developers to create streamlined, compatible services. The framework should provide:
- Well-defined contracts that ensure services are accessed and managed in a unified and consistent manner.
- Service dependency management that defines exactly how services interact with each other and the framework.
- Management software that allows developers to dynamically configure, maintain, and deploy services.
- Enterprise application support for business solutions, such as logging and security.
The JSF is focused on being very versatile, both in terms of the environments it can be implemented within, and to the range of services it supports.
As an example of the utility of this architectural approach let’s explore how the service framework of the HP Application Server allows the developer to easily and dynamically introduce new resource types as lookup targets for J2EE components.
The HP Application Server installs a service as an Object Factory into the JVM’s JNDI NamingManager. Therefore, as lookups for resources such as datasources, JMS connection factories, etc. are executed by components the JNDI lookup resolution service (actually called the Reference Resolver Service) can query any registered resource provider service to see whether they can return the object or resource in question. This framework supports the dynamic and runtime addition of any service that support the ResourceProvider interface in order to easily extend the resources available to components. In addition, the services providing access to resources are manageable and configurable using the framework’s facilities and thus extend the basic JNDI Object Factory capabilities. The resource request associated with a lookup is only processed by the resource provider once; after the first retrieval the resource is inserted into the component’s context bindings so subsequent lookups are much faster.
The example service allows the framework to represent Web services as just another resource available for lookup by J2EE components. Thus, the framework can already support a service lookup in line with the model being proposed by draft releases of the JAX-RPC specification. The service in question is simply installed into the framework and advertises the Web service’s interface to the other services in the framework.
This Web service proxy can be installed multiple times into the application server, each time representing a different Web service. Under the covers, it simply takes the method request and uses the JAX-RPC dynamic invocation facilities to execute the request. The service’s associated configuration file can specify a UDDI registry location and business name so the service can obtain the WSDL description and leverage it to perform the service requests.
Once an instance is configured the component simply configures a descriptor element for the service:
<resource-ref> <description>Stock Quote Web Service</description> <res-ref-name>webservice/nasdaq</res-ref-name> <restype> com.hp.mwlabs.webservices.samples.NASDAQStockQuoteService </res-type> <res-auth>Container</res-auth> </resource-ref>
And performs the lookup from its code:
InitialContext ctx = new InitialContext ();
NASDAQStockQuoteService quoteService =
(NASDAQStockQuoteService)ctx.lookup("java:comp/env/webservice/nasdaq");
As you can see, the J2EE developer has been shielded from the potential complexity associated with remote invocations of Web services. In addition, the resource lookup and invocation is in line with the standard J2EE programming model.
The service-oriented approach provides an extremely modular architecture and supports advanced plug-and-play capabilities. Application servers based on SOA, such as HP’s Application Server 8.0, help make businesses more responsive by providing the facilities for rapidly extending the application server to offer access to new and evolving enterprise APIs. In addition, this approach dramatically reduces the risk of infrastructure obsolescence since the end user can extend the functionality with new services or potentially even replace existing services with better and more advanced implementations. Service-centric application servers are positioned to support the next generation of enterprise applications by providing a framework that can adapt to the velocity of business and the rapid emergence of new technologies.
About the Author
Jonathan Maron is a Distinguished Engineer with Hewlett-Packard’s Middleware Division. He was the principle architect of the Bluestone EJB 1.1 Server and has been a member of the EJB and J2EE expert groups. He is currently acting as Specification Lead for the Java Community Process’ (JCP) Java Specification Request (JSR) 111 — The Java Services Framework.
Maron will be presenting a session at Invent 2002, a worldwide developer conference, to be held in Las Vegas, May 28-31, 2002. His presentation on the Java Services Framework initiative will describe how the JSF defines a coarse-grained component infrastructure for quickly assembling non-distributed server applications and will cover the specification’s goals, major components, and some sample applications. In addition, a 12-month JSR roadmap will be presented.
