SCA (Service component architecture) programming pattern

This article transferred from: http://www.ibm.com/developerworks/cn/webservices/ws-sca/

This article introduces the basic concepts in the SCA programming model and illustrates some of its basic uses in a simple example, expecting to be a catalyst and laying the groundwork for the reader to understand SCA later.

Overview

The industry's major software vendors are aggressively promoting the concept of service oritented Architecture,soa, but for most customers the concept of SOA is relatively abstract. In order to make it easier for customers to realize the transition to this service-oriented architecture, IBM introduced a new service component model while introducing a series of WebSphere new products. This is a new, language-independent programming model that provides a unified invocation method that enables customers to encapsulate and invoke different component types, such as Pojo, EJB, process components, and human interaction components, through a standard interface. Based on the data model of SDO, the programming model of this service component can greatly simplify the programming of the customer and improve the flexibility of the application, which is the architecture of service Component Architecture,sca. The current IBM support for SCA is in the recently launched WebSphere Process Server (WPS), but later the service component model will be applied to the bottom tier platform as an important programming model for IBM software. This article introduces the basic concepts in the SCA programming model and illustrates some of its basic uses in a simple example, expecting to be a catalyst and laying the groundwork for a deeper understanding of SCA in the future.

The origin of 1.1 SCA

Component-based programming has always been an important way for the software industry to simplify programming and improve efficiency and quality, but often we have different component models for different languages, which require different invocation methods. For example, in the field of Java EE technology, we have EJB,POJO,JDBC,JMS and so on, which is a great challenge for developers. In order to provide a unified calling method for these different interfaces, IBM proposed the Wsif (Web Service invocation Framework, refer to http://ws.apache.org/wsif/) and contribute it to the Apache organization. As a specification in the WebService domain, WSIF provides a unified ability to invoke a variety of services based on the Java API. But Wsif does not form a component-based architecture model, so IBM has introduced a service-oriented component model (services oritented Architecture, SCA) on this basis. This model not only solves the problem of unified invocation, but also presents a component-based building model, and provides many QoS capabilities for enterprise computing. Therefore, from a technical point of view, SCA is the continuation and extension of Wsif. The purpose of SCA is to enable users to build enterprise applications with a hierarchy that is no longer directly confronted with specific technical details, but rather as a way to build applications through serviced components. This approach also enables the customer's enterprise application to have a good hierarchical architecture, good separation of application business logic and it logic, not only easy to apply the build, but also easy to apply changes and deployment.

the basic concepts in 1.2 SCA

Some new concepts such as service components, modules, shared libraries, import and export are presented in the service component model (SCA). The basic concepts in these service components are explained separately below.

1.2.1 Service Components

The service component is the basic constituent element and the basic building unit of SCA, where we implement the business logic concretely. We can think of it as building blocks for our application. We can easily package traditional Pojo, stateless session beans, and so on as service components in SCA. The main interface specification for SCA service components is based on WSDL (Web Service Description Language), and in order to provide a more straightforward interface to Java programmers, some of SCA's serviced components also provide Java interfaces. Therefore, clients using serviced components can choose to use either the WSDL interface or the Java interface.

The portal that the serviced component provides to other service calls is called Interface (interface). The service component itself may also need to invoke other services, the call exit called Reference (Reference). The invocation specification is either a WSDL or a Java interface, whether it is an interface or a reference. For an interface model of the SCA service component, see Figure 1:

Figure 1:sca Service component Interface Model

WebSphere Processserver leverages SCA's component architecture and provides a number of components in the product that are closely related to business, such as business processes, human tasks, business state machines, business rules, and more. This allows users to directly leverage these service components to build their own business processes or other business-integrated applications. In WebSphere Process Server V6.0.1, the role of service components and SCA in the schema is shown in Figure 2:

Figure 2:websphere The architecture environment for Process Server V6.0.1

We can see from Figure 2 that the service component architecture is fundamental in Websphereprocess server, as well as the relationships of various ancillary service components related to business-related service components or technologies. About the architecture of WebSphere process Server This is not discussed here, please refer to the Developerworks special issue, the third installment of the 2005 ――websphere Process srever V6 Architecture Overview.

The main difference between SCA serviced components and traditional components is that:

1. Service components tend to be coarse-grained, while traditional components are mostly fine-grained.

2. The interface of the serviced component is standard, primarily the WSDL interface, and traditional components often appear in the form of specific APIs.

3. The implementation of a serviced component is irrelevant to the language, whereas traditional components often bind to a particular language.

4. Service components can provide QoS services through component containers, while traditional components are completely controlled directly by the program code.

1.2.2 Service Modules (module)

A service Module (module) consists of one or more service components that have an intrinsic business connection. How many service components are placed in a module, or which service components are put together, depends primarily on the requirements of the business and the flexibility of deployment. The module is the operating unit in SCA, because behind an SCA module is an enterprise application project with a Java EE. The reason for this is "behind", because we see in the development tool WID (WebSphere integration Developer V6.0) The elements that are SCA levels through the business integration perspective. But when you switch to the Java EE perspective, you will find the correspondence between these SCA elements and the actual Java EE elements. Therefore, building a module in WID is equivalent to building a project. In addition, because the module is a standalone unit, this gives the application a lot of flexibility in its deployment. For example, as long as the module interface remains the same, it is easy to replace the original business logic by redeploying the new module without affecting the rest of the application.

Since a module often contains multiple service components, how do we build the mutual invocation relationships between these serviced components? In the Wid tool, we can specify a call relationship between them simply by connecting the interface to the reference, without having to write a line of code. In addition, we can set the required QoS requirements on these connections, such as transactions, security, etc.

1.2.3 Importing and exporting (export)

The actual application of the user is often more complex, so the actual application usually requires multiple modules to meet the requirements, and these modules often have a mutual call relationship.

In addition, the service components in the module need to invoke some of the existing applications in addition to other serviced components, or services that have some existing applications that invoke the module, which may not be based on the SCA schema. In order to solve the above problem, we introduced two special "endpoints" in the module, one is the import, it's function is to make the service component in the module can invoke the service outside the module. The other is export, which makes it possible for an application outside the module to invoke the serviced component in the module.

Because calls are involved inside and outside the module, specific binding information needs to be specified. These binding information includes the invocation method of the target service or the source service, location information, methods of invocation, and so on. Currently, in WebSphere Process Server V6.0, the import endpoint provides four ways to bind, including: JMS bindings, WebService bindings, SCA bindings, and stateless session bean bindings. The export endpoint provides three ways to bind, including: JMS bindings, WebService bindings, and SCA bindings. For calls between SCA modules, we can easily set the binding method to SCA bindings, but for calls between non-SCA modules and SCA modules we only have to choose other binding methods.

1.2.4 Shared Libraries (library)

When we build multiple modules, if there are resources that can be shared between different modules, we can choose to create a resource that can be shared between different modules, rather than repeating them in different modules. Shared libraries are places where these shared resources are stored. Shared libraries can be created in wid in a similar way to modules, but the shared library contains only: Data definitions, interface definitions, data mappings, and relationships. The biggest difference from the module is that the shared library does not contain the service components and therefore does not contain the business logic. From the included features, we can think of a shared library as a subset of modules. When a module needs to use the resources in a shared library, we only need to make the module dependent on the shared library. From the perspective of deployment, a shared library corresponds to a jar package. At deployment time, the Java EE Enterprise application that corresponds to the module will automatically contain the shared library jar packages that are dependent on it. In particular, it is important to note that the shared library concept here is not a concept with shared libraries in WebSphere application servers, and there is no connection between them, so don't confuse them.

1.2.5 Standalone Reference

The service component in the module is not directly used by external Java code, for external Java code, such as Jsp/servlet using the service component in the module, the WID tool provides a special endpoint in the module called standalone Reference. This endpoint is only referenced (Reference), and there is no interface (Interface). As long as the reference to the endpoint is connected to the interface of the serviced component that needs to be invoked, the external Java code invokes the corresponding service component by the name of the reference. Refer to the actual code of the example below for details on how to invoke it.

At this point, the main concepts related to the service modules have been introduced, and the relationship between them is shown in Figure 3:

Figure 3: Overview map of service Modules

1.3 synchronous calls and asynchronous calls

We know that a common method call is a synchronous call, which is a blocking invocation, where the client (the calling party) code blocks until it is returned by the server (callee). This method of invocation is relatively straightforward and is also a calling method that is directly supported by most programming languages. However, if we are faced with a service component that is based on coarse granularity and we are faced with scenarios that require a long response time, then we need a non-blocking invocation method called asynchronous invocation.

The SCA programming pattern provides three ways of asynchronous invocation, namely:

1. One-way invocation.

2. Delayed response mode.

3. The request callback method.

one-way invocation

One-way invocation is the simplest way to invoke an asynchronous invocation in which a client makes a request and no longer cares about the server, including whether it succeeds, what the return value is, and so on. We can use the following figure 4 to describe this one-way invocation:

Figure 4: One-way invocation

One-way invocation is a way of invoking results, but in many cases we need to know the result of the call. We need to know if the call is successful and we need to know the result of the call, even if the call fails we also want information such as the error code. In this case, the delay response and the request callback are two ways to let us know the result of the call.

Delayed Response Mode

Deferred response means that the client continues execution after the call request has been made, but after a period of time, the client calls the appropriate method to retrieve the returned result, specifying through the parameters how to perform further actions based on the result of the call. Because it is an asynchronous invocation, the server needs to return an object called a ticket (Ticket) when the call request is made for the first time. This object is used as a parameter when the retrieval result request is issued for the second time. Obviously, this ticket object works very much like the SessionID of Web programming. We can use figure 5来 to indicate the delay of the corresponding call method:

Figure 5: Deferred response invocation method

Request Callback

Similar to the delayed response, the request callback method can also get the response from the server, but the difference is that the response is triggered by the server by a callback method, rather than being actively retrieved by the client as a deferred response. The principle of request callback is similar to the callback mechanism in many programming languages, and the difference is that the level of implementation is relatively high. We can use figure 6来 to indicate how the request is invoked:

Figure 6: Request callback method

two ways to call 1.4 SCA clients

From an interface perspective, the SCA client-side programming model is available in two ways:

1. Static call mode

2. Dynamic invocation Mode

Static Call Mode

Static invocation is a type-safe way, and is the most common way in general Java programming. The so-called type-safe refers to doing type checking at compile time, rather than waiting for the type error to be found when running. The examples are as follows:

Myserviceimpl MyService = (Myserviceimpl) servicemanager.locateservice ("MyService");
Myservice.somemethod ("input");

In SCA client programming, the static approach is to get directly to the actual implementation of the interface type, that is, directly to the Java interface.

Dynamic invocation Mode

As opposed to static invocation, dynamic invocation is a non-secure way. Its advantage is that the call is very flexible, but at the same time the disadvantage is that part of the problem is not found in the compile time, only to wait until the runtime to discover. The examples are as follows:

Service MyService = (service) servicemanager.locateservice ("MyService");
DataObject input = ...
Myservice.invoke ("SomeMethod", "input");

In the dynamic invocation mode, as shown in the example above, the client specifies the name of the method to invoke by invoking the string parameter of the Invoke method. Obviously, in this way, if the method name is incorrect, it cannot be found at compile time.

The other thing to note about dynamic invocation is that, in this invocation mode, all parameter passing is done by means of DataObject, SDO. Even if the actual parameter is just a string, it needs to be packaged into a DataObject.

Interface type and invocation method

In fact, what kind of invocation the client has is closely related to the interface type. When the provided interface type is of the WSDL type, the client can only be invoked in a dynamic manner. Because WSDL is the primary interface in the SCA model, this makes the dynamic invocation method very common in the SCA programming model. However, if the interface type provided is Java type, then the client can be invoked either dynamically or by means of a static invocation.