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

  • Services are software components that have published contracts/interfaces; 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.
  • Consumers can dynamically discover services.
  • Services are interoperable.

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:

  • 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 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.

Pages: 1, 2

Next Pagearrow