Starting with the service component architecture

A considerable number of bloggers have been wanting to know about the standardization efforts of the Service Component Architecture (SCA).

The SCA selection (pick-and-chose) specification style makes it easy to get lost in the SCA universe. Because of the basic lack of SCA experience in the community, many of the areas worth detailing are still under investigation or even untouched.

First, readers can easily be misled into believing that SCA is a (another) revolution in the Java realm. At two, this is wrong. First, while Java-oriented work attracts the most attention, SCA is not just about the Java domain: There are specifications for C + +, COBOL, PHP, and BPEL. What we should note, then, is that SCA's main purpose is not to replace existing environments, such as Java EE and OSGi, but to create an infrastructure where applications can traverse the boundaries between different programming models in these environments. The details of how SCA will integrate with the existing technology are missing pieces in the published SCA specification directory. There is really a lot of work to be done before you can depict the tedious details of integration with these environments at all levels.

Technology integration is difficult. In the course of its use, it should not be limited to a single interesting technique. However, the entire content of SCA is about Cross technology (cross-technology) integration.

SCA looks good in the future. Some very interesting prototypes have been shown on different occasions (including public meetings):

Oracle developers have demonstrated a combination of BPEL processes with proprietary quorum components, workflow components, and event proxies (see here).

SAP developers have demonstrated a combination of Java EE components and BPEL processes in a Java EE application package, as well as domain-level (domain-level) assembly on several Java EE applications. (See the JavaOne 2007 conference here)

The Apache Tuscany Project can run a mix of scripting language components and Java components.

SCA's FABRIC3 implementation demonstrates how to assemble a service network over a distributed runtime environment and different programming technologies.

Let's try to sum up what we can learn from these examples:

SCA is an enhancement of the framework, which provides a programming model for component and connectivity abstractions. Those frameworks may be standard products, but they can also be proprietary technologies, such as remote function calls (RFCs) for SAP systems, private quorum or script components, SQL stored procedures, and so on. To fulfill a range of benefits, SCA defines an assembly language that can be integrated into such a framework. We will discuss various benefits in detail. We can draw the following conclusions:

SCA support is combined with existing technologies. That will probably be its main use case.

The fundamental value of SCA is that it provides the basis for integration, distributed deployment, and assembly across technology programming models.

SCA allows implementations to provide proprietary technology in a consistent and universally recognized way-which is good for both developers and vendors.

Integration with existing environments

If anything, SCA is concerned with the integration of existing technologies. When designing SCA, it is not about reuse or other specifications. Its approach is an alternative: How the specification describes how to integrate deeply with the SCA model. You'll see this when you're browsing the SCA white paper or tracking prototype results osoa.org (see above). The idea here is that no matter where a particular technology is, it can add value by using SCA to extend its use outwards.

The integration of existing technologies may take place at different levels in different ways. An implementation type definition is a natural choice for a scripting language. For service invocation techniques, such as messaging, remote protocols, and bindings are all ways to integrate. For a run-time environment that provides a deployment model such as Java EE, one (and possibly more) component model integration can occur at more than one level.

Deep integration with the SCA Assembly of a given environment can reduce the annoying model friction caused by abstraction, which typically attempts to wrap all types of run-time packaging into a common "more advanced" run-time model.

For example, sometimes it is a good idea to abstract all the services through WSDL and implement the service invocation in some general-purpose XML-oriented ws-* runtime. Even though it seems like a good idea to look at the top, but the lack of attraction from the perspective of a service developer and service consumer: No matter where you are, you have to pay for the non integrated impedance mismatch that needs to be switched back and forth between different technologies-including naming, transactional, security.

Instead, an SCA integration will attempt to provide a performance opportunity for local devices so that they can be referenced immediately in the assembly definition and need to be modified only if there are previously no features.

Cross-technical programming model integration

SCA introduces the abstract concept of the implementation type (Implementation type). The implementation type describes the appearance of the component from an SCA assembly perspective. In other words, it illustrates what service endpoints a component provides, what references it needs, and what configuration properties it assigns to it. In that sense, an implementation type provides a technology-independent representation of a component implementation.

It sounds like a science fiction, and we've heard about it before. However, SCA does not attempt to capture a component and all aspects of its interaction within its own language. For example, SCA does not define its own interface description language, but relies on Java and WSDL. Other interface languages are supported by the implementing user when needed. In the same spirit, although SCA defines a policy framework, it does reuse ws-policy definitions as much as possible.

Once you have an implementation type, such as Foo, you can use SCA assembly to define how the component type Foo is combined with other environments, such as the BPEL process, Java POJO, or EJB session bean--Whatever your chosen environment supports.

From a vendor's point of view, this means that SCA lowers the marginal cost of providing implementation or binding technology to his users. For consumers, it means that SCA lowers the marginal cost of leveraging implementation or binding technology.

In the case of Java EE, we actually did a study in SAP. We integrate an SCA runtime and a BPEL engine with our Java EE 5 environment (the SAP NetWeaver) to get a seamless bpel and Java EE Component Integration and lifecycle model. Let's take a look at what we've got: real native Bpel to Java (and vice versa) local invocation (although not by reference, pass-by-reference) because we have sufficient local application to assemble metadata. In particular, a BPEL process can invoke a session bean through an SCA line (wire), update persisted data in the same transaction using the Java Persistence API (JPA), and expose the hidden information by exposing the Web service to the local interface. In this case, the SCA line has one end defined by the WSDL interface, its component side is implemented by BPEL, and one end is defined by the Java interface, which is the business interface of the session bean.

On the other side: when providing support for choreography (orchestration) languages such as BPEL, you need to be as seamless as possible to reuse existing assets. Here, SCA helps to allow it to be used locally, almost "in place".

Although there is no reason to expect a similar integration between C + + code and Java (but ...). Who knows, but there are a lot of programming models from the Enterprise Service Bus (ESB) or Enterprise application integration (EAI) legacy that can be integrated according to the same routines as integrated BPEL.

Distributed Deployment and assembly

Although SCA wisely does not describe a particular deployment format, it does define some aspects of deployment. In particular, it defines the concept of "deploying to an SCA Domain" (contribution to the SCA domains). This is another key concept of SCA.

As we discuss the deployment unit (contribution, that is, deployable), we can go beyond a single deployment unit to talk about assembly, which is actually the domain-level assembly that SCA refers to. A field is visualized as a combination that contains a combination from a deployment unit. That is, using the same assembly language that we use locally, we get a way of representing the assembly relationship across the deployment unit.

Distributed assembly, which is activated by domain concepts, is a logical counterpart for integration across technologies at the programming level. In fact, business applications must be integrated across application packages and often differentiate between huge systems across several technologies, and programming-level integration is unreasonable.

Fortunately, a domain may span several systems with more than one system and internal interconnection. In this sense, domain-level assembly provides a connectivity abstraction that moves the configuration from the system to the physical endpoint of the system to the definition of the composite domain structure.

It is not only about endpoint addressing within an abstract domain. In addition to that, assembly information may remain silent on the actual transport protocol used, depending on the heterogeneity of the domain, and the domain will leave that decision to the domain administrator or even the run-time implementation.

From an Enterprise service Bus (ESB) perspective, this suggests that today's trend is "the marginalization of ESB capabilities". That is, programming model integration (see above) allows us to freely implement integration functions in the business application logic, while domains abstract the ESB topology details-that is, programming on the service bus.

Proprietary technology and SCA

An important point to be drawn here is to reduce the marginal cost of the new programming model for providers and consumers. It's a simple win-win situation.

Vendors are generally reluctant to introduce new programming models because of the extra effort it takes to push it to developers and tools. It is not uncommon for new deployment models, management tools, and tool suites to introduce a new programming language such as BPEL. Is that fair?

Similarly, why should users be happy with the need to learn something extra? And these things do not make their development life more enjoyable.

When it comes to proprietary technology, this means that vendors can use SCA to provide faster, more labor-saving use of new or proprietary technologies. Users should expect to enter a lower threshold for domain-specific technology.

Summarize

You can learn from this article that SCA is not primarily an attempt to replace or change your favorite technology. It adds an assembly abstraction that you can use when you need it.

Is it about SOA? If we say SOA is about abstract connectivity details that can tamper with different transport protocols and programming models for integration and application deployments, then SCA is a simplification of SOA development.

Now that SCA enters Oasis and is known as the Open Composite Service Architecture (OPENCSA), SCA Development will continue under public gaze. Stay focused!