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 ebay.com 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
|
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 independence)
- 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.
| Figure 1: SOA's Find-Bind-Execute Paradigm |
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.
|
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.
|
The Java WSDP 1.5 and J2EE 1.4 platforms provide the Java APIs for XML (JAX) that are shown in Table 1.
| API | Description |
|---|---|
| This API lets you process XML documents by invoking a SAX or DOM parser in your application. JAXP 1.2 supports W3C XML Schema. | |
| This is an API for building and deploying SOAP+WSDL web services clients and endpoints. | |
| This is a Java API for accessing different kinds of XML registries. It provides you with a single set of APIs to access a variety of XML registries, including UDDI and the ebXML Registry. You don't need to worry about the nitty-gritty details of each registry's information model. | |
| This API lets you produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note. | |
| JSR 109 defines deployment requirements for web services clients and endpoints by leveraging the JAX-RPC programming model. In addition, it defines standard deployment descriptors using the XML Schema, thereby providing a uniform 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 http://www.ws-i.org, 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 |
|
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 size) |
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 interoperable.
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.
|
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 services.
|
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.
|
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, 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 environments.
|
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 Internet.
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.
|
- Assessing your SOA Readiness
- On the Road to SOA: Building Real-World Enterprise Web Services (JavaOne 2004 Presentation)
- Using SOA and J2EE to Ease Integration and Customization While Reducing Overall Implementation and Customization Costs (JavaOne 2004 Presentation)
- Java Business Integration Vision
- JSR 208: Java Business Integration
- Java WSDP 1.5
- J2EE 1.4
- Java BluePrints
- BluePrints Solution Catalog (SOA with Web Services)
Không có nhận xét nào:
Đăng nhận xét