Print Print
Simplifying Composite Applications with Service Component Architecture (cont'd)

The Advantages of SCA for Developers
SCA has several key advantages for composite application developers:

  • SCA provides a single programming model for invoking a component.
    A composite application invokes a SOAP over HTTP Web service the same way it invokes a POJO and the same way it invokes an RMI service. Once a developer knows how to invoke an SCA component, they don't have to learn new programming interfaces, networking protocols or frameworks to use different components. That means a much shorter learning curve for the developer.
  • SCA frees administrators to choose services written in different ways.
    If an administrator finds a RMI service that provides better performance, but no one on the development team knows RMI, there are training costs and risks in deciding to use the new service. With SCA, there are no training costs; the RMI service is invoked in the same was as any other service.
  • SCA frees the developers from the details of composite applications to focus on business logic.
    Writing infrastructure code doesn't make the organization work better. A developer writes code to configure a Java message queue because they have to, not because there is any business value in doing so. With SCA, developers write code that improves the organization.

SCA Roles and Responsibilities
There are three important roles in the development of composite applications. An Administrator decides which components will be used, and uses SCA to define the policies for accessing them. A Service Provider uses SCA to assemble components so they can be used in an SCA application. Finally, an Application Developer writes the composite application, focusing on business logic and using SCA components as needed.

If a Service-Oriented Architecture is in the early stages, it's likely that one person performs all three of these roles. As the SOA matures, an organization has to know what services are being used, how they're being used and whether there are multiple services that do the same thing. These issues are part of SOA Governance, and SCA simplifies this task. There will be only a few administrators and some number of service providers, but most of the people involved in an SCA environment will be application developers.

There are several key concepts in the SCA programming model that affect the aforementioned roles in an SCA environment:

  • Composition
  • Assembly
  • Policies
  • Bindings

Composition is how pieces of software are packaged as services. The details of composition include the location of the software, its interface, other components used by this software and other details. Composition is done by the service provider.

Assembly is the process of creating a composite application by combining business logic with some number of services. This is done by the application developer.

Policies define the rules for accessing a service. Policies typically define requirements for encryption, digital signatures, quality of service, authentication and other details. Policies are defined by the administrator.

Bindings involve the combination of an interface and a protocol. A binding might define that an application is accessed with RMI or SOAP over HTTP. A single component might have multiple bindings, each of which would be a different combination of interface and protocol. Bindings are defined by the service provider.

Easing Composite Application Development
SCA supports service implementations and bindings to a variety of different types of technologies. SCA's service implementations can be written in a number of different languages including Java, C++, PHP and BPEL. SCA bindings can support access methods such as Web services, messaging systems and RMI.

If you're building composite applications, you should build your component infrastructure with SCA. For organizations just getting started with Service-Oriented Architectures, SCA is a great way to organize your services. If your SOA is more mature, SCA greatly simplifies the task of service management and governance. Implementing SCA makes your applications more flexible, your services easier to manage and your policies easier to define and implement. To quote analyst David Chappell, "Anyone who's interested in the future of application development should be interested in SCA."


Previous Page: Getting Started  
Rikki Kirzner is a freelance writer and veteran computer industry professional with experience as an analyst and former Research Director for IDC, Gartner Group, and Meta Group and as a Senior Editor. Rikki writes about software, development tools, open source, SOA, domaining, and Web-based computing.
Doug Tidwell is a senior software engineer in emerging technology evangelism for IBM.
Submit article to: