SOA and Web services have become so mainstream that some believe they are now de-facto standards for deploying new applications and composite services. The triple lures of component reuse, open standards and easily-assembled composite services have become irresistible to companies seeking better agility and the flexibility to adapt to rapidly changing markets. In fact, SOA services are yielding significant business value to those companies mature enough to effectively deploy and govern them.
All is not rosy in SOA land, however. SOA services are creating challenges for both development teams tasked with creating them, and operations teams tasked with supporting them. In this article, we'll explore how the Service Component Architecture (SCA) can be used to reduce current problem areas, such as
Requires Free Membership to View
 |
||||
|
|
|||
|
||||
Service-oriented architecture (SOA), as its name implies, is simply an architecture. It relies on a combination of products, designs, standards and technology for actual implementation. While software components written for a variety of platforms and in multiple languages may be leveraged in SOA services, combining and integrating them into value-added business services is what SOA is all about.
There are a host of Web services standards contributing to the growth of standards-based SOA. Service component architecture (SCA), Service Data Objects (SDO) and Service Component Definition Language (SCDL) are emerging standards that promise to simplify standards-based SOA deployment, and in doing so accelerate the growth curve.
The intent of SCA is to simplify the process of creating composite services by de-coupling the programming of code modules from the invocation details necessary to assemble them into usable composite services. In lieu of such a standard, knitting together diverse components requires in-depth knowledge of protocols, databases, application program interfaces (APIs), Web technology, programming, and infrastructure architecture. SCA extends and complements existing standards and is implemented using SCDL. SCDL is an XML-based language that describes the way in which components are combined into usable applications and business services. A sister specification, Service Data Objects (SDO), promises to simplify data exchange as well.
The service component architecture vision
The current SCA specification was initially proposed to the Organization for the Advancement of Structured Information Standards (OASIS) by a vendor consortium that included IBM, Oracle Corporation, BEA Systems (later acquired by Oracle) and SAP AG. The OASIS consortium describes SCA as an application model for building applications and systems using a SOA.
|
||||
|
|
|||
|
||||
Building on emerging best practices, SCA separates middleware programming dependencies from business logic by introducing bindings that act as access mechanisms to the underlying technology. The specification is designed to simplify the life of the programmer because it abstracts the complexities of integration from the task of writing business-relevant code. In theory, it also minimizes the skill and resource requirements necessary to combine software components into SOA services.
The vision is that SCA will eventually enable personnel with business skills, versus deep programming and technical skills, to "create" business services from a library of software components. The complexity that is currently addressed by programmers will largely be masked by the SCA standard, which will include prewritten bindings, or translators, for common programming languages and protocols. SCA v1.0 was delivered in March of 2007 and the C and COBOL draft SDO specifications were published in May of 2007.
The SCA reality
Using SCA in its native form requires in-depth knowledge of SCDL, which looks very similar to both XML and Hypertext Markup Language (HTML). This is due to the fact that most markup languages go back to the same roots in Standard Generalized Markup Language (SGML), the ISO standard for document markup languages. Those familiar with HTML know that writing native HTML is a cumbersome way to create a Web page. SCDL has similar drawbacks.
This will likely change over time with the evolution of SCA/SCDL toolsets. In the same way that Microsoft's FrontPage simplified the process of developing HTML-based Web sites, new vendor products are starting to simplify the deployment and use of SCA. FrontPage masked native HTML's user-unfriendly exterior with a simple graphic interface. This enabled virtually any user to create a Web page with little or no technical expertise. Over time, a similar evolution will likely enable less-skilled users to assemble code modules into composite services leveraging SCA. (See examples of tools in sidebar.)
Like the Business Process Execution Language (BPEL) standard before it, one of the primary beneficiaries of the SCA standard has been independent software vendors (ISVs). It has enabled them to share intellectual property and develop better product interoperability. The standard is now being incorporated into vendor products.
The emerging standards benefit businesses as well. By leveraging products that incorporate SCA, development teams will be able to create composite services significantly faster and with less skilled staff. However, at the present time, the idea of non-technical personnel creating composite services is probably unrealistic. Stay tuned, because this will likely change over the next 1-3 years.
Conclusions
In the end, SCA, like any other standard, is good for the industry. Benefits include:
- OASIS-specified
- Extends existing standards
- Masks the complexity of heterogeneous technology
- Promotes faster integration of components into services
- Simplifies both product development (for ISVs) and integration (for system integrators and businesses).
SCA simplifies a complex technical process, and in doing so benefits the broad marketplace. It provides a standard for co-development and interoperability among vendors and across products, and benefits those companies with a need to integrate heterogeneous technology.
That being said, the myth of putting integration into the hands of non-programmers remains a myth, at least for the present. In the same way that few business stakeholders would willingly create a Web site by writing raw HTML, few would likely want to manually integrate software modules with SCA as it currently stands. That being said, products that leverage SCA are already coming to market, and will continue to evolve over time. As these products evolve, the full promise of SCA will continue to unfold.
About the author: Julie Craig is research director at http://www.enterprisemanagement.com Enterprise Management Associates, an IT analyst and consultant firm. At EMA, here focus areas are best practices, application management, software development, service oriented architecture (SOA), and software as a service (SaaS).
Julie has over 20 years of deep and broad experience in software engineering, IT
infrastructure engineering, and enterprise management. Her experience in commercial software
companies included development of communications interfaces and management of programming teams. As
a former IT senior engineer, she developed enterprise management solutions and deployed multiple
packaged system, application and performance management products.
This was first published in December 2009
Join the conversationComment
Share
Comments
Results
Contribute to the conversation