Jun Qian (钱骏) 's Weblog

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

In the first installment of this Composite Application mini-series, I gave a brief overview of Composite Application and JBI Runtime. In this installment, I will talk about the relationship between a Component Project and a Composite Application Project in NetBeans, and also take a closer look at Service Assembly.

Component Project vs. Composite Application Project (CompApp)

In order for a Component Project (a.k.a. JBI Module) to provide a composable service and participate in a Composite Application, the Component Project needs to provide the following information:

• a list of service Consume/Provide Endpoints (more on this later),
  
• the name of the target JBI Component (specifically, a Service Engine) where the service will be deployed to.

Besides this basic contract between a Component Project and a Composite Application Project, the Component Project can do whatever it wants. The Composite Application Project doesn't know and doesn't need to know anything (except for the WSDL files, of course) about the internals of its Component Projects. The corresponding Service Engine at runtime is the only one that needs to understand the files packaged in the Component Project's build artifact.

Typically, for each type of Service Engine in the JBI runtime, a corresponding design-time component project type is needed. For example, for BPEL Service Engine, there is a BPEL Project type at design-time; for XSLT Service Engine, there is a XSLT Project type. Those design-time project types provide support to create, edit, build and validate the component project instances.

You might be wondering about the Binding Components in the JBI runtime. Fortunately, you don't need to worry too much about them and there is no need to define a separate project type for each Binding Component. Composite Application Project System automatically introspects all the WSDL files defined in both the constituent component projects and the composite application project itself and creates the necessary Binding Component Service Units for you.

A Closer Look at Service Assembly

In the first installment, I introduced Service Assembly (SA), the build artifact of a composite application project, and Service Unit (SU), the individually deployable units inside a Service Assembly. I also showed a logical view of the Service Assembly. Now, I am going to show you a Service Assembly logical view along with its detailed file view.

An SESU / BCSU is a Service Unit that will be deployed to a Service Engine / Binding Component in JBI runtime. An SESU jar file (BpelModule.jar, for example) comes directly from the corresponding component project. It is the build artifact of the component project. A BCSU jar file (sun-http-binding.jar), on the other hand, is generated by the Composite Application Project System.

As you can see, each SU jar file contains a Service Unit descriptor (SU jbi.xml) that describes the service endpoints defined in that Service Unit. The Service Assembly also contains a top-level descriptor (SA jbi.xml) that describes the connections among the service endpoints defined in all the Service Units inside the Service Assembly. When you build a Composite Application Project, the Project System automatically generates a default connectivity map based on the interfaces of the endpoints. You can view/edit the connectivity map using the Composite Application Service Assembly (CASA) Editor in NetBeans 6.0 SOA Pack.

Next time, we will take a look at Service Endpoint.

Posted at 12:52AM Apr 20, 2007 by Jun Qian in NetBeans  |  Comments[0]