ONJava.com    
 Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples


An Introduction to Service-Oriented Architecture from a Java Developer Perspective An Introduction to Service-Oriented Architecture from a Java Developer Perspective

by Debu Panda
01/26/2005

The use of heterogeneous technologies and applications in corporations is a reality. At a time when resources are scarce, IT shops cannot just throw away their existing applications; rather, they must leverage their existing investments. service-oriented architecture (SOA) is popular because it lets you reuse applications and it promises interoperability between heterogeneous applications and technologies.

In this article, I will introduce SOA from a Java developer perspective and examine the technologies available in the Java space to build service-oriented applications.

What is SOA?

The concept of a service is nothing new, but the notion of an SOA has evolved over the past couple of years. It's an architectural style of building software applications that promotes loose coupling between components so that you can reuse them. Thus, it's a new way of building applications with the following characteristics:

Figure 1 gives a overview diagram of service-oriented architecture.

The basic building block of SOA is the service. A service is a self-contained software module that performs a predetermined task: "verify a customer's credit history," for example. Services are software components that don't require developers to use a specific underlying technology. As Java developers, we tend to focus on reusing code; thus, we tend to tightly integrate the logic of objects or components within an application. However, SOA promotes application assembly because services can be reused by numerous consumers. For example, in order to create a service that charges a consumer's credit card, we build and deploy only one instance of such a service; then we can consume this service from any number of applications.

Related Reading

Java Web Services in a Nutshell
By Kim Topley

The other key advantage of SOA is that it lets you automate business-process management. Business processes may consume and orchestrate these services to achieve the desired functionality. Thus, new business processes can be constructed by using existing services. For example, a customer order that has been submitted to shipping can be represented by a business process that can asynchronously interact with the requisite services.

Why SOA?

Today's IT organizations invariably employ disparate systems and technologies. Most analysts predict that J2EE and .NET will continue to coexist in most organizations and the trend of having heterogeneous technologies in IT shops will continue. Moreover, creating applications that leverage these different technologies has historically been a daunting task. SOA provides a clear solution to these application integration issues by allowing systems to expose their functionality via standardized, interoperable interfaces.

Using SOA offers several key advantages. You can:

SOA and Java

Most developers often think web services and SOA are synonymous. Many also think it's not possible to build service-oriented applications without using web services. To clarify, SOA is a design principle, whereas web services is an implementation technology. You can build a service-oriented application without using web services--for example, by using other traditional technologies such as Java RMI.

The main theme behind SOA is to find the appropriate modularity and achieve loose coupling between modules. You can build an application where the modules don't have too much tight coupling between interacting components, such as an application where the JSP presentation layer is not tightly integrated with the data model and accesses it appropriately via an EJB.

It's worth mentioning that Jini had long established the concept of SOA prior to the rise in popularity of web services. What web services bring to the table are the platform-independent standards such as HTTP, XML, SOAP, and UDDI, thus allowing interoperability between heterogeneous technologies such as J2EE and .NET. In this article, we'll focus on web services as the enabling technology for building service-oriented applications.

Different Layers for Service-Oriented Applications

Like any distributed application, service-oriented applications are multi-tier applications and have presentation, business logic, and persistence layers. Figure 2 provides a typical architecture for a service-oriented application. The two key tiers in SOA are the services layer and the business process layer.

The Service Layer

As we discussed earlier, services are the building blocks of service-oriented applications. Thus, services are somewhat analogous to Java objects and components such as EJBs. Unlike objects, however, services are self-contained, maintain their own state, and provide a loosely coupled interface.

The greatest challenge of building a service-oriented application is creating an interface with the right level of abstraction. While analyzing your business requirements, carefully consider what software components you want to build as a service. Generally, services should provide coarse-grained functionality. For example, the software component that processes a purchase order is a good candidate for publication as a service, as opposed to a component that just updates an attribute of a purchase order.

You have two choices when building a service: the top-down approach or the bottom-up approach. The top-down approach requires that you identify and describe the messages and operations your service provides and then implement the service. This approach is recommended when you're building a completely new service, as it lets you choose your preferred implementation technology. This approach also promotes the most interoperable services, since you can avoid implementation artifacts that may preclude interoperability (for example, data types that may not have an interoperable representation).

The bottom-up approach is quite popular because it lets you reuse your existing investment in business components. For example, vendors provide the tools that let you expose a PL/SQL-stored procedure that checks whether a customer is entitled to a discount as a service.

The most important aspect of a service is the service description. When using web services as the implementation technology for SOA, Web Services Description Language (WSDL) describes the messages, types, and operations of the web service, and is the contract to which the web service guarantees it will conform.

Here's an example of WSDL for a simple web service:


<?xml version="1.0" encoding="UTF-8"?> 
<definitions name="MyTimeService" 
  targetNamespace="urn:oracle-ws"
  xmlns:tns="urn:oracle-ws"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types/>
<message name="TimeService_getDateTime">
<part name="String_1" type="xsd:string"/></message>
<message name="TimeService_getDateTimeResponse">
<part name="result" type="xsd:string"/></message>
<portType name="TimeService">
<operation name="getDateTime" parameterOrder="String_1">
<input message="tns:TimeService_getDateTime"/>
<output message="tns:TimeService_getDateTimeResponse"/>
</operation>
</portType>
<binding name="TimeServiceBinding" type="tns:TimeService">
<operation name="getDateTime">

<input>
<soap:body
  encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  use="encoded"
  namespace="urn:oracle-ws"/>
</input>

<output>
  <soap:body
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    use="encoded"
    namespace="urn:oracle-ws"/>
</output>

<soap:operation soapAction=""/></operation>

<soap:binding
  transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
</binding>

<service name="MyTimeService">

<port
  name="TimeServicePort"
  binding="tns:TimeServiceBinding">
  <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port> 

</service> 

</definitions>

If you look carefully you'll note that the WSDL has a complete description of the TimeService web service, including the port, operations, and message types. A web service based on this WSDL must support these operations and messages whether it's built using Oracle's Java technology or any other technology, such as Microsoft .NET.

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:

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:

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

Copyright © 2009 O'Reilly Media, Inc.