Tracking Service-Oriented and Web-Oriented Architecture

SOA & WOA Magazine

Subscribe to SOA & WOA Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA & WOA Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


SOA & WOA Authors: TJ Randall, Lori MacVittie, Andreas Grabner, Dynatrace Blog, Cynthia Dunlop

Related Topics: Java EE Journal, SOA & WOA Magazine, Java Developer Magazine

J2EE Journal: Article

Java Feature: Putting a Face on Web Services and SOA

It's easier than you think

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
In the interest of conveying the concepts behind the services without getting bogged down in the actual implementation of these services, Web Services will be auto-generated in JDeveloper based on simple Java classes that contain public methods that return current loan rate information and can be exposed as Web Services.

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
Building a BPEL process flow consists primarily of editing the XML document that defines the flow. Previously mentioned as an alternative to coding directly in XML, it's possible to use Oracle JDeveloper's BPEL Designer feature, which provides a graphical environment for designing BPEL process flows and deploying them to a BPEL process manager.

More Stories By Chris Schalk

Chris Schalk is Google Developer Advocate at Google. He is also one of the original members of the OpenAjax Alliance. Prior to Google, he was a Principal Product Manager and Java Evangelist for Oracle's application server and development tools division. While at Oracle, he worked to define the overall web development experience for Oracle JDeveloper and ADF Faces (Trinidad). He is also the co-author of 'JavaServer Faces: The Complete Reference' published through McGraw-Hill Osborne (ISBN: 0072262400).

More Stories By Michael O'Neill

Michael O'Neill is manager of developer programs at Oracle, with six years of experience in Web and UI development utilizing both Java and Microsoft technologies.

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Mark 05/01/07 12:47:16 PM EDT

Hi,

I have attempted to use the example (http://java.sys-con.com/read/192427.htm)with JDeveloper 10.1.3, and
I keep running into the same error when I compile the BPEL, it complains regarding
the "soc_security" global variable - "make sure variable with messageType definition is used" this
is just a local variable to pass a value around?

Any comments/suggestions regarding how I can fix this issue would be most appreciated.

Details from JDeveloper below.

Error(84):
[Error ORABPEL-10032]: missing messageType
[Description]: in line 84 of "C:\002_DEV\loanMark1\loanMark1\bpel\loanMark1.bpel",
variable "soc_security" of invoke does not have a messageType definition..
[Potential fix]: make sure variable with messageType definition is used in incoming
and outgoing activities.

Error(84):
[Error ORABPEL-10032]: missing messageType
[Description]: in line 84 of "C:\002_DEV\loanMark1\loanMark1\bpel\loanMark1.bpel",
variable "soc_security" of invoke does not have a messageType definition..
[Potential fix]: make sure variable with messageType definition is used in incoming and outgoing activities.

Thank you

Fred Holahan 03/17/06 10:39:59 AM EST

Guys,

I enjoyed your piece entitled "Putting a Face on Web Services and SOA". With regard to BPEL, you really should check out Active Endpoints. We offer a world-class, Eclipse based BPEL designer FOR FREE, and servers that range from our open source ActiveBPEL Engine all the way up to enterprise class BPEL solutions for popular J2EE containers.

Readers who want to download the free ActiveBPEL Designer can do so at http://www.active-endpoints.com/products/activebpeldes/index.html. Readers who need access to commercial grade open source BPEL engine can visit http://www.activebpel.org.

Fred

SYS-CON Italy News Desk 03/16/06 08:23:04 PM EST

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.