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 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.
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 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.
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");
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.
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.
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.
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.
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.