Jun Qian (钱骏) 's Weblog

Anatomy of Composite Application in NetBeans 6.0 SOA Pack (Part 3)

Service Endpoint

In Part 2 of this series, I briefly talked about Service Endpoints defined by Service Units. A Service Endpoint is basically an addressable entity in the JBI system. The following graph shows a Service Unit (targeted at the BPEL Service Engine) that provides a service at Endpoint "parnerlinktyperoleClient_myRole" and consumes a service at Endpoint "parnerlinktyperole1_parterRole". The names you see here are the endpoint names.

 

Note that the endpoint name by itself is not enough to uniquely identify an Endpoint in a JBI system. To avoid name conflict, a fully qualified endpoint name is needed. The following shows an example of the fully qualified endpoint name:

 

A fully qualified endpoint name uniquely identifies a service endpoint in a JBI runtime. There can't be two endpoints that share the same fully qualified endpoint name (either in the same JBI Component or different JBI Components) inside one JBI Meta-Container.

You already know there are Consume Endpoint that consumes service and Provide Endpoint that provides service. Based on the endpoint's accessibility, endpoints can also be categorized into Internal Endpoint and External Endpoint.

Internal Endpoints are private endpoints inside the JBI runtime and they are not accessible from outside of the JBI runtime. In the Composite Application Service Assembly (CASA) Editor, Internal Endpoints are the C/P pins in the "JBI Modules" region (and the "External Modules" region, which will be explained later in the series).

External Endpoints correspond to concrete WSDL Port elements defined in WSDL files. They are public endpoints accessible from both inside and outside of the JBI runtime. The C/P pins in the "WSDL Ports" region are External Endpoints.

The External Endpoint needs a little bit more explanation.

In the above example, the C and P in the "WSDL Ports" region actually represent one endpoint ("portClient") because they have the same fully qualified endpoint name. The SOAP address for this endpoint, or WSDL Port, is something like "http://localhost:18181/SynchronousSampleClient". In this composite application configuration, a SOAP client can access the BPEL service at this SOAP address. As part of the service it provides to the SOAP client, the BPEL service consumes a private XSLT service. The XSLT service is private because its service endpoint is not accessible from outside the JBI environment.

In the next configuration, a new External Endpoint ("casaPort1") is added to expose the XSLT service to the outside world. A new SOAP address is associated with this new web service.  Now any SOAP client can access the XSLT service directly at this new address.

 

In the third configuration, we tweak the connection between the BPEL Service Unit and XSLT Service Unit a little so that instead of directly talking to the private Provide endpoint through the Normalized Message Router inside the JBI runtime, the BPEL service invokes the XSLT service through its public web service interface we introduced in the previous configuration. This call is obviously more expensive now because the message goes out of the JBI environment and comes back again and it involves the whole WS-* stack.

 

As you can see, the CASA Editor makes it so easy to modify composite application project configuration that even Grandma can do it now. Well, maybe not. ;-)

Posted at 01:36AM May 02, 2007 by Jun Qian in NetBeans  |  Comments[0]