WebSphere Enterprise Service Bus, Version 6.2.0 Operating Systems: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Service component architecture

SCA is an abstraction you can implement in many different ways. It does not mandate any particular technology, programming language, invocation protocol, or transport mechanism. SCA components are described using Service Component Definition Language (SCDL), which is an XML-based language.

An SCA component has the following characteristics:

WebSphere® Integration Developer supports the following implementation artifacts for WebSphere Enterprise Service Bus and WebSphere Process Server:
Table 1. Implementation artifacts
WebSphere ESB WebSphere Process Server
Mediation flows Mediation flows
Plain Java™ objects Plain Java objects
  Business processes
  Business state machines
  Business rules
  Human tasks

SCA separates business logic from infrastructure so that application programmers can focus on solving business problems. IBM’s WebSphere Process Server is based on that same premise. Figure 1 shows the architectural model of WebSphere Process Server.

Figure 1. WebSphere Process Server component-based framework
WebSphere Process Server component-based framework

In the WebSphere environment, the SCA framework is based on the Java 2 Platform, Enterprise Edition (J2EE) runtime environment of WebSphere Application Server. The overall WebSphere Process Server framework consists of SOA Core, Supporting Services, and the Service Components. The same framework with a subset of this overall capability, targeted more specifically at the connectivity and application integration needs of business integration, is available in WebSphere Enterprise Service Bus.

The interface of an SCA component can be represented as one of the following:
An SCA module is a group of components wired together by directly linking references and implementations. In WebSphere Integration Developer, each SCA module has an assembly diagram associated with it, which represents the integrated business application, consisting of SCA components and the wires that connect them. One of the main responsibilities of the integration developer is to create the assembly diagram by connecting the components that form the solution. WebSphere Integration Developer provides a graphical Assembly Editor to assist with this task. When creating the assembly diagram, the integration developer can proceed in one of two ways: The bottom-up approach is more commonly used when customers have existing services that they want to reuse and combine. When you need to create new business objects from scratch, you are likely to adopt the top-down approach.

The SCA Programming Model: Fundamentals

The concept of a software component forms the basis of the SCA programming model. As we mentioned, a component is a unit that implements some logic and makes it available to other components through an interface. A component may also require the services made available by other components. In that case, the component exposes a reference to these services.

In SCA, every component must expose at least one interface. The assembly diagram shown in Figure 2 has three components, C1, C2, and C3. Each component has an interface that is represented by the letter I in a circle. A component can also refer to other components. References are represented by the letter R in a square. References and interfaces are then linked in an assembly diagram. Essentially, the integration developer “resolves” the references by connecting them with the interfaces of the components that implement the required logic.

Figure 2. Assembly diagram
Assembly diagram

Invoking SCA Components

To provide access to the services to be invoked, the SCA programming model includes a ServiceManager class, which enables developers to look up available services by name. Here is a typical Java code fragment illustrating service lookup. The ServiceManager is used to obtain a reference to the BOFactory service, which is a system-provided service:

//Get service manager singleton
ServiceManager smgr = new ServiceManager();
//Access BOFactory service
BOFactory bof =(BOFactory)
        smgr.locateService("com/ibm/websphere/bo/BOFactory");
Note: The package for ServiceManager is com.ibm.websphere.sca.

Developers can use a similar mechanism to obtain references to their own services by specifying the name of the service referenced in the locateService method. After you have obtained a reference to a service using the ServiceManager class, you can invoke any of the available operations on that service in a way that is independent of the invocation protocol and the type of implementation.

SCA components can be called using three different invocation styles:
  • Synchronous invocation: When using this invocation style, the caller waits synchronously for the response to be returned. This is the classic invocation mechanism.
  • Asynchronous invocation: This mechanism allows the caller to invoke a service without waiting for the response to be produced right away. Instead of getting the response, the caller gets a “ticket,” which can be used later to retrieve the response. The caller retrieves the response by calling a special operation that must be provided by the callee for this purpose.
  • Asynchronous invocation with callback: This invocation style is similar to the preceding one, but it delegates the responsibility of returning the response to the callee. The caller needs to expose a special operation (the callback operation) that the callee can invoke when the response is ready.

Imports

Sometimes, business logic is provided by components or functions that are available on external systems, such as legacy applications, or other external implementations. In those cases, the integration developer cannot resolve the reference by connecting a reference to a component containing the implementation he or she needs to connect the reference to a component that “points to” the external implementation. Such a component is called an import. When you define an import, you need to specify how the external service can be accessed in terms of location and the invocation protocol.

Exports

Similarly, if your component has to be accessed by external applications, which is quite often the case, you must make it accessible. That is done by using a special component that exposes your logic to the “outside world.” Such a component is called an export. These can also be invoked synchronously or asynchronously.

Stand-alone references

In WebSphere ESB, an SCA service module is packaged as a J2EE EAR file that contains several other J2EE submodules. J2EE elements, such as a WAR file, can be packaged along with the SCA module. Non-SCA artifacts such as JSPs can also be packaged together with an SCA service module. This lets them invoke SCA services through the SCA client programming model using a special type of component called a stand-alone reference.

The SCA programming model is strongly declarative. Integration developers can configure aspects such as transactional behavior of invocations, propagation of security credentials, whether an invocation should be synchronous or asynchronous in a declarative way, directly in the assembly diagram. The SCA runtime, not the developers, is responsible for taking care of implementing the behavior specified in these modifiers. The declarative flexibility of SCA is one of the most powerful features of this programming model. Developers can concentrate on implementing business logic, rather than focusing on addressing technical aspects, such as being able to accommodate asynchronous invocation mechanisms. All these aspects are automatically taken care of by the SCA runtime.

Qualifiers

The qualifiers govern the interaction between a service client and a target service. Qualifiers can be specified on service component references, interfaces, and implementations and are usually external to an implementation.

The different categories of qualifiers include the following:

SCA allows these quality of service (QoS) qualifiers to be applied to components declaratively (without requiring programming or a change to the services implementation code). This is done in WebSphere Integration Developer. Usually, you apply QoS qualifiers when you are ready to consider solution deployment. For more information, see Quality of service qualifier reference.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cdev_pgsca.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).