IBM’s SOA programming model provides a set of rules and languages that lets you focus on creating an implementation of a business design. The programming model addresses the aspects of service components and the data that is exchanged between services as service data, over a service bus. Now, let us look at the key aspects of this programming model.
Service Component Architecture
We design and build applications (for example, account opening, loan underwriting, order management, customer care, customer billing, and so on) so that an organization can run their business effectively and efficiently. Applications can be looked at as a collection of software components that are assembled or integrated together for a particular purpose. Ideally, you should have the freedom to implement the different components in the technology of your choice. However, at times you may have to inherit or work with existing systems, technologies, or work with third parties who have a different set of technologies. When you adopt an SOA approach to building applications, these components can be viewed as services. When we look at the constructs that make up a service, two things immediately come to mind:
- The What part: Data that should be passed to the service and data received back from the service
- The How part: The mechanism required to realize the service and how it can be invoked or can be made available to a service consumer
For each of the previous two questions, there are many standards and programming models and, at times, it may get too overwhelming. This is where an SCA model comes in and mitigates these complexities. SCA is not another programming language or replacement, but rather gives a model to assemble and build SOA applications by choosing any technology specific to the implementation approach. The fundamental goal and premise of SCA is to separate business logic from infrastructure logic. IBM’s BPM development tool WID provides the design time environment to build SCA-based applications using a bottom-up (expose services out of existing applications and make them available through the Enterprise Service Bus) or top-down approach (more a business-driven approach to identify the right set of services needed to achieve a larger goal, capability, or solution).
Therefore, WID enables architects and developers to spend more time working on solving a particular business problem rather than focusing on the details of which implementation technology to use. BPEL is one of those components that are available in WID to build applications.
Defining SCA
SCA is a set of specifications that describes a model for building applications and systems using an SOA approach. SCA extends and complements prior approaches to implementing services and SCA builds on open standards, such as web services.
SCA divides the steps in building a service-oriented application into two major parts:
- The implementation of components (including BPEL) that expose (export) services and consume (import) other services
- The assembly of sets of components to build business applications, through the wiring of references to services
SCA uses Service Data Objects (SDO) to represent the business data that forms the request and response values of services, providing uniform access to business data to complement the uniform and consistent access to business services offered by SCA itself. SCA supports bindings to a wide range of access mechanisms used to invoke services.
SCA emphasizes the decoupling of service implementation and of service assembly from the infrastructure capabilities, from technology or programming language specifics, and from the details of the access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware-specific APIs. The basic elements of SCA include:
- Service components
- Service assembly
- Service data objects
The basic building block in SCA is the service component and represents a business service that publishes or operates on business data. The SCA Component Fundamental Structure figure depicts the essential pieces of a service component definition. A service component can have one or more interfaces with which it is associated. The interfaces associated with a service component advertise the business operations associated with this service. These interfaces can be specified as either Java interfaces or WSDL port type interfaces.
The arguments and return types for these interfaces are specified as simple Java types, Java classes, SDOs, or XML Schema (for WSDL port type interfaces). Also, implementation is associated with a service component definition. As the figure indicates, there are multiple language and component types available for implementing a service component.
When specifying a component interface, you cannot mix Java and WSDL port type interfaces on the same service component definition.
A service assembly deals with the aggregation of components and the linking of components through wiring or wires. Think of the assembly model as how, when building a kitchen, you would assemble various components including kitchen cabinets, sink, appliances, counter top, and so on. The assembly model is independent of implementation language. An analogy would be, you don’t care how and where the dishwasher is engineered, manufactured, and built, but rather focus on the features, functions, and durability.
As depicted in the following figure, an SCA-based application Order Handling System can be made up of one or many modules and hence one or many components. Components can be combined into composites , a logical construct. In the following figure, we can see that the Order Handling System is made up from two composites, an Order Processing Composite and a Third-Party Shipping Composite.
In WID, a composite can be compared to a Service Module, which in essence becomes the basic unit of deployment and administration in WPS or WESB (SCA runtime). A service module typically contains the following artifacts:
- Module Definition
- An SCA-specification-defined deployment model for packaging components into a service module. In WID, the sca.module file contains the definition of the module.
- In the following figure, the Order Processing Composite and Third-Party Shipping Composite are the modules.
- Service Components
- Each service component can be implemented in various ways (BPEL, Mediation Flow Component, State Machine, Java, and so on), specified by the implementation definition.
- Service components can invoke other service components or imports, defined in the current service module as defined by an appropriate reference.
- A component can have 1..N interfaces.
- Each service component definition can have zero or more references to other services.
- In the following figure, the Order Validation Component and Order Handling Component are the service components whose implementations are BPEL and state machine respectively.
- In WID, the service component definition is included in the <SERVICE_NAME>.component file.
- Imports and Exports
- Allows SCA components in one module to invoke SCA components in other modules.
- A service module can have zero or more imports included with it.
- Imports have a name and a set of 1 . .N interfaces.
- A Binding attribute describes how the external service is bound to the current module.
- Once an import has been defined, other services within the module can reference the imported service as if it was a regular service component defined in the module.
- In the following figure, the Order Handling Component imports a component from the Third-Party Shipping Composite via a reference.
- In WID, import definition is included in an <IMPORT_NAME>.import file.
- Imports can use the following bindings, which can be remote or local:
- SCA
- Web service
- HTTP
- Messaging (JMS, MQ JMS, generic JMS, MQ)
- Stateless session bean
- EIS
- Exports
- Allows SCA components in a module to expose their capabilities to components in other modules.
- In order to invoke any of the services in the order handling application by any client (SCA or non-SCA), the service must be exposed with an export.
- A service module can have zero or more exports included with it.
- Export components include a name and a target attribute.
- A Binding attribute describes how the service is bound externally.
- In the following figure, the Order Validation Component has an export named Order Validate Export.
- In WID, import definition is included in an <EXPORT_NAME>.export file.
- Exports binding can be:
- SCA
- Web service
- HTTP
- Messaging (JMS, MQ JMS, generic JMS, MQ)
- Stateless session bean
- EIS
- References
- Inline
- Stand-alone
- Interfaces, Business Objects, Java classes, and other components
In order to invoke any of the services in the Order Handling System by any client (SCA or non-SCA), the service must be exposed with an export. A service module can have zero or more imports included with it. An import is used to access services that are outside the current SCA module. Once an import has been defined, other within the module can reference the imported service as if it was a regular service component defined in the module.
As depicted in the following figure, the service module Order Processing Composite can have zero or more exports included with it. An export is used to expose a particular service to clients, outside the current SCA module. A service may also include a stand-alone references file that includes references to services in the module that can be used by SCA and non-SCA services.
An SCA service module is packaged and deployed to the native SCA container strategy provided by WPS. This capability allows a developer not to use any to generate runtime-specific artifacts prior to installing a module. Unlike the previous releases of WPS and WESB, with version 7.0 the native container provides greater performance improvements due to the elimination of ejbDeploy for standard SCA applications.
