SOA by deepthi24


									    Service-Oriented Architecture (SOA) and
    Web Services: The Road to Enterprise
    Application Integration (EAI)

By Qusay H. Mahmoud, April 2005

Most enterprises have made extensive investments in system resources over the course of many years.
Such enterprises have an enormous amount of data stored in legacy enterprise information systems
(EIS), so it's not practical to discard existing systems. It's more cost-effective to evolve and enhance
EIS. But how can this be done? Service Oriented Architecture (SOA) provides a cost-effective solution.
SOA is not a new concept. Sun defined SOA in the late 1990's to describe Jini, which is an environment
for dynamic discovery and use of services over a network. Web services have taken the concept of
services introduced by Jini technology and implemented it as services delivered over the web using
technologies such as XML, Web Services Description Language (WSDL), Simple Object Access
Protocol (SOAP), and Universal Description, Discovery, and Integration(UDDI). SOA is emerging as
the premier integration and architecture framework in today's complex and heterogeneous computing
environment. Previous attempts didn't enable open interoperable solutions, but relied on proprietary
APIs and required a high degree of coordination between groups. SOA can help organizations
streamline processes so that they can do business more efficiently, and adapt to changing needs and
competition, enabling the software as a service concept. eBay for example, is opening up its web
services API for its online auction. The goal is to drive developers to make money around the eBay
platform. Through the new APIs, developers can build custom applications that link to the online
auction site and allow applications to submit items for sale. Such applications are typically aimed at
sellers, since buyers must still head to to bid on items. This type of strategy, however, will
increase the customer base for eBay.
SOA and web services are two different things, but web services are the preferred standards-based way
to realize SOA. This article provides an overview of SOA and the role of web services in realizing it.
The article provides:
       An overview of software as a service
       A tutorial on SOA
       An overview of Sun's platforms for building web services
       Guidelines for designing interoperable web services
       Challenges in moving to SOA
       An overview of Java Business Integration (JSR 208)
       A discussion of web services for enterprise application integration
Service-Oriented Architecture

SOA is an architectural style for building software applications that use services available in a network
such as the web. It promotes loose coupling between software components so that they can be reused.
Applications in SOA are built based on services. A service is an implementation of a well-defined
business functionality, and such services can then be consumed by clients in different applications or
business processes.
SOA allows for the reuse of existing assets where new services can be created from an existing IT
infrastructure of systems. In other words, it enables businesses to leverage existing investments by
allowing them to reuse existing applications, and promises interoperability between heterogeneous
applications and technologies. SOA provides a level of flexibility that wasn't possible before in the
sense that:
     Services are software components with well-defined interfaces that are implementation-
      independent. An important aspect of SOA is the separation of the service interface (the what)
      from its implementation (the how). Such services are consumed by clients that are not
      concerned with how these services will execute their requests.
     Services are self-contained (perform predetermined tasks) and loosely coupled (for
     Services can be dynamically discovered
     Composite services can be built from aggregates of other services
SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers
register their service in a public registry. This registry is used by consumers to find services that match
certain criteria. If the registry has such a service, it provides the consumer with a contract and an
endpoint address for that service.

SOA-based applications are distributed multi-tier applications that have presentation, business logic,
and persistence layers. Services are the building blocks of SOA applications. While any functionality
can be made into a service, the challenge is to define a service interface that is at the right level of
abstraction. Services should provide coarse-grained functionality.
Realizing SOA with Web Services

Web services are software systems designed to support interoperable machine-to-machine interaction
over a network. This interoperability is gained through a set of XML-based open standards, such as
WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and
using web services.
Sun's Java Web Services Developer Pack 1.5 (Java WSDP 1.5) and Java 2 Platform, Enterprise Edition
(J2EE) 1.4 can be used to develop state-of-the-art web services to implement SOA. The J2EE 1.4
platform enables you to build and deploy web services in your IT infrastructure on the application
server platform. It provides the tools you need to quickly build, test, and deploy web services and
clients that interoperate with other web services and clients running on Java-based or non-Java-based
platforms. In addition, it enables businesses to expose their existing J2EE applications as web services.
Servlets and Enterprise JavaBeans components (EJBs) can be exposed as web services that can be
accessed by Java-based or non-Java-based web service clients. J2EE applications can act as web
service clients themselves, and they can communicate with other web services, regardless of how they
are implemented.
Web Service APIs

The Java WSDP 1.5 and J2EE 1.4 platforms provide the Java APIs for XML (JAX) that are shown in
Table 1.
Table 1: Java APIs for XML (JAX) provided by J2EE 1.4
         API                                             Description
Java API for XML
                    This API lets you process XML documents by invoking a SAX or DOM parser in
Processing (JAXP)
                    your application. JAXP 1.2 supports W3C XML Schema.
Java API for XML-
                    This is an API for building and deploying SOAP+WSDL web services clients and
based RPC (JAX-
RPC) 1.1
                    This is a Java API for accessing different kinds of XML registries. It provides you
Java APIs for XML
                    with a single set of APIs to access a variety of XML registries, including UDDI
Registries (JAXR)
                    and the ebXML Registry. You don't need to worry about the nitty-gritty details of
                    each registry's information model.
SOAP with
                    This API lets you produce and consume messages conforming to the SOAP 1.1
Attachments API for
                    specification and SOAP with Attachments note.
Java (SAAJ) 1.2
                    JSR 109 defines deployment requirements for web services clients and endpoints
JSR 109: Web        by leveraging the JAX-RPC programming model. In addition, it defines standard
services for J2EE deployment descriptors using the XML Schema, thereby providing a uniform
1.0                 method of deploying web services onto application servers through a wide range
                    of tools.

Note: JAX-RPC 1.1 and SAAJ 1.2 include support for the Web Services Interoperability (WS-I) and
the Web Services Interoperability Basic Profile (WSI-BP), currently being developed by, which provides a set of guidelines on how to develop interoperable web services.
With the APIs described in Table 1, you can focus on high-level programming tasks, rather than low-
level issues of XML and web services. In other words, you can start developing and using Java WSDP
1.5 and J2EE 1.4 web services without knowing much about XML and web services standards. You
only need to deal with Java semantics, such as method invocation and data types. The dirty work is
done behind the scenes, as discussed further in the next section.
Figure 2 illustrates how the JAXR and JAX-RPC APIs play a role in publishing, discovering, and using
web services and thus realizing SOA.

                    Figure 2: Web services Publish-Discover-Invoke model
Web Services Endpoints in J2EE 1.4

The J2EE 1.4 platform provides a standardized mechanism to expose servlets and EJBs as web
services. Such services are considered web service endpoints (or web service ports), and can be
described using WSDL and published in a UDDI registry so that they can be discovered and used by
web service clients.
Once a web service is discovered, the client makes a request to a web service. The web service
processes the request and sends the response back to the client. To get a feeling for what happens
behind the scenes, consider Figure 2, which shows how a Java client communicates with a Java web
service in the J2EE 1.4 platform. Note that J2EE applications can use web services published by other
providers, regardless of how they are implemented. In the case of non-Java-based clients and services,
the figure would change slightly, however. As mentioned earlier, all the details between the request and
the response happen behind the scenes. You only deal with typical Java programming language
semantics, such as Java method calls, Java data types, and so forth. You needn't worry about mapping
Java to XML and vice-versa, or constructing SOAP messages. All this low-level work is done behind
the scenes, allowing you to focus on the high-level issues.
             Figure 3: A Java Client Calling a J2EE Web Service (click image for full
Note: J2EE 1.4 and Java WSDP 1.5 support both RPC-based and document-oriented web services. In
other words, once a service is discovered, the client can invoke remote procedure calls on the methods
offered by the service, or send an XML document to the web service to be processed

Interoperability is the most important principle of SOA. This can be realized through the use of web
services, as one of the key benefits of web services is interoperability, which allows different
distributed web services to run on a variety of software platforms and hardware architectures. The Java
programming language is already a champion when it comes to platform independence, and
consequently the J2EE 1.4 and Java WSDP 1.5 platforms represent the ideal platforms for developing
portable and interoperable web services.
Interoperability and portability start with the standard specifications themselves. The J2EE 1.4 and Java
WSDP 1.5 platforms include the technologies that support SOAP, WSDL, UDDI, and ebXML. This
core set of specifications -- which are used to describe, publish, enable discovery, and invoke web
services -- are based on XML and XML Schema. If you have been keeping up with these core
specifications, you know it's difficult to determine which products support which levels (or versions) of
the specifications. This task becomes harder when you want to ensure that your web services are
The Web Services Interoperability Organization (WS-I) is an open, industry organization committed to
promoting interoperability among web services based on common, industry-accepted definitions and
related XML standards support. WS-I creates guidelines and tools to help developers build
interoperable web services.
WS-I addresses the interoperability need through profiles. The first profile, WS-I Basic Profile 1.0
(which includes XML Schema 1.0, SOAP 1.1, WSDL 1.1, and UDDI 2.0), attempts to improve
interoperability within its scope, which is bounded by the specification referenced by it.
Since the J2EE 1.4 and Java WSDP 1.5 platforms adhere to the WS-I Basic Profile 1.0, they ensure not
only that applications are portable across J2EE implementations, but also that web services are
interoperable with any web service implemented on any other platform that conforms to WS-I
standards such as .Net.
Challenges in Moving to SOA

SOA is usually realized through web services. Web services specifications may add to the confusion of
how to best utilize SOA to solve business problems. In order for a smooth transition to SOA, managers
and developers in organizations should known that:
     SOA is an architectural style that has been around for years. Web services are the preferred way
      to realize SOA.
     SOA is more than just deploying software. Organizations need to analyze their design
      techniques and development methodology and partner/customer/supplier relationship.
     Moving to SOA should be done incrementally and this requires a shift in how we compose
      service-based applications while maximizing existing IT investments.
Sun has recognized the challenges customers face in moving to SOA and has developed an SOA
Opportunity Assessment service offering that leverages years of experience in delivering enabling
technology solutions that met the unique needs of each customer. Sun's SOA Opportunity Assessment
provides customers with an analysis of their organization's readiness to move to SOA, and a set of best
practices developed to complement this service offering, and helps them identify business-relevant
opportunities for building their service-oriented applications using architectural best practices and
reusable design patterns. For more information on this as well as additional Sun SOA services
offerings, see Assessing your SOA Readiness (pdf).
In addition, Sun's Java BluePrints provide developers with guidelines, patterns, and sample
applications. Java BluePrints has a book on Designing Web Services with J2EE 1.4, which is the
authoritative guide to the best practices for designing and integrating enterprise-level web services
using J2EE 1.4. It provides the guidelines, patterns, and real-world examples architects and developers
need in order to shorten the learning curve and start building robust, scalable, and portable solutions.
It is also worth noting that the Java BluePrints Solutions Catalog has a section on SOA with web
Java Business Integration

Enterprises have invested heavily in large-scale packaged application software such as enterprise
resource planning (ERP), supply chain management (SCM), customer relationship management
(CRM), and other systems to run their businesses. IT managers are being asked to deliver the next
generation of software applications that will provide new functionality, while leveraging existing IT
investments. The solution to this is integration technology; the available integration technology
solutions, however, are proprietary and do not interoperate with each other. The advent of web services
and SOA offers potential for lower integration costs and greater flexibility.
JSR 208 Java Business Integration (JBI), is a specification for a standard that describes plug-in
technology for system software that enables a service-oriented architecture for building integration
server software. JBI adopts SOA to maximize the decoupling between components, and create well-
defined interoperation semantics founded on standards-based messaging. JSR 208 describes the service
provider interfaces (SPIs) that service engines and bindings plug into, as well as the normalized
message service that they use to communicate with each other. It is important to note that JSR 208
doesn't define the engines or tools themselves. JSR 208 has the following business advantages:
     It is itself a service-oriented architecture that will be highly flexible, extensible, and scalable.
     Service engines could be implemented in any language as long as they support the SPI
      definition implemented by JSR 208 compliant systems.
     New engines can be added to the container by plugging them into the standard SPI and defining
      the messages they will use to interact with the rest of the system.
     ISVs that specialize in one of these components could be able to plug special-purpose engines
      into industry-standard integration solutions.
     Open interfaces will enable free and open competition around the implementation of these
      engines. This means that customers will be free to choose the best solution available, and their
      integration code can be migrated between implementations.
A JSR 208 example architecture is shown in Figure 4.

             Figure 4: An Example Architecture Based on JSR 208 (click image for full size)
As you can see, JBI provides an environment in which plug-in components reside. Interaction between
the plug-in components is by means of message-based service invocation. Services produced and
consumed by plug-in components are modeled using WSDL (version 2.0). A normalized message
consists of two parts: the abstract XML message, and message metadata (or message context data),
which allows for association of extra information with a particular message as it is processed by plug-in
and system components.
Project Shasta

Sun's Project Shasta, which is based on the JSR 208 architecture, aims to build a next-generation
integration solution. This project will be implemented on Sun's J2EE application server and leverage
J2EE services such as Java Message Service (JMS), J2EE Connector Architecture (JCA), failover, and
high availability. It will feature many of the emerging standards in the web services (such as web
service notification, coordination, and transaction management) and integration space. The project will
be focused on web services and using them to enable the creation of service-oriented architectures.
Figure 5 depicts what a fully implemented product could look like.
             Figure 5: An Example Architecture Based on JSR 208 (click image for full size)

Web Services and J2EE 1.4 for Enterprise Application Integration

Web services, which build on knowledge gained from other mature distributed environments (such as
CORBA and RMI), offer a standardized approach to application-to-application communication and
interoperability. They provide a way for applications to expose their functionality over the web,
regardless of the application's programming language or platform. In other words, they allow
application developers to master and manage the heterogeneity of EIS.
Web services let developers reuse existing information assets by providing developers with standard
ways to access middle-tier and back-end services and integrate them with other applications.
Since web services represent gateways to existing back-end servers, strong support for back-end
integration is required. This is where the J2EE platform comes into play. The J2EE platform provides
industry-standard APIs (such as the J2EE Connector Architecture, the JDBC API, Java Message
Service (JMS), among others) for accessing legacy information systems. J2EE 1.4 (which supports web
services) provides an excellent mechanism to integrate legacy EIS and expose their functionality as
interoperable web services, thereby making legacy data available on heterogeneous platform

The advent of web services and SOA offers potential for lower integration costs and greater flexibility.
An important aspect of SOA is the separation of the service interface (the what) from its
implementation (the how). Such services are consumed by clients that are not concerned with how
these services will execute their requests. Web services are the next step in the Web's evolution, since
they promise the infrastructure and tools for automation of business-to-business relationships over the
JSR 208 (Java Business Integration) has the potential to revolutionize the industry as it provides a way
for platform vendors, system integrators, and enterprise software developers to collaborate on
integration solutions that have the flexibility to move with a changing market.
ging market.

To top