Docstoc

SOA Introduction for Java Developers

Document Sample
SOA Introduction for Java Developers Powered By Docstoc
					SOA Introduction for Java Developers

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 b uilding
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.

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 proce sses 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 se rvice-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 w hether 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:

          A mapping file, an XML file that details Java -to-WSDL mapping. In most instances, this
          file is required only for more complex or customized mappings.
          A service endpoint interface that's used by the J2EE server to expose the web service
          endpoint. The interface must extend the java.rmi.Remote interface, as in the
          following example:

            package time;
            import java.rmi.RemoteException;
            import java.rmi.Remote;
             public interface TimeService extends Remote
             {
            public String getDateTime (String name) throws
            RemoteException;
        }

        Web services deployment descriptors such as webservices.xml, which describe the
        location of endpoint interface, WSDL, and Java -to-WSDL mapping.
        Vendor-specific deployment descriptors, such as oracle-webservices.xml for the Oracle
        Application Server.

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 tha t 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 na med 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:

        Partnerlinks for the services with which the process interacts.
        Variables for the data to be manipulated.
        Correlations to correlate messages between asynchronous invocatio ns.
        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 gra phical 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 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 contro ls 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 te chnologies 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.




http://www.soatutorial.net/

				
DOCUMENT INFO
Description: 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.