ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

An Introduction to Service-Oriented Architecture from a Java Developer Perspective
Pages: 1, 2

Building the Service Layer in Java

Java provides a comprehensive platform for building the service layer of service-oriented applications. J2EE 1.4 standardizes the APIs for building web services using Java.

The following table provides the list of APIs available in the J2EE 1.4 to build web services applications.

Java APIs Description

JAXP

Java API for XML Parsing

JAXB

Java API for XML Binding

JAX-RPC (JSR 101)

Java API for XML-Remote Procedure Call

SAAJ

SOAP API for Attachments in Java

JAXR

Java API for XML Registries

JSR 109

Web Services Deployment Model

EJB 2.1

Stateless Session EJB Endpoint Model

Of these technologies, JAX-RPC can be thought of as the core API for building and deploying web services with J2EE. It provides a simple, robust platform for building web services applications by hiding from the developer the complexity of mapping between XML types and Java types and the lower-level details of handling XML SOAP messages. JAX-RPC introduces a method call paradigm by providing two programming models: a server-side model for developing web services endpoints using Java classes or stateless EJB components, and a client-side model for building Java clients that access web services as local objects. JAX-RPC 1.1 mandates use of SOAP 1.1 and interoperability with other web services built with other technologies such as Microsoft .NET. Several J2EE-1.4-compliant application servers, such as Oracle Application Server Containers for J2EE (OC4J) 10.1.3, the Sun One Application Server, and IBM WebSphere V6, support JAX-RPC.

If you already have a stateless session EJB or a Java class that performs your business logic, J2EE 1.4 lets you expose it as a service in a standard manner using JAX-RPC. If you're building services using J2EE, you may need several artifacts in addition to the standard WSDL:

  • A mapping file, an XML file that details Java-to-WSDL mapping. In most instances, this file is required only for more complex or customized mappings.
  • A service endpoint interface that's used by the J2EE server to expose the web service endpoint. The interface must extend the java.rmi.Remote interface, as in the following example:
    
    package time; 
    import java.rmi.RemoteException; 
    import java.rmi.Remote; 
     public interface TimeService extends Remote 
     { 
     public String getDateTime (String name) throws 
     RemoteException; 
    }
  • Web services deployment descriptors such as webservices.xml, which describe the location of endpoint interface, WSDL, and Java-to-WSDL mapping.
  • Vendor-specific deployment descriptors, such as oracle-webservices.xml for the Oracle Application Server.

We'll discuss building the service layer of an SOA application in a future article.

At first glance, these requirements for a service seem daunting. However, most SOA vendors are easing developers' workloads by providing the appropriate design tools. For example, Oracle offers web service design facilities within the Oracle JDeveloper 10g IDE, and IBM's WebSphere Application Developer Studio simplifies SOA development.

Finally, as mentioned earlier, interoperability is one of the key aspects of service-oriented applications. If you want your service to be reusable, make sure it's interoperable not only with other J2EE platforms but also with heterogeneous platforms such as .NET. You can't really anticipate who your consumers will be--once your service is deployed and registered in a service directory (such as UDDI), any consumer can find and use it. So when you build your service, make sure it conforms to the WS-I Basic Profile. WS-I is an open industry consortium of SOA platform vendors such as Oracle, IBM, Microsoft, and Sun that focuses on web services interoperability across platforms, operating systems, and languages. J2EE 1.4 requires conformance to the WS-I Basic Profile, so your application server should generate interoperable services.

Business Process Layer

Another promise of SOA is that you can build a new application from existing services. The main benefit that SOA brings is the standardization of business process modeling, often referred to as service orchestration. You can build a web-service-based layer of abstraction over legacy systems and subsequently leverage them to assemble business processes. In addition, SOA platform vendors are providing tools and servers to design and execute these business processes. This effort has been standardized by an OASIS standard named Business Process Execution Language (BPEL); most platform vendors are adhering to this standard. BPEL is essentially a programming language but is represented in XML.

Here's an overview of a BPEL-defined process:


<process>

 <!– Definition and roles of process participants -->
 <partnerLinks> ... </partnerLinks> 

 <!- Data/state used within the process --> 
 <variables> ... </variables> 

 <!- Properties that enable conversations -->
 <correlationSets> ... </correlationSets>
 
 <!- Exception handling -->
 <faultHandlers> ... </faultHandlers>

 <!- Error recovery – undoing actions --> 
 <compensationHandlers> ... </compensationHandlers> 

 <!- Concurrent events with process itself -->
 <eventHandlers> ... </eventHandlers> 

 </process>  

BPEL provides:

  • Partnerlinks for the services with which the process interacts.
  • Variables for the data to be manipulated.
  • Correlations to correlate messages between asynchronous invocations.
  • Faults for message definitions for problems.
  • Compensation handlers to execute in the case of problems.
  • Event handlers that let the process deal with anticipated events in a graceful fashion.

Although the BPEL syntax is rather straightforward, a graphical representation of a business process is preferable, so you'll benefit from a GUI design tool to assemble business processes from existing services. Thus, creating business processes is a relatively simple task if you understand your business processes and you've deployed services available for your use. The Oracle BPEL Designer, which can be used as either as an Eclipse or JDeveloper plug-in, helps you design business processes, making it easier to design and develop services.

Related Reading

Java Web Services
By David A. Chappell, Tyler Jewell

In addition, you'll need a high-performance processing environment (or server) to execute the generated business processes, and a management tool to test and monitor the status of these deployed processes. Most SOA platform vendors such as Oracle and IBM now have a robust platform to deploy business processes. For example, Oracle provides the Oracle BPEL Process Manager to deploy and execute business processes and Oracle BPEL Console to test and monitor business processes.

Presentation Layer: The Data Binding Problem

The presentation layer is very important from a user perspective. This layer can be built with technologies such as JSP, JSF, portlets, or standalone Java clients. For developers, it's an uphill battle to achieve loose coupling between the presentation layer and the business logic or service layers. Several Model-View-Controller (MVC) frameworks, which have been in use for a long time, allow for loose coupling between the view, or presentation layer, and the model that supplies the data and business logic. This lets you change either the view or model with minimal impact. This does help us achieve the type of loose coupling we want between the presentation and service layers. The main problem, however, is that there's no standard way of binding data between different kinds of clients (such as JSP, Java clients, and services such as EJB or web services), and clients have to know the exact underlying implementation of the service layer. For example, services built using either web services or pure EJB have different interfaces to either bootstrap the service or transfer data--and this defeats the goal of SOA. JSR-227 aims to standardize the data binding of services for J2EE applications by defining the data binding service through a set of XML-based metadata definitions.

JSR-227 will let developers create data controls by using a business service, which could be a web service, stateless EJB, or a standard Java class. The data control will describe the collections (attributes and operations supported the service using XML metadata). This data control can later be used by UI components via declarative bindings and thus completely decouple the presentation layer from the service layer.

Best Practices

Here are a few best practices to follow when building service-oriented applications:

1. Do not jump into implementation technologies just because of the hype. Carefully consider whether web services make sense for your organization. Building a service-oriented application using traditional technologies such as RMI may be more appropriate for your use cases than using web services.

2. Modularity of services is very important. Do not build fine-grained services, as this will result in a tightly coupled, brittle infrastructure.

3. For most applications, interoperability is important. Adhere to the WS-I best practices--and even then, make sure to test for interoperability with your preferred clients.

4. If it doesn't make sense to use web services for your application, there are alternatives. Many BPEL process managers, such as Oracle BPEL Process Manager, let you use native protocols.

Conclusion

In this article, I provided an introduction to SOA and provided some guidelines that can help you bootstrap developing your first service-oriented applications using Java. You can build service-oriented applications using these best practices to future-proof your investments.

 

Resources

Debu Panda is a Senior Principal Product Manager of the Oracle Application Server development team.


Return to ONJava.com