Incorporating SCA into Existing Enterprise Systems
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:
- BEA Systems, Cape Clear Software, IBM, Interface21, IONA Technologies PLC, Oracle, Primeton Technologies Ltd, Progress Software, Red Hat Inc., Rogue Wave Software, SAP AG, Siebel Systems, Software AG, Sun Microsystems, Sybase, TIBCO Software Inc. (2006). Service Component Architecture. Retrieved 11 27, 2011, from DeveloperWorks: http://www.ibm.com/developerworks/library/specification/ws-sca/
- High, R. (2007). The SOA Component Model. Retrieved 11 26, 2011, from InfoQ: http://www.infoq.com/presentations/rob-high-sca-sdo-soa-programming-model
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
replied on Wed, 2012/11/07 - 11:36am
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