This chapter is from the book
This chapter is from the book
This chapter is from the book
Service Component Architecture
A.2.2
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. You could, in theory, create an SCDL file manually. In practice, you're more likely to use an integrated development environment (IDE) such as WebSphere Integration Developer to generate the SCDL file.
An SCA component has the following characteristics:
- It wraps an implementation artifact, which contains the logic that the component can execute.
- It exposes one or more interfaces.
- It can expose one or more references to other components. The implementation's logic determines whether a component exposes a reference. If the implementation requires invoking other services, the SCA component needs to expose a reference.
This chapter focuses on the SCA implementation that WPS offers and the WID tool that is available to create and combine SCA components. WPS and WID support the following implementation artifacts:
- Plain Java objects
- Business Process Execution Language (BPEL) processes
- Business state machines
- Human tasks
- Business rules
- Selectors
- Mediations
SCA separates business logic from infrastructure so that application programmers can focus on solving business problems. IBM's WPS is based on that same premise. Figure 2.1 shows the architectural model of WPS.
)
Figure 2.1 Architectural model for WPS
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 WESB.
The interface of an SCA component, as illustrated in Figure 2.2, can be represented as one of the following:
- A Java interface
- A WSDL port type (in WSDL 2.0, port type is called interface)
)
Figure 2.2 SCA in WPS
An SCA module is a group of components wired together by directly linking references and implementations. In WID, 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. WID 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:
- Top-down defines the components, their interfaces, and their interactions before creating the implementation. The integration developer can define the structure of the process, identify the necessary components and their implementation types, and then generate an implementation skeleton.
- Bottom-up combines existing components. In this case, the integration developer simply needs to drag and drop existing implementations onto the assembly diagram.
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. Chapter 4 introduces the various wizards in WID and lays out the six phases of creating a simple module using 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.3 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.3 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)
mgr.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. We illustrate in more detail the usage of the SCA programming model in Chapter 11, "Business Integration Programming." For the time being, we want to emphasize that 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 WPS, an SCA service module is equivalent to a J2EE EAR file and 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 declarative aspects of SCA programming are discussed in Chapter 11.