Enterprise Integration Zone is brought to you in partnership with:

Behind DotNetBlocks.com is a software engineer with over 10 years of experience in Microsoft technologies and is currently obtaining a Masters in IT. His primary focus is typically on software architecture, web applications, and interactions amongst various systems. Todd is a DZone MVB and is not an employee of DZone and has posted 47 posts at DZone. You can read more from them at their website. View Full User Profile

Incorporating SCA into Existing Enterprise Systems

11.06.2012
| 4312 views |
  • submit to reddit

After viewing Rob High’s presentation “The SOA Component Model” hosted on InfoQ.com, I can foresee how Service Component Architecture (SCA) can be incorporated in to an existing enterprise.

According to IBM’s DeveloperWorks website, SCA is a set of conditions which outline a model for constructing applications/systems using a Service-Oriented Architecture (SOA). In addition, SCA builds on open standards such as Web services.
 
In the future, I can easily see how some large IT shops could potently divide development teams or work groups up into Component/Data Object Groups, and Standard Development Groups. The Component/Data Object Group would only work on creating and maintaining components that are reused throughout the entire enterprise. The Standard Development Group would work on new and existing projects that incorporate the use of various components to accomplish various business tasks.
 
In my opinion the incorporation of SCA in to any IT department will initially slow down the number of new features developed due to the time needed to create the new and loosely-coupled components. However once a company becomes more mature in its SCA process then the number of program features developed will greatly increase. I feel this is due to the fact that the loosely-coupled components needed in order to add the new features will already be built and ready to incorporate into any new development feature request.
 
References:

Published at DZone with permission of Todd Merritt, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jim Marino replied on Wed, 2012/11/07 - 11:36am

Hi,


This is an interesting take on how SCA modularity can be used to bridge new and existing systems. Since the time of Rob's presentation, SCA has evolved and moved to OASIS (http://www.oasis-opencsa.org/committees). The need for SDO seems to have faded - it was originally developed before JAXB 2 and standardization work has now been suspended. SCA isn't tied to SDO and integrates well with popular databinding technologies such as JAXB and Jackson (JSON).


As SCA gains wider adoption, I think one of the key features will be composites, which group related components. Composites can be used to better facilitate modular development in an organization and across teams. For example, composites can restrict visibility of contained components and expose a set of "service APIs". In addition, composites can be nested.


The Fabric3 open source SCA runtime uses this type of modularity extensively. The sample application, Big Bank, provides a detailed example of how composites can be used to encapsulate third-party or legacy credit scoring systems: http://docs.fabric3.org/display/fabric3/BigBank+Architecture

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.