<Hossam Karim>
AFAIK, JBI does not define any specific XML document format.
</Hossam Karim>

A JBI normalized message is an XML document. A typical JBI normalized message consists of two parts:
1. Message metadata – Also known as the message context data, the message metadata includes context information such as:

• Protocol-supplied context information
• Security tokens
• Transaction context information
• Data specific to other components

2. Message payload – The message payload is a generic source abstraction that contains all the message data. The payload conforms to an abstract WSDL message type (see FIGURE 3 in the whitepaper http://java.sun.com/developer/technicalArticles/WebServices/soa3/index.html), with no protocol encoding or formatting.

<Hossam Karim>
- Can the engine invoke other SEs and BCs through the NMR based on their service descriptions (WSDLs) just like invoking web services?
</Hossam Karim>

Any JBI component deployed on a JBI environment, be it a Service Engine or a Binding Component, can invoke each other JBI components deployed in the JBI environment through the JBI NMR. The messages exchanged are JBI Normalized messages. Please see that same whitepaper at http://java.sun.com/developer/technicalArticles/WebServices/soa3/index.html.

<Hossam Karim>
What if an output message of a consumed service is not a SOAP message?
</Hossam Karim>

All messages that flow through inside the JBI environment are JBI Normalized messages. In a JBI environement, both remote access outside the JBI environment and protocol independence is provided by JBI Binding Components. The BCs consume protocol-specific message data, convert it into a JBI specified Normalized Message and hands it off for consumption by the NMR. Similarly, it picks up the JBI Normalized Message, "Denormalizes" the message into a protocol specific message and sends it back to the consuming client. This allows any JBI Component to communicate over any protocol or transport (SOAP, JMS, File, SMTP, etc.) as long as a BC that handles the particular transport or protocol is plugged-in into the JBI meta-container. This eliminates the need to implement those protocols in your business logic, and enables a loose-coupling by decoupling the service implementation from the access mechanism. Please see that same whitepaper at http://java.sun.com/developer/technicalArticles/WebServices/soa3/index.html.

Posted by Gopalan Suresh Raj on June 25, 2006 at 04:56 AM PDT #

<Hossam Karim>
The document is absolutely wonderful, it is the reason I am actually here:),
</Hossam Karim>

Thanks Hossam.
I am glad that you liked it.
The following post also references the same document at http://java.sun.com/developer/technicalArticles/WebServices/soa3/index.html heavily.

<Hossam Karim>
For example, can I deploy just a BPEL XML document so that the engine would invoke a web service, receive the reply, invoke a transformation JBI service engine and finally write the output to an out box through a file binding engine?
</Hossam Karim>

The WS-BPEL SE only knows how to talk to the JBI NMR though the delivery channel available to the WS-BPEL SE. However, the JBI NMR knows how to route messages based on the <service-connections/> deployment descriptor deployed during project deployment. Each consumer declares in its service unit metadata, its expectations concerning how service connections are to be applied to it when it consumes a particular service. This is termed provider linking in JBI parlance.

<Hossam Karim>
More precisely, can the engine do both HTTP posts and delivery channel operations transparently?
</Hossam Karim>

Let's take the example you provided that a request comes in through HTTP/SOAP (through a HTTP/SOAP BC consuming endpoint), starts a process in a WS-BPEL service unit (deployed on a WS-BPEL SE), then invokes an external service through HTTP/SOAP (through a deployed HTTP/SOAP BC), then invokes a transformation (deployed on a Transformation SE), and then writes it out to a file (using a File BC).

At deployment time:

The HTTP/SOAP Binding Component will find and read the HTTP/SOAP Service Unit jbi.xml and locate the WSDLs which have a <soap:address/> extensibility element, with all the associated information for the external endpoint names provided. It will activate all its <provides> (outbound) endpoints. For its <consumes> endpoints, it will start a HTTP server on the port provided in the soap address.

When the WS-BPEL Service Unit gets deployed to the WS-BPEL Service Engine, it will also read the WS-BPEL Service Unit jbi.xml and activate its endpoints (named after the partner link/role) for the <provides>, and find all matching artifacts (WS-BPEL) associated with these partner links/roles.

When the Transformation Service Unit gets deployed to the Transformation Service Engine, it will also read the Transformation Service Unit jbi.xml and activate its endpoints.

The File Binding Component will find and read the File BC Service Unit jbi.xml and locate the WSDLs which have a <file:address/> extensibility element, with all the associated information for the external endpoint names provided. It will activate all its endpoints based on the attributes of the <file:address/> extensibility element.

The JBI Framework reads the <service-connections/> element in the Service Assembly jbi.xml deployment and places this information in it's internal Routing table.

At runtime:
For the inbound HTTP/SOAP request, when a request arrives at that port that matches the context in a soap address, the Binding Component Normalizes the message into a JBI Normalized message and sends the message to the NMR giving the <consumes> service/endpoint details, which in this case is the same as the external endpoint details.

The JBI NMR will consult its internal routing table and route it to the WS-BPEL SE. The WS-BPEL SE receives this JBI normalized message, executes the process and then the invoke to an external remote HTTP/SOAP provider is encountered. It sends the request as a JBI Normalized message to the JBI NMR. The JBI NMR receives the JBI normalized message and routes it to the HTTP/SOAP BC. The HTTP/SOAP BC Denormalizes the message and sends it to the external remote service provider. Once the HTTP/SOAP BC receives the reply, it once again Normalizes the reply back and sends the JBI Normalized message to the JBI NMR. The NMR sends it to the WS-BPEL SE. The WS-BPEL SE resumes its process and encounters the invoke to the Transformation. The WS-BPEL SE sends the request to the NMR. The NMR routes it to the Transformation SE through the assigned delivery channel. The Transformation SE transforms the message and sends the reply back to the NMR. The NMR routes it to the WS-BPEL SE. The WS-BPEL SE proceeds with the process and then encounters the invoke to the File BC. It sends the request to the NMR. The NMR sends the JBI Normalized message to the File BC. The File BC Denormalizes the message and writes it out to the file.

So as you can see, all message interchange within the JBI environment requires no marshaling/unmarshaling as all the messages are standard JBI Normalized Messages. It is only where the message has to flow outside of the JBI environment, the message is converted to the appropriate format by the particular Binding Component and sent out.

So yes to answer your question, to the WS-BPEL SE, an invoke to an external Service outside of the JBI environment will look the same as an invoke to a service within the JBI environment since the only messages that an SE deals with are JBI Normalized messages. For external remote calls going out of the JBI environment, it is the responsibility of the BCs to convert them to the appropriate protocol or transport format. Any message going through the NMR and flowing within the JBI environment are pure JBI Normalized messages.

Posted by Gopalan Suresh Raj on June 25, 2006 at 05:37 PM PDT #