Chapter 2. Financial services business scenario 147
2.8 Step 4: Create Service Component Architecture
modules
As mentioned earlier, we included WebSphere Process Server in the A2Z
Financial Services’ self service solution for its complementary functionality to
IBM Information Server. In particular, its support for aggregating SOA services
(both IBM Information Server generated as well as otherwise) into a larger
business process SOA service, support for both sync and async invocations of
an SOA service. The service aggregation feature simplifies application
development, while the other features support a more diverse infrastructure.
WebSphere Integration Developer (WID) is the tooling for developing Service
Component Architecture (SCA) modules which are the deployable units in
WebSphere Process Server. An enterprise archive (.ear) file is generated from a
module, which is then deployed on WebSphere Application Server (WAS) and
appears as an application in the WAS Administrative Console.
As described in Appendix B, “WebSphere Integration Developer overview” on
page 459, the SCA module assembly contains a diagram of the integrated
business application consisting of components and wires that connect them.
Services become components that can be dropped into an assembly diagram
that forms a module. Services may be implemented using a variety of
programming paradigms such as process-flow style business process execution
language (BPEL) processes, state machine-style event management, and
declarative business rules style.
In our A2Z Financial Services’ self service solution, we chose to use the BPEL
style implementation in the following SCA modules that are created and deployed
on the WebSphere Process Server (lead.itsosj.sanjose.ibm.com):
򐂰 A2ZSCA_Brokerage:
This module includes multiple business processes that are exposed as an
SOA service using different bindings, as follows:
Note: We installed the Interim Fix 003 without which the modules could not be
built, and the optional feature IBM Information Server Plug-In for WID that
contains the IBM Information Server activity for BPEL processes and the
Enterprise Service Discovery Wizard extension for IBM Information Server.
These packages can be downloaded from
http://www-306.ibm.com/software/integration/wid/support/
148 SOA Solutions Using IBM Information Server
a. PlaceTradeProcess is a business process that places a trade in the
Brokerage system. The PlaceTradeProcess is exposed as a service using
SOAP over HTTP binding, and invokes the following Information Server
services:
i. AuthorizationService
ii. TradesService
iii. AuditService
b. OpenAccountProcess is a business process that opens an account in the
Brokerage system. The OpenAccountProcess is exposed as a service
using JMS binding, and invokes the following Information Server services:
i. AuthorizationService
ii. StandardizeAddressService
iii. NewAccountService
iv. AuditService
c. GetBalancesProcess is a business process that gets the balances in the
Brokerage system. The GetBalancesProcess is exposed as a service
using SCA binding, and invokes the following Information Server services:
i. AuthorizationService
ii. AccountStatusService
iii. AuditService
d. GetPositionsProcess is a business process that gets the positions in the
Brokerage system. The GetPositionsProcess is exposed as a service
using SOAP over HTTP binding, and invokes the following Information
Server services:
i. AuthorizationService
ii. AccountStatusPlatinumService and AccountStatusService
iii. LegacyStockQuoteService
6
Note: Even though the PlaceTradeProcess is exposed using SOAP
over HTTP binding, the Information Server services it consumes may
be accessed using a combination of EJB binding and SOAP over HTTP
binding.
6
This is not an IBM Information Server service. GetPositionsProcess consumes this service using
SOAP over HTTP binding.
Chapter 2. Financial services business scenario 149
򐂰 A2ZSCA_CreditCard:
This module includes multiple business processes that are exposed as an
SOA service using different bindings such as NewCardService,
CardStatusPlatinumService, CardStatusService, and
CardMaintenanceService.
The creation of this module is not shown here, but the
CardStatusPlatinumService and CardStatusService are imported by the
A2ZSCAccountStatusMediation module.
򐂰 A2ZSCA_AccountStatusMediation
This module also invokes a number of services linked together using a
number of artifacts. The objective with this module was to showcase the
capabilities of a mediation flow which responds to a service request
(GetAccountStatus) and routes it to another service (gold or platinum
service depending upon the customer’s status) that is designed to handle
it. Mediation modules and mediation flows are used in the WebSphere
Enterprise Bus.
This module is exposed as a single interface service using SCA binding,
and invokes the following Information Server services:
i. AuthorizationService
ii. AccountStatusPlatinumService and AccountStatusService
iii. CardStatusPlatinumService and CardStatusService
iv. CustomerIdLookupService
Figure 2-123 on page 150 shows these modules as deployed applications in the
WAS Administrative Console.
Note: We chose to only define representative SCA modules to showcase
async capabilities and various bindings support such as JMS, SCA, and
SOAP over HTTP.

Get SOA Solutions Using IBM Information Server now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.