Java Business Integration

What is the Need ?

• Use of Non-Standard Technologies to create Integration Solutions resulting in Vendor Lock.

How does JBI Solve this problem ?

• JBI Creates a Standards Based Architecture for Integration Solutions.
• Third Party Components are assembled by the End User.
• These Components are allowed to inter-operate predictably and reliably.
• User is free to chose components that address certain functionalities, and then assembled to provide an end to end solution.
• The Assembling is done through a Service Oriented Architecture, that enables decoupling of components, and creates well defined intereroperation semantics based on standards based messaging.

What does JBI Provide ?

• JBI Provides a standards based framework into which components from different vendors can be plugged in. [rather than having separate dedicated connections between disparate applications from various vendors]
• The Services that the Component expose are descrived using WSDL 2.0

What are the different categories of components that can be plugged in ?

• The Service Engine [SE]
• The Binding Component [BC]

In Summary, what do these components do ?

The Service Engine is used for Business Logic and Transformation Needs, whereas Binding Components are used for Connectivity.

What do we gain from having described services using WSDL ?

• Decoupling [Provider-Consumer Decoupling]
• Portability [Description is independant of implementation]
• Interoperability [Through Definition of XML Based Message Exchnage]
• A Service Oriented Architecture

How does a JBI Environment look like ?

The JBI Environment is where the Plugin components reside. The Environment provides the following services.

• Execution of Services
• Component Interaction [Through Message based Service Invocation] Note that JBI uses an Abstract Service Model as the basis of Component interaction. i.e. [Abstract Service Model means definition of service without reference to protocols or wire encoding]
• Overall System Management [Lifecycle and installation Management Services]

How does a Message within the JBI Environment look like ?

Only Normalized Messages travel within the JBI Environment. Normalized Messaged have two parts.

• Abstract XML Message
• Message Metadata [used by System and plugin components]

Can a JBI Environment span over multiple Virtual Machines?

No.

How would a detailed list of components within a JBI Environment contain ?

• SE Framework [Containing the Different SEs]
• The NMS [For providing the Mesage and Control interaction infrastructure]
• The BC Framework containing the WS-I BC and optionally, other BCs

So JBI Provides SEs or the Frameworks for the SEs?

JBI defines the frameworks that provide the pluggable infrastructure for adding SEs and BCs.

What about the Message Exchange within the environment ?

Its WSDL messaging all the way. Inbound Service Requests are received by the BCs, routed by the NMS, and delivered to an SE. An Outbound Service Request is generated by an SE, routed by an NMS, and delivered to a BC.

The BC itself is describes as an inbound WSDL endpoint [ The WSDL 2.0 definition of a Port]. All outbound messages from the SE define the outbound destination as an abstract service name. The NMS plays the responsiblity to route the outbound message to the appropriate BC.

What are the other infrastructure within the JBI Environment ?

The JBI environment also has services for life cycle management, environmental inspection, administration and reconfiguration, for relaiable operations.

In Simple terms, how would a simple Message Routing lifecycle look like ?

• Service Consumer sends service request bound to a particular protocol and transport to BC.
• BC converts request to normalized form [ as per WSDL Model]
• Normalized message is sent to NMS by the BC
• NMS Routes the Message to the appropriate SE
• SE Creates a Normalized Message, requesting a Service to be performed by a service references by its WSDL Service Name
• BC denormalizes the Message into protocol and transport format, and sends the message across the wire to the service provider.

Web Service Profiles - An Introduction

• What is the need ?

The Basic Specifications for Web Services are already in place - the ones for service description, discovery, and invocation.[Specifications for SOAP 1.2, WSDL 1.1, UDDI 2.0] With these small subset of specifications, its not tough to keep track of Products and their degree of support for these specifications. But there is plenty to be done for several other aspects that would realise the Web Service vision. These include

• Extensibility
• Binary Attachments
• Routing
• Correlation
• Guaranteed Message Exchange
• Signatures
• Encryption
• Transactions
• Process Flow
• Inspection
• More . . . . .

Each of these would be captured in a particular specification. With different versions of these interrelated specifications, it is difficult to know which product complies with which version of a specification. This could lead to chaos.

• What is the Solution

The Solution if by the usage of "Profiles" - which are nothing but a named group of Web Service Specificaitons at specific version levels, along with conventions as to how they work together. WS-I will develop a set of core collection of Profiles that support interoperability for general purpose Web Service functionality.

Some important points here to note:

• Profiles make it easier to discuss Web services interoperability at a level of granularity that makes sense for developers, users, and executives making investment decisions about Web services and Web services products. WS-I focuses on compatibility at both the individual specification and at the Profile level.
• To be a useful concept and avoid confusion, the number of Profiles should remain relatively small.
• Despite the best intentions of the standards authors, there may be ambiguities or areas that are so under specified that interoperability becomes difficult. A specification might also be of such a general nature that further conventions or recommended practices are necessary for interoperability. Therefore, in addition to the list of specifications or standards, a Profile may also contain one or more documents that resolve ambiguities or make recommendations for common usage. Such documents may apply to an individual Web service specification, or may pertain to how multiple specifications should work together.
• What is WS-I Basic Profile?
  Through the first phase of Web services adoption, four specifications have risen to prominence as providing the basic functionality required to start developing Web services. These specifications are XML Schema 1.0, SOAP 1.1, WSDL 1.1, and UDDI 2.0. The first profile proposed is WS-I Basic Web services.

Whats new in WSDL 2.0 on XML.com

WSDL 1.2 was renamed WSDL 2.0 because of its substantial differences from WSDL 1.1.

Some of these changes include:

• Adding further semantics to the description language. This is one of the reasons for making targetNamespace a required attribute of the definitions element in WSDL 2.0.
• Removal of message constructs. These are specified using the XML schema type system in the types element.
• No support for operator overloading.
• PortTypes renamed to interfaces. Support for interface inheritance is achieved by using the extends attribute in the interface element.
• Ports renamed to endpoints.

What is AS2

AS2 (Applicability Statement 2) is a specification for Electronic Data Interchange (EDI) between businesses using the Internet's Web page protocol, the Hypertext Transfer Protocol (HTTP). The specification is an extension of the earlier version, Applicability Statement 1 (AS1). Both specifications were created by EDI over the Internet (EDIINT), a working group of the Internet Engineering Task Force (IETF) that develops secure and reliable business communications standards.
The AS2 standard provides Secure Multi-Purpose Internet Mail Extensions (S/MIME) and uses HTTP or a more secure version, HTTPS, to transmit data over the Internet. AS1 uses a slower protocol, SMTP (Simple Mail Transfer Protocol). The use of HTTP or HTTPS allows communication in real time rather than through e-mail delivery. Security, authentication, message integrity, and privacy are assured by the use of encryption and digital signatures. Another important feature, nonrepudiation, makes it impossible for the intended recipient of a message to deny having received it.
The AS2 standard allows businesses to use a common, single communications solution. This eliminates the complications and costs involved when different businesses in a network use different transfer protocols. A Web server, an EDI transfer engine, and digital certificates are required for data exchange using AS2. Almost any type of data can be transmitted.