Service Component Architecture Meets Java EE: A Work in Progress (Part 2 of 2)
If you’ve read Service Component Architecture Meets Java EE: A Work in Progress (Part 1 of 2) of this blog, you should have a conceptual framework for understanding how Service Component Architecture (SCA) assembly works in a Java Enterprise Edition (Java EE) context. In this blog I’m going to show you a simple example that illustrates these concepts and guides you through the construction process. This scenario is introductory, and it does not yet include additional technologies beyond Java EE, such as BPEL.
The goal is to take this application and assemble it on the domain level with another application. First, a Web Component is going to be exposed via a special deployment composite to the domain. The domain then will have its reference wired via another domain level component to a service implemented by an EJB. That sounds complicated, but I’m going to show you how easy it is using the SCA framework we’ve created. The following scenario should be readily implementable by Java developers.
Here’s the overview graphic.
On the right side we have a composite with a SCA service component that is implemented by an EJB Session Bean. The service component is named
and it has a service called
, which is represented by the green chevron. That service was actually derived from the bean’s business interfaces according to the component type derivation rules for the implementation type for session beans.
Now it’s time to define the right
, so as to include the composite into the domain. Simply declare the composite as a deployable composite, which means it is now included into the domain. Now this service component and its services will be exposed in the domain.
Let’s go back to the overview shown above.
On the left side we see an application that has a Web module with a few references. We assume that at least one of those references is not supposed to be exposed to the domain. Instead it may be wired up with some other service component (e.g. a BPEL implementation) at a later point in time.
We create an application composite, from scratch actually, and this application composite contains one service component called web that’s implemented by the Web component. Web Components are somewhat special, since they can be instantiated only once: unlike a Session Bean a Web component is bound to an external resource, a URL. You cannot configure the references of a Web component twice because when you put the URL into your browser you cannot tell from the given URL what reference you want to use – there can only be one.
The application composite is the root of our assembly for the application. Regardless of any domain exposure, this is where SCA assembly is applied.
As with the Session Bean above, there is some automation at work. The introspection is done by the implementation of
. As implementor of the web component, we know that it has a reference called
. It is not necessary to repeat the reference declaration. We declare a reference AccountReporting on the composite which is a promotion of the reference of the Web component. This is illustrated by the two chevrons with the dashed line in between them.
Now bring it all together.
as deployment composite will include the component that wrapped the application composite constructed about into the domain.
The reference declared in the included composite will be wired up with its target service component that was put to the domain from the app at the right side.
There is a lot more to discuss of course and we did hardly touch on how to package the applications and much more.
A more complex scenario (that should look familiar to attendees of our technical session TS-41500 at JavaOne 2007 – available at JavaOne Online) will be described in another blog soon.