Service-Oriented Architecture (SOA) is a hot topic among analysts, CIOs, and technology marketers, but the path from high-level architectural principles to programming a functioning, real-world service isn't always clear, especially since, in the end, you still need to create a clean user interface that's as flexible as the services it consumes.

Why SOA?
The concepts underlying SOA aren't a major divergence from standard design principles like abstraction, encapsulation, and reuse. To put it simply, SOA is a software architecture in which application functionality is encapsulated as independent services. These services are in many cases Web Services but can also be services derived from various technology types. Clients in different applications or business processes can then consume these services. More important, an SOA is designed to decouple the implementation of a software service from the interfaces that call that service. This lets clients of a service rely on a consistent interface regardless of the implementation technology of the service.

Instead of building big monolithic applications, developers can build more agile services that can be deployed and reused across an organization for different applications and processes. This allows for better reuse of software functionality, as well as for increased flexibility because developers can evolve the implementation of a service without necessarily affecting the clients of that service.

To this end, the main requirement of an SOA is that the interface to the services is decoupled from the implementation. This separation provides the central benefit to SOA, both from a programmatic perspective and a financial one. Existing systems, both legacy and modern, internal to the company and external, can be exposed and consumed as services, simplifying the task of development.

A Face for SOA
A discussion of adopting an SOA typically focuses on Web Services reliability, interoperability, and messaging - that is, on how to integrate existing software into processes and composite applications, and not on how users will interact with those processes. Without a user interface, however, there isn't much of an application.

JavaServer Faces (JSF) complements SOA by allowing for an easy way to add the last piece of the SOA puzzle: a human-usable interface. JSF is a standard J2EE technology providing a component-based approach to user interface development, as well as adherence to the model-view-controller architecture that Jakarta Struts helped promote as the standard Web application architecture (Figure 1).

JSF components can be likened to services in SOA: they encapsulate many of the common requirements and commands of a Web-based user interface. Instead of having to programmatically build HTML tables or write data validation in JavaScript, components can provide all of this functionality, enabling a developer to simply drop a component onto a page and set its properties. Even more compelling, the more comprehensive JSF component sets, like Oracle's ADF Faces, are built with multiple sets of renderkits that allow the components to be consumed by many different clients and devices, including PDAs, mobile phones, Telnet, and IM.

Service-Oriented Architecture Details
With Web Services providing an implementation-agnostic messaging protocol, they are the standard messaging protocol for building SOA applications. Combined with standards for reliable messaging, security, and interoperability, Web Services are the ideal SOA backbone.

The services that comprise the building blocks of an SOA application have a common characteristic: a public interface made up of exposed methods that can be consumed by other parts of the application. The public interface can be implemented in any technology (.NET, J2EE, COBOL, PL/SQL, etc.).

By far the most common type of service used in SOA is Web Services. However Web Services by themselves don't provide the basic infrastructure you'd expect in a programming language such as exception handling and state maintenance. To orchestrate a set of Web Services into a business process requires either writing a great deal of low-level code or the use of the Business Process Execution Language (BPEL). BPEL is an emerging OASIS (Organization for the Advancement of Structured Information Standards) standard that enables the orchestration of Web Services. While the BPEL language is represented by a somewhat complex XML schema, there are visual BPEL tools, like Oracle's BPEL Designer, that simplify the orchestration of Web Services into business process flows using a drag-and-drop, declarative development environment.

JavaServer Faces and SOA - A Simple Example
To get a feel for how composite SOA applications, which include both the BPEL process flow as well as a user interface, a simple example SOA/JSF application will be introduced here and more importantly the exact steps required to build the application will be presented. By considering the steps needed to build an SOA application that uses the latest J2EE user interface standard, one can see that building composite SOA applications doesn't have to be an overly complex ordeal.

Consider an example application that consists of both a JSF user interface and a backend BPEL process flow. The JSF user interface includes an entry form for personal information, most importantly a Social Security number. The JSF application then submits the user-provided Social Security number to the BPEL process that shops for the lowest loan rate from a set of independent financial institutions that offer loan rate quotes via Web Services (Figure 2). Once the lowest rate is determined, it's returned back to the JSF application and reported to the user.

For simplicity our example BPEL choreography consists of two Partner Links based on the Web Services that provide two competing loan rates.

Building the BPEL Process Flow
Our example BPEL process flow consists of an orchestration of different services (referred to as Partner Links), which compares the loan rate values returned from the services to determine the lowest one. To prototype this example, a set of simple Web Services can easily be constructed to return hard-coded values as loan rates. The following steps show how to build these using Oracle JDeveloper 10g (version 10.1.3).

Building the Loan Rate Services
The prototype Web Services for this example application are based on simple Java classes that return hard-coded values. They are:

• EzLoans - When supplied with a Social Security number, returns a current loan rate.
  - Return method: getDailyRate
  
• CheapLoans - Also returns a current loan rate when supplied a Social Security code.
  - Return method: getLoanRate

As an example, here is the core source code for the EzLoans Web Service:

package com.jdj.ezloan;
public class EzLoan {

    public float dailyRate = (float)5.6;

      public EzLoan() {
      }

      public float getDailyRate(String soc_security) {
System.out.println("EzLoans returning loan rate " + dailyRate + " for " + soc_security);
return dailyRate;
}
}

As you can see, the method getDailyRate( ) simply returns the value of the dailyRate that is hardcoded to a value of 5.6. To expose this method as a Web Service, an IDE can quickly generate the necessary code, which will expose the method as a Web Service when deployed to an application server.

In a similar fashion the CheapLoans Java class with a method getLoanRate( ) can also be exposed as a Web Service.

Once the necessary plumbing code for the Web Services has been created, the EzLoans and Cheaploans Web Services can be deployed to a J2EE app server such as Oracle Containers for J2EE (OC4J). After successful deployment, the services can be viewed and tested to make sure they can process requests.

Orchestrating the Services - Building a BPEL Flow
Once the services are created you can then build a BPEL process flow that consumes these services. Fortunately this can be done in an entirely visual manner using the BPEL Designer in Oracle JDeveloper. The process for this is as follows:

1. Create a new synchronous BPEL project in JDeveloper (Figure 3)
2. Create Partner Links mappings to the deployed Web Services
3. Create a process flow that invokes the Partner Links (Web Services) and compares their values and returns the lowest loan rate value.
4. Compile and deploy to a BPEL Process Manager