간단한 JBI 설명

간단해서 보기 좋다. JBI-A standard-based approach for SOA in Java

By Mareej Kinnumpurath 13 Dec 2005 | TheServerSide.com

The industry has witnessed the evolution of a wide range of solutions addressing the problem space of B2B and enterprise application integration (EAI). These solutions varied from proprietary message oriented middleware to standard JMS based solutions and web services. This paper provides a brief introduction to the upcoming JBI (Java Business Integration) standard in relation to SOA (service-oriented architecture) principles and the ESB (Enterprise Service Bus) infrastructure.

Service Oriented Architecture

SOA (service-oriented architecture) is one of the latest developments that have made a huge leap in the area of application and business integration. SOA defines a set of well-defined architectural principles, paradigms and best practices to enable loosely coupled interaction between applications.

SOA promotes loosely coupled interaction between participating applications based on well-defined interfaces. Service implementations are self-contained and don’t depend on the contextual information and state of other services. Service interactions are mainly based on exchanging document-style data, defined using a standards-based messaging model. The services themselves are agnostic to the transport level interactions required to enable the communication between the service provider and service consumer.

Even though not a mandatory requirement, most of the modern SOA based systems utilise web services and related technologies for providing the required plumbing for the interactions between services. WSDL (Web Services Definition Language) is used as the main artefact for representing messaging models; SOAP as the message representation protocol and HTTP as the wire-level transport protocol. This doesn’t mean you always need to use the aforementioned technologies for implementing systems based on service-oriented architecture. Lot of enterprises have used similar architectures for realising loosely coupled systems, well before any of these buzzwords came into existence. However, the key difference is that now we have standards-based protocols, toolsets and software for enabling service oriented architecture.

SOA principles are significantly different from object-oriented paradigms and principles. The key difference is that the interactions between services are defined using interfaces that are oriented more towards data than behaviour. A service in isolation may be realised using object-oriented principles and techniques, however, the interactions between the services seldom use any of these techniques. Rather, these interfaces are geared more towards document-based interchanges. Where object-orientation binds behaviour closer to data, service-orientation decouples data from behaviour.

Enterprise Service Bus

An ESB (Enterprise Service Bus) provides the infrastructure for realising service-oriented architecture. ESBs provide a runtime environment for deploying and enabling your services augmented with design-tools for defining the interaction and orchestration of the services.

In the ESB world the services don’t directly interact with each other. Rather, the ESB runtime acts as a mediator between the services to loosely couple them. The ESB runtime would implement protocol bindings, message translation, message handling etc.

The key services provided by an SB would include:

• Providing transport bindings for the services
• Providing definition and discovery of the deployed services
• Rules based routing and orchestration of messages between services
• Value added services including document transformation etc

Most of the ESB vendors base their SOA proposition on open standards and technologies including the various web services standards and protocols. They provide a variety of transport bindings for invoking the services including HTTP, FTP, and JMS etc. Most ESBs use WS-BPEL (Business Process Execution Language for Web Services) for realising orchestration between the deployed services for implementing business processes. ESB vendors also provide quality of service features including fault-tolerance, failover, load balancing, message buffering etc.

Java Business Integration

JBI (Java Business Integration) is a Java-based standard addressing the EAI and B2B issues based on the paradigms and principles advocated by service-oriented architecture. The current version (1.0) is finalized through the JSR (Java Specification Request) 208 in August 2005. Both commercial and open source worlds have already started embracing JBI as an integration standard in their ESB products.

Mediator-based Architecture

JBI defines a plug-in based architecture where services can be plugged into the JBI runtime environment. JBI provides well-defined interfaces for services to interact with the JBI runtime environment. The services need to expose interfaces to the JBI runtime environment for the JBI runtime environment to route messages to the services. The JBI runtime environment acts as a mediator between the services that are deployed in the environment.

The JBI runtime core mainly comprises of the following components within the same JVM:

• Component framework: The component framework enables the deployment of the different types of components within the JBI runtime.
• Normalized Message Router: Normalized message router enables a standard mechanism of message interchange between the services.
• Management framework: The management framework based on JMX enables the deployment, management and monitoring of components within the JBI runtime.

Component Model

JBI defines two types of components in the JBI runtime environment,

• Service Engine Components: These are components responsible for implementing business logic and other services. The SE components can internally be realised using various technologies and design principles. SE components can be as simple as a component that provides low-level services like data transformation and translation or something more convoluted as a WS-BPEL instance that models an intricate business process.
• Binding Components: Binding components are mainly used to provide transport level bindings for the deployed services. BC components can be of a variety of types including,
  • Enabling remote communication with external systems using standard transport protocols.
  • Enable in-VM invocation between two services deployed in the same JVM.
  • Enable communication between services using standard WS-I (Web Services Interoperability) profiles.

The key aspect of JBI is the decoupling of the service engine and binding components so that business logic is not infested with the infrastructure details required for invoking and consuming services. This promotes a flexible and extensible architecture. Both BC and SE components within JBI can be service providers and/or service consumers.

Both BC and SE components provide interfaces to the JBI runtime for accepting messages from the JBI runtime. Similarly, they use interfaces provided by JBI for communicating with the JBI runtime.

Messaging Model

JBI uses a messaging model that decouples the service consumers from the service providers. The messaging model is defined using WSDL. WSDL is used to describe the operations exposed by both SE and BC components. WSDL is also used to define transport level bindings for the abstract service operations.

One of the key components used in the JBI architecture is NMR (Normalized Message Router). NMR provides the main messaging spine built around WSDL, which provides the loosely coupled message exchange between the SE and BC components deployed within the JBI runtime. Services are required to have interfaces, which are an aggregation of operations. Each operation is composed of zero or more messages. An interface can have one or more transport level bindings.

JBI uses a normalized format for representing messages within the runtime. A normalized message is composed of the following parts,

• Message properties
• Message payload
• Message attachments

The JBI specification provides standard interfaces for the service consumers and providers for exchanging messages with the NMR. NMR supports both one-way and request-response semantics for service invocation between consumers and providers.

Management

JBI uses JMX for the runtime installation, configuration and monitoring of services. The services are required to implement a set of JBI interfaces to make them manageable in the JBI environment. The JBI environment is required to provide a set of JMX MBeans to enable the management of the JBI runtime.

The JBI runtime environment allows the following operation related to the SE and BC components,

• Installation of components: This will make the component interface available to the normalized message router.
• Installation of component artefacts: This will allow deployment of component artefacts required for the functioning of installed components. For example, this could be deploying the connection details required to connect to a database for a deployed service that requires connecting to the database.
• Starting and stopping of services and groups of related services.

JBI defines standard deployment descriptors and packaging models for both components and component artefacts.

Roles

JBI identifies the following roles for providing an end-to-end JBI based EAI solution,

• Engine developers: Engine developers are required to provide the SE components that adhere to the NMR and management contracts.
• Binding developers: Binding developers provide the binding components that adhere to the NMR and management contracts.
• JBI Environment providers: JBI environment providers are required to support the JBI runtime using either J2EE 1.4 or J2SE 1.4 r newer platform.
• J2EE Platform providers: J2EE platform providers may include a JBI runtime as part of their application server offerings.
• JBI Application developers: JBI developers build JBI applications using the SE and BC components and the JBI environment.

Conclusion

With the whole industry aligning more and more towards open standards and specifications, JBI takes a great leap in enabling Java technologists adopting a standards-based approach in addressing integration issues using service oriented architecture and ESB infrastructure. Both commercial vendors like Oracle and open source software like ServiceMix have already started adopting JBI as part of their ESB offerings.

About the Author

Meeraj Kinnumpurath works as a Java architect with VOCA Ltd (formerly BACS), who are the largest clearing house in Europe. He has been using Java for the past eight years, developing enterprise applications. He has also published a few books on Java, J2EE and Web Services.