SOA.WRK.

Composite Application - Part 2, Service Component Model

In part 1 of this series, a brief definition of JBI component was given:

"A component in JBI is a logical service defined by one or more WSDLs. It interacts with components in other containers via operations/messages specified in WSDLs."

1.component.interface + implementation

We will provide a more detailed description of the service component model used in the composite application projects. In our model, a component has:

• An interface definition specified by an xml-based descriptor file, jbi.xml (of service unit). The descriptor specifies provides (input) and consumes (output) endpoints of the component. The endpoints are typed using portType (WSDL 1.1) or interface (WSDL 2.0) defined in a WSDL. An example of the jbi.xml file is shown below:

  <jbi ... version="1.0">
    <services binding-component="false">
      <provides endpoint-name="partner" interface-name="ns1:portType1" 
                service-name="ns0:SynchronousSample"/>
    </services>
  </jbi>

• An implementation consisting of deployment artifacts needed by the specific component container. For example, a typical BPEL component deployment artifact is a jar collection of BPEL sources and associated WSDL, XSD, and other data files.

2.component.composition

Components can be composed by connecting endpoints from one component to another. The connection is specified in an application level descriptor file, jbi.xml (of service assembly). An example of the connection specification is show below:

<connections>
  <connection>
    <consumer endpoint-name="port1"   service-name="ns1:service1"/>
    <provider endpoint-name="partner" service-name="ns2:SynchronousSample"/>
  </connection>
</connections>

Given a set of components, the composite application project system can auto-generate most of the necessary connections by matching the consumes and provides endpoint type. We also provide a GUI-based Composite Application Service Assembly (CASA) editor for editing component connections.

3.component.model.comparison

A frequently asked question is how our component model compares to other SOA component models, e.g., Service Component Architecture (SCA) . There are some minor differences, but overall the two models are very similar. For example, if we replace terms in the SCA component diagram shown below by the corresponding JBI terms, the diagram very much describes the composite application component model.

        CompApp Model     SCA Model
             consumes <-> reference
             provides <-> service
           connection <-> wire

One can consider our component model equivalent to the SCA model restricted to WSDL based interfaces. SCA supports two interface types:

• Java interfaces
• WSDL 1.1/2.0 interfaces

Most people consider WSDL as the de facto specification for SOA interfaces, but it is less obvious to think Java as a SOA interface. SCA did, but we did not. As the result of this difference, the SCA model has to address more issues that do not exist in ours.

Posted at 07:33AM Mar 07, 2007 by tientienli in Sun  |