Dashboard > Open SOA > ... > The Assembly Model > Recursive Assembly Model > Information > Page Comparison
Log In   View a printable version of the current page.
Open SOA
Recursive Assembly Model
Version 19 by Mike Edwards (IBM)
on Mar 19, 2007 08:30.

<< Changes from 18 to 19
compared with
Current by Mike Edwards (IBM)
on Mar 19, 2007 08:33.
(show comment)
 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 1 changes. View first change.

  h1. Recursive Assembly Model
  
 The SCA collaboration got a lot of feedback both from within and outside suggesting the need to further simplify the SCA assembly model. From the feedback it was clear that making the SCA assembly model fully *{_}recursive{_}* would be key to achieve further simplification.
  
 *_"Recursive"_* basically means that assemblies can be nested inside other "higher-level" assemblies. Having a fully recursive assembly model promotes the reuse of assemblies. It also allows for successive decomposition of service implementations in top-down design of solutions.
  
 In the [SCA V0.9 assembly model specification|Main:SCA - Previously Published Specifications^SCA_AssemblyModel_V09.pdf], a module contained amongst other things a set of components that were implemented by "atomic" component implementations, e.g. Java POJO, BPEL process, and so on. There was no support at the module assembly level for components that were implemented by another assembly.
  
 Looking at the system assembly level, the V0.9 specification had components that were implemented by modules. But instead of naming them just components they are named module components, and they had no extensible implementation type concept as existed for components at the module assembly level.
  
 So, in the SCA 1.0 Assembly model, three things have been done to simplify the model:
 # have only components independent of which level of the assembly hierarchy is involved
 # components can either be implemented by simple implementations or by assemblies
 # give a name to assemblies that does not use the term "module" or "system": *{_}composite{_}* is the name chosen.
  
 Allowing components to be implemented by simple implementations or by composites opens some further opportunities for simplification. Both atomic implementations and composites should use the same terminology and provide the same capability to define their configurable aspects (i.e. services, references, and properties). This is achieved by renaming entry point to *{_}service{_}*, external service to *{_}reference{_}*, and to allow for properties to be defined for composites in a first class way.
  
 In the V0.9 specification, both module assemblies and system assemblies had the concept of building up the assemblies out of a set of partial assemblies. These were called module fragments on the module level and subsystems on the system level. In the latest model this is realized by another form of usage of composites. It is the use of a composite by including it into another composite, which means textual inclusion of the contents of a composite into the composite including it.&nbsp;Composites used for inclusion in this way do not have to be implementations - they can contain any set of elements, which are the contributed to the composites which include them.
  
 h2. Summary of Model Changes
  
 The following table summarizes the model changes by showing the new model next to old model. It can be clearly seen how making the assembly model fully recursive simplified the model by reducing the number of concepts.
 || *Old Assembly Model* || *New Assembly Model* ||
 | \\
 Simple Component Implementation (e.g. POJO, BPEL, ...) \\
 * Service
 * Reference
 * Propertiy | \\
 Simple Component Implementation (e.g. POJO, BPEL, ...) \\
 * Service
 * Reference
 * Property |
 | \\
 Module Assembly \\
 * Entry Point
 * External Service
 * \-
 * Component
 ** Simple implementation
 ** \-
 * Module Fragment | \\
 Composite \\
 * Service
 * Reference
 * Property
 * Component
 ** Simple implementation
 ** Composite implementation
 * Composite include |
 | \\
 System Assembly \\
 * Entry Point
 * External Service
 * \-
 * Module Component
 ** Module Assembly
 ** \-
 * Subsystem | \\
 Composite \\
 * Service
 * Reference
 * Property
 * Component
 ** Simple implementation
 ** Composite implementation
 * Composite include |
  
 h2. The New Model in Action
  
 In the following we show the new recursive assembly model in action using a variation of the Big Bank sample, described in a white paper published with the SCA 0.9 specification (see [the BigBank Example document|Main:SCA - Previously Published Specifications^SCA_BuildingYourFirstApplication_V09.pdf]).
  
 h3. Development Assembly
  
 The variation of the sample is to implement the *{_}AccountDataServiceComponent{_}* of the *{_}bigbank.Account{_}* composite using another composite instead of a POJO. The following shows the assembly diagrams of the two composites *{_}bigbank.Account{_}* and *{_}bigbank.Accountdata{_}*. The latter implementing the *{_}AccountDataServiceComponent{_}* of the former.
 !BigBank_Account_Composite.jpg!
  
 &nbsp;
 The following snippet shows the definition of the *{_}bigbank.Account{_}* composite. It defines an *{_}AccountDataServiceComponent{_}* that uses the *{_}bigbank.Accoundata{_}* composite for its implementation. It also shows how to define a *{_}property{_}* for a composite and how the composite property is used to set a property of a component, here on the *{_}AccountServiceComponent{_}*. This example also shows that an entry point in the composite is now called a service and that an external service is called a reference. The way that the configuration of component properties and references is spelled in XML is also simplified to remove the use of the _v:_ namespace that caused confusion in the V0.9 specification.
 {code}
 <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  xmlns:bb="http://bigbank.com"
  targetNamespace="http://bigbank.com"
  name="bigbank.account">
  
  <service name="accountService" promote="AccountServiceComponent">
  <interface.java interface="services.account.AccountService"/>
  <binding.ws port="... #wsdl.endpoint(AccountService/AccountServiceSOAP)"/>
  </service>
  
  <property name="currency" type="xsd:string">USD</property>
  
  <component name="AccountServiceComponent">
  <implementation.java class="services.account.AccountServiceImpl" />
  <property name="currency" source="$currency"/>
  <reference name="accountDataService" target="AccountDataServiceComponent"/>
  <reference name="stockQuoteService" target="StockQuoteService"/>
  </component>
  
  <component name="AccountDataServiceComponent">
  <implementation.composite name="bb:bigbank.AccountData"/>
  </component>
  
  <reference name="StockQuoteService"
  promote="AccountServiceComponent/stockQuoteService">
  <interface.java interface="services.stockquote.StockQuoteService"/>
  <binding.ws port="...#wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)"/>
  </reference>
  
 </composite>
 {code}
 The following snippet shows the definition of the *{_}bigbank.AccountData{_}* composite.
 {code}
 <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  targetNamespace="http://bigbank.com"
  name="bigbank.AccountData">
  
  <service name="accountdataService" promote="AccountData">
  <interface.java interface="services.accountdata.AccountDataService"/>
  </service>
  
  <component name="AccountData">
  <implementation.java class="services.accountdata.AccountDataImpl"/>
  </component>
  
 </composite>
 {code}
  
 h3. Deployment Assembly
  
 The following assembly diagram shows the configuration of our bigbank.account composite into an SCA domain. We configure an implementation (in our sample the bigbank.Account composite) into an SCA domain by creating another composite with a component that uses that implementation. The created composite is added to the domain by inclusion. The domain itself works just like a composite and its configuration is built up through the inclusion of other composites.
  
 *{+}Note:+* In many cases implementations come with the entire configuration to make them a ready usable component in an SCA domain. SCA provides a direct way for deployment of these implementations.&nbsp;
 !BigBank_Domain_Deployment.jpg!
  
 The following snippet shows the definition of the *{_}bigbank.AccountManagement{_}* composite that creates a configured instance of the *{_}bigbank.Account{_}* composite shown earlier. It shows how the currency property is set, and also how the endpoint address of the stock quote web service used is overridden.
 {code}
 <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  xmlns:bb="http://bigbank.com"
  targetNamespace="http://bigbank.com"
  name="bigbank.AccountManagement">
  
  <component name="bigbank.Account">
  <implementation.composite name="bb:bigbank.Account" />
  <property name="currency">EURO</property>
  <reference name="stockQuoteService">
  http://www.eurosq.com/SQService
  </reference>
  </component>
  
 </composite>
 {code}
 The following snippet shows the definition of the *{_}bigbank.Client{_}* composite that creates a configured instance of the *{_}bigbank.Webclient{_}* composite. For details on the *{_}bigbank.Webclient{_}* composition see [the BigBank Example document.|Main:SCA - Previously Published Specifications^SCA_BuildingYourFirstApplication_V09.pdf]. The accountService reference of the *{_}bigbank.Webclient{_}* component is wired to the accountService of the *{_}bigbank.Account{_}* component.
 {code}
 <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  xmlns:bb="http://bigbank.com"
  targetNamespace="http://bigbank.com"
  name="bigbank.Client">
  
  <component name="bigbank.Webclient">
  <implementation.composite name="bb:bigbank.Webclient" />
  <reference name="accountService" target="bigbank.account/accountService"/>
  </component>
  
 </composite>
 {code}
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.4.5 Build:#708 Apr 12, 2007) - Bug/feature request - Contact Administrators