Service-Oriented Architecture from a Java Developer Perspective

In IT Industry the use of different technologies and applications 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.

Now 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?

Service Oriented architecture is abbreviated as SOA.SOA is 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:

• Services are software components that have published contracts; these contracts are platform, language, and operating-system-independent.

XML and the Simple Object Access Protocol (SOAP) are the enabling technologies for SOA, since they’re platform-independent standards.

• Services are interoperable.

Service is the basic building block of SOA. 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.

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?

Using SOA offers several key advantages. You can:

• Adapt applications to changing technologies.
• Easily integrate applications with other systems.
• Leverage existing investments in legacy applications.
• Quickly and easily create a business process from existing services.

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 Technology 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

Different Layers for Service-Oriented Applications

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. On creating the service layer the following points should be considered.

• 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.
• On building a service you have two choices namely : the top-down approach or the bottom-up approach

Top-down approach:  The top-down approach requires that you identify and describe the messages and operations your service provides and then implement the service.

The bottom-up approach : It 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.

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

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

At first glance, 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.

Business Process Layer

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.

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.

In addition, you’ll need a high-performance processing environment (or server) to execute he 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.

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.