读《Service Oriented Java Business Integration》2

2 Java Business Integration

Total Cost of Ownership (TCO)

SOA - The Motto

Why We Need SOA

We have been using multiple technologies for developing application components: * Remote Procedure Call (RPC) * Common Object Request Broker Architecture (CORBA) * Distributed Component Object Model (DCOM) * .NET remoting * Enterprise Java Beans (EJBs) * Java Remote Method Invocation (RMI)

What is SOA

SOA is all about a set of architectural patterns, principles, and best practices to implement software components in such a way that we overcome much of the deficiencies identified in traditional programming paradigms. SOA speaks about services implemented based on abstract interfaces where only the abstract interface is exposed to the outside world. Hence, the consumers are unaware of any implementation details. Moreover, the abstract model is neutral of any platform or technology. Features of SOA: * Standard-based (WS-* Specifications) * Servicese are autonomous and coarse grained * Providers and consumers are loosely coupled

SOA and Web Services

SOA doesn't mandate any specific platform, technology, or even a specific method of software engineering, but time has proven that web service is a viable technology to implement SOA.

Providers and consumers agree to a common interface called Web Services Description Language (WSDL) in SOA using web services. Data is exchanged normally through HTTP protocol, in Simple Object Access Protocol (SOAP) format.

WSDL

There are mainly two approaches in working with WSDL: * Start from WSDL, create and host the web service and open the service for clients; tools like wsdl2java help us to do this. * Start from the types already available, generate the WSDL and then continue; tools like java2wsdl help us here.

JBI is based on WSDL.

SOAP

Service Oriented Integration (SOI)

JBI in J2EE - How they Relate

The Java 2 Enterprise Edition (J2EE) platform provides containers for client applications, web components based on servlets and Java Server Pages (JSP), and Enterprise JavaBeans (EJB) components. These J2EE containers provide deployment and run-time support for application components. They also provide a federated view of the platform-level services, provided by the underlying application server for the application components.

Servlets, Portlets, EJB, JCA, and so on

JBI and JCA - Competing or Complementing

J2EE Connector Architecture (JCA) defines standards for connecting the J2EE platform to heterogenous EIS systems.

JBI - a New Standard

Integration is not that simple as it involves integration architectures, integration patterns, and MOM expertise. We need to build the extra intelligent adapters around services and endpoints. These adapters are to work in tandem with the platform provider to give low-level features like communication, session, state, transport, and routing. Thus, business integration is not limited by just application programming, but involves components and engineering processes at the application and platform interface-level. Hence, to make integration artifacts portable, even the integration vendors (who deal with platform services) have a big part to play. This is where we need standardization as components and adapters should be portable across several vendor products.

JBI in Detail

JBI provides a collaboration framework which provides standard interfaces for integration components and protocols to plug into, thus allowing the assembly of SOI frameworks.

JSR 208

JSR 208 is an extension of J2EE, but it is specific for JBI Service Provider Interfaces (SPI). SOA and SOI are the targets of JBI and hence it is built around WSDL. Integration components can be plugged into the JBI environment using a service model based on WSDL. Service composition is a major target in ESB architecture and the JBI environment aggregates multiple service definitions in the WSDL form into the message infrastructure.

JSR 208 mandates the following for JBI components: * Portable: Components are portable across JBI implementations. * Manageable: Components can be managed in a centralized manner. * Interoperable: Components should be able to provide service to and consume services from other components, despite the fact that they come from different sources and transport protocols.

JBI Nomenclature

The major components are explained: * JBI environment: a single Java Virtual Machine (JVM) where we can deploy integration artifacts.

* Service Engine (SE): SEs are service providers or service consumers deployed locally within a JBI environment. They provide the actual business logic like transformation.

Business Process Execution Language (BPEL)

* Binding Components (BC): BC provide communications protocol support and they are normally bound to components deployed remotely from the JBI run time.

The distinction between SE and BC is important for various pragmatic reasons. Mainly, it separates service logic from binding protocol. This facilitates reusability.

* JBI Container: Similar to the container in an application server , a JBI environment by itself a JBI container. This container hosts SE and BC. The interesting part is a SE is again a container for engine specific entities like XSLT engine, stylesheets, rules engines, and scripts.

* Normalized message: A normalized message consists of two parts - the actual message in XML format, and message metadata which is also referred to as the message context data.

* Normalized message router (NMR): The nerve of the JBI architecture is the NMR. This is a bus through which messages flow in either direction from a source to a destination. The specialty of this router is that messages are always in a normalized format, irrespective of the source or destination. NMR thus acts as a lightweight messaging infrastructure which facilitates actual message exchange in a loosely coupled fashion. NMR provides varying QOS functionalities: Best effort; At least Once; Once and only once.

* Pluggable components: The loosely coupled feature of ESB is due to the pluggable architecture for service components. There are two broad categories of pluggable components called SE and BC. Pluggable components can play the role of service provider, service consumer, or both. Pluggable components are connected to the NMR through a Delivery Channel.

* Service providerse and service consumers: Components can act as both a provider and a consumer at the same time. Service definition is available in the form of WSDL and this is the only shared artifact between providers and consumers.

* Delivery Channel (DC): DC connects a message source and a destination. The messaging infrastructure or the NMR is the bus for message exchange for multiple service providers and consumerse. When a service provider has got information to communicate, it doesn't just fling the message into the NMR, but adds the message to a particular DC. Similarly, a message consumer doesn't just pick it up at random from the messaging system. Instead, the consumer receives the message from a particular DC.

DCs are logical addresses in the ESB.

Provider-Consumer Contract

In the JBI environment, the provider and consumer always interact based on a services model. A service interface is the common aspect between them. WSDL 1.1 and 2.0 are used to define the contract through the services interface.

Detached Message Exchange

Provider and Consumer never interact directly. In technical terms, they never share the same thread context of execution. Provider and Consumer use JBI NMR as an intermediary. Consumer sends a request message to the NMR. The NMR, using intelligent routers decides the best matched server provider and dispatches the message on behalf of the Consumer.

Provider-Consumer Role

When a binding acts as a service Provider, and external service is implied. When a binding acts as a service Consumer, an external Consumer is implied.

Message Exchange

Message exchange encapsulates the following: * Normalized message * Message exchange metadata * Message exchange state

Message exchange is the JBI local portion of a service invocation.

Service Invocation

An end-to-end interaction between a service consumer and a service provider is a service invocation. Service consumers employ one or more service invocation patterns. Service invocation through a JBI infrastructure is based on a 'pull' model, where a component accepts message exchange instances when it is ready.

Message Exchange Patterns (MEP)

There are many service invocation patterns, and, from a JBI perspective, any JBI-compliant ESB implementation must support the following four service invocations: * One-Way * Reliable One-Way * Request-Response * Request Optional-Response

ESB - Will it Solve all Our Pain Points

An ESB is not required to build an SOA, nor is JBI required for ESB or SOA. However, all of them have something in common using JBI. JBI by itself is one of the ways by which we can attain SOA. There is also a caveat to this—just following JBI or ESB will not guarantee that you attain SOA.

Summary

JBI is the new integration API introduced in the J2EE world. It is a great enabler for SOA because it defines ESB architecture, which can facilitate the collaboration between services. It provides for loosely coupled integration by separating out the providers and consumers to mediate through the bus.