Service Component Architecture –
Programming for the Enterprise
Service Bus
Sanjay Patil
Standards Architect – SAP AG
April 2008
Agenda
1. ESB Scenarios
2. Why does ESB need SCA?
3. SCA for ESB Programming
© SAP 2007 / Page 2
ESB Scenarios
Service
Interface X
A2A Integration

Integration Logic is the glue between
consumer and provider systems.
Service
Interface Y
System A
Integration Logic
Non – WS Connectivity
Service Adaptation


Services are defined as part of a top-down
requirement analysis
Service Adaptation layer may provide
message mapping/enrichment, protocol
bridging, etc
© SAP 2007 / Page 3
Service
InterfaceY
WS End Point
Service Adaptation
Service
InterfaceX
Non – WS Connectivity
System A
System B
ESB Scenarios (cont’d)

Service Aggregation / Orchestration

Combination of distinct functionalities to
achieve new business goals or to
optimize the operation of existing
processes.
Service
Interface Y
WS End Point
Aggregation Logic
Service
Interface A
Non-WS
Connectivity
System A

Service Virtualization


Switch between redundant backend
systems for scalability, optimal resource
utilization, etc
Single, consolidated Service is offered for
a collection of similar services, a possible
result of merger/acquisitions or
decentralization-then-centralization ITcycles.
© SAP 2007 / Page 4
Service
Interface B
System B
Service
Interface Y
WS End Point
Virtualization Logic
Service
Interface A
System A
Non-WS
Connectivity
Service
Interface B
System B
ESB Essentials
 Service
oriented approach to integration
 Support for standards – XML, Web servicies (including WS-RM, WS-SC,
etc), WS-BPEL, ...
 Protcol bridging
 Multi-language support
 Traditional integraion services – mapping, routing, rules engine, ...
 Eventing, loose coupling
 Distributed runtime (hubless architecture)
 <your favorite requirement>
Still ... What is really an ESB?
© SAP 2007 / Page 5
Agenda
1. ESB Scenarios
2. Why does ESB need SCA?
3. SCA for ESB Programming
© SAP 2007 / Page 6
Scenario: Wholesales Sales Order Tracking
A typical project involves different systems, creating new business logic, using integration
services (mapping, routing, rules), invoking some external services …
Logistic Service
Provider
Wholesaler
Supplier
Customer
* Receive
customer call
© SAP 2007 / Page 7
* Verify
customer SO
data
Check
supplier
system for
order status
Obtain
tracking
number
Check 3PL
system for
delivery date
* Update
customer on
status info
Defining Process Steps and Gathering
Services Requirements
Display
Customer
Details
Search for
customers
by name,
address, city..
Search for
Sales Orders
by number,
date, PO,..
Display
Customer
details
including
Account
Executive
information
Use existing
Service
Use existing
Service
New Service
required
Enterprise
Services
ERP
© SAP 2007 / Page 8
CRM
Backend
Search
Sales
Orders
Search
Customers
Typical Implementation using ESB
Supports typical ESB features of BPEL engine, adapters, multi-protocol support, etc
Standards based – BPEL, Web Services, Java EE
Service oriented design
So why do you need SCA?
Process
Engine
CRM Adapter
Enterprise
Services
ERP
© SAP 2007 / Page 9
ESB:
 Protocol Bridging
 Service Enablement
 Mapping / Routing
 …
Service Engine
CRM
Case I – Use Web services when needed
What if the Process Engine and the ESB Runtime are running on the same JVM?
Where and how to declare and validate the mapping of Web service to the internal call?
Do we really need this call as
a Web Service?
Process
Engine
CRM Adapter
Service Engine
Enterprise
Services
ERP
© SAP 2007 / Page 10
CRM
Case II – End-to-end QoS
Each application runtime and communication mechanism has its own model for security, reliability, etc
Bridging of different QoS models at the edges is brittle and difficult to manage
Bridging of
QoS Models
Bridging of
QoS Models
Process
Engine
CRM Adapter
Bridging of
QoS Models
Service Engine
Enterprise
Services
ERP
© SAP 2007 / Page 11
CRM
Case III – Managing changes to Service
provider and location
M&A, new business partnerships, new products/upgrades, etc, lead to changes to service
Ease and efficiency of handling changes to service providers and location!
Process
Engine
CRM Adapter
Service Engine
Enterprise
Services
ERP
© SAP 2007 / Page 12
What if this system is
moved or replaced/
outsourced?
CRM
Case IV – Collecting management data
The information about service dependencies is either in people’s minds, or in project documentation, etc.
Deriving management data could be part of the design and deployment methodology
Process
Engine
CRM Adapter
Service Engine
Enterprise
Services
ERP
© SAP 2007 / Page 13
What happens when this
service is shutdown for
maintenance, etc?
CRM
Case V – Tolerance towards new protocols
and application runtimes
New communication infrastructure and new runtime get periodically added to the landscape
Does the IT development team need to learn yet another programming technology, invocation model?
New Protocol
Process
Engine
New App
New Runtime
CRM Adapter
Service Engine
Enterprise
Services
ERP
© SAP 2007 / Page 14
CRM
Agenda
1. ESB Scenarios
2. Why does ESB need SCA?
3. SCA for ESB Programming
© SAP 2007 / Page 15
Key Areas of SCA
How do I define, use and
administer policies for nonfunctional aspects (QoS, etc)?
 SCA Policy Framework Spec
Properties
How do I configure and
assemble components to
create composites?
 SCA Assembly Spec
Composite
SOAP/
HTTP
Component
JMS
How do I configure access to
SCA services using
SOAP/HTTP or JMS or JCA, …
 SCA WS Binding Spec, …
© SAP 2007 / Page 16
JCA
How do I code SCA
components in Java? Or
say in BPEL? Or C++, PHP
 SCA BPEL Client & Impl
Spec, …
Modeling the Composite Application with SCA
<component name=„SalesOrderTrackingComponent“ …>
<implementation.bpel
process=„tracking:SalesOrderTrackingProcess“/>
<Reference name=„customerDetails“>
<binding.jca ... />
Properties
Ref
CRM
Java
Service
BPEL
Ref
ERP
Composite
<Composite name=„SalesOrderTracking“
<Service >
<Component >
<Reference >
© SAP 2007 / Page 17
<Reference name=„salesOrderDetails“>
<binding.ws ....>
XML Representation of the Composition
<?xml version="1.0" encoding="ASCII"?>
<composite xmlns="http://www.oasis-open.org/opencsa/sca/200712"
name=“SalesOrderTracking" >
<service name=“SalesOrderTracking“
promote=“SalesOrderTrackingComponent”>
<binding.ws port="http://www.acme.com/SOService#
wsdl.endpoint(…)"/>
</service>
<component name=“SalesOrderTrackingComponent">
<implementation.bpel
process=“SalesOrderTrackingServiceProcess"/>
<property name=“continent”>EUROPE</property>
<reference name=“salesOrderDetails“/>
<reference name=“CustomerDetails“
target=“CustomerDetailsComponent”/>
</component>
<component name=“CustomerDetailsComponent">
<implementation.java
class=“acme.tracking.CustomerDetails"/>
<reference name=“CustomerDetails"/>
</component>
BPEL Engine
Java App
CRM Adapter
Java EE Server
Enterpri
se
Service
s
ERP
<reference name=“salesOrderDetails“
promote=“SalesOrderTrackingComponent/SalesOrderDetails”>
<binding.ws port=“…"/>
</reference>
<reference name=“customerDetails“
promote=“CustomerDetailsComponent/customerDetails>
<binding.jca …/>
</reference>
</composite>
© SAP 2007 / Page 18
CRM
ESB – Compositions programmed to the bus
Service
Consumer
Event
Consumer
Java App
ESB
BPEL Engine
Application
with
Eventing &
BPM
Java EE Server
SCA Domain
Application
with Mediation
and Mapping
Registry
Service
Provider
Event
Provider
B2B
Partner
Enterprise
Services
ERP
Service-based communication
Event-based communication
© SAP 2007 / Page 19
CRM
Benefits of SCA to ESB
Use Case
SOA does not always mean WS
Benefit of using SCA Standard

Neutral to communication technologies

Supports WS, JMS, JCA bindings

Wires internal to SCA domain use proprietary technology

Bridging QoS Models of
heterogeneous platforms
Managing changes to service
provider/location
Modeling and configuring QoS aspects of is handled at the the
platform neutral SCA Assembly layer
SCA defines
QoS aspects in abstract terms (‘intents’) and allows
their mapping to individual platform environments

SCA component implementations are programmed to interfaces

Service endpoint information is not hardwired into client code

Wiring of components is a first class concept with elaborate
support for common scenarios (internal, external, redeployment)

Support for testing, management
By providing a holistic view of the solution, it becomes possible
for management tools to capture service dependency information
Service
Tolerance to new application runtimes
and communication technologies
© SAP 2007 / Page 20

testing tools can be more effective
Framework for bindings to different technologies makes it
possible for developers to apply a consistent programming model
Questions?
Sanjay Patil
SAP Labs – Palo Alto
Email: sanjay.patil@sap.com
© SAP 2007 / Page 21