service component architecture – programming for the enterprise service bus sanjay patil standards...
TRANSCRIPT
Service Component Architecture – Programming for the Enterprise Service Bus
Sanjay PatilStandards Architect – SAP AGApril 2008
© SAP 2007 / Page 2
1. ESB Scenarios
2. Why does ESB need SCA?
3. SCA for ESB Programming
Agenda
© SAP 2007 / Page 3
ESB Scenarios
A2A Integration Integration Logic is the glue between
consumer and provider systems.
Service Adaptation Services are defined as part of a top-down
requirement analysis Service Adaptation layer may provide
message mapping/enrichment, protocol bridging, etc
System A System B
Service Interface X
Service Interface Y
Integration Logic
Non – WS Connectivity
System A
Service Adaptation
Non – WS Connectivity
WS End Point
Service InterfaceX
Service InterfaceY
© SAP 2007 / Page 4
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 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 IT-cycles.
System A
Aggregation Logic
WS End Point
System B
Service Interface Y
Service Interface A
Service Interface B
Non-WS Connectivity
System A
Virtualization Logic
WS End Point
System B
Service Interface Y
Service Interface A
Service Interface B
Non-WS Connectivity
© SAP 2007 / Page 5
ESB Essentials
Service oriented approach to integrationSupport for standards – XML, Web servicies (including WS-RM, WS-SC,
etc), WS-BPEL, ...Protcol bridgingMulti-language supportTraditional integraion services – mapping, routing, rules engine, ...Eventing, loose couplingDistributed runtime (hubless architecture)<your favorite requirement>
Still ... What is really an ESB?
© SAP 2007 / Page 6
1. ESB Scenarios
2. Why does ESB need SCA?
3. SCA for ESB Programming
Agenda
© SAP 2007 / Page 7
Scenario: Wholesales Sales Order Tracking
* Receive customer call
* Verify customer SO data
Check supplier system for order status
Obtain tracking number
Check 3PL system for delivery
date
* Update customer on
status info
Supplier
WholesalerLogistic Service Provider
Customer
A typical project involves different systems, creating new business logic, using integration services (mapping, routing, rules), invoking some external services …
© SAP 2007 / Page 8
Defining Process Steps and Gathering Services Requirements
CRMERP
Enterprise Services
Search Customers
Search Sales
Orders
Display Customer
Details
Search for customersby name,
address, city..
Search for customersby name,
address, city..
Search for Sales Ordersby number,date, PO,..
Search for Sales Ordersby number,date, PO,..
Display Customer
details including Account
Executiveinformation
Display Customer
details including Account
Executiveinformation
Use existing Service
Use existing Service
Use existing Service
Use existing Service
New Servicerequired
New Servicerequired
© SAP 2007 / Page 9
ESB: Protocol Bridging Service Enablement Mapping / Routing …
Typical Implementation using ESB
ERP
Enterprise Services
CRM
Process Engine
Service Engine
CRM Adapter
Web
Ser
vice
Web Service
Supports typical ESB features of BPEL engine, adapters, multi-protocol support, etc
Standards based – BPEL, Web Services, Java EE
Service oriented designSo why do you need SCA?
© SAP 2007 / Page 10
Case I – Use Web services when needed
ERP
Enterprise Services
CRM
Process Engine
Service Engine
CRM Adapter
Web
Ser
vice
Web Service
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?
© SAP 2007 / Page 11
Case II – End-to-end QoS
ERP
Enterprise Services
CRM
Process Engine
Service Engine
CRM Adapter
Web
Ser
vice
Web Service
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
Bridging of QoS Models
© SAP 2007 / Page 12
Case III – Managing changes to Service provider and location
ERP
Enterprise Services
CRM
Process Engine
Service Engine
CRM Adapter
Web
Ser
vice
Web Service
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!
What if this system is moved or replaced/
outsourced?
© SAP 2007 / Page 13
Case IV – Collecting management data
ERP
Enterprise Services
CRM
Process Engine
Service Engine
CRM Adapter
Web
Ser
vice
Web Service
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
What happens when this service is shutdown for
maintenance, etc?
© SAP 2007 / Page 14
Case V – Tolerance towards new protocols and application runtimes
ERP
Enterprise Services
CRM
Process Engine
Service Engine
CRM Adapter
Web
Ser
vice
Web Service
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 Runtime
New AppNew AppNew Protocol
© SAP 2007 / Page 15
1. ESB Scenarios
2. Why does ESB need SCA?
3. SCA for ESB Programming
Agenda
© SAP 2007 / Page 16
Key Areas of SCA
How do I configure and assemble components to create composites? SCA Assembly Spec
SOAP/HTTP
JMSJCA
How do I code SCA components in Java? Or say in BPEL? Or C++, PHP SCA BPEL Client & Impl Spec, …
How do I configure access to SCA services using SOAP/HTTP or JMS or JCA, … SCA WS Binding Spec, …
How do I define, use and administer policies for non-functional aspects (QoS, etc)? SCA Policy Framework Spec
Composite
Component
Properties
© SAP 2007 / Page 17
Modeling the Composite Application with SCA
<Reference name=„customerDetails“> <binding.jca ... />
<component name=„SalesOrderTrackingComponent“ …><implementation.bpel
process=„tracking:SalesOrderTrackingProcess“/>
<Composite name=„SalesOrderTracking“ <Service > <Component > <Reference >
<Reference name=„salesOrderDetails“><binding.ws ....>
Composite
Service
Ref
Ref
ERP
BPEL
JavaCRM
Internal
wire
Properties
© SAP 2007 / Page 18
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>
<reference name=“salesOrderDetails“ promote=“SalesOrderTrackingComponent/SalesOrderDetails”> <binding.ws port=“…"/> </reference>
<reference name=“customerDetails“ promote=“CustomerDetailsComponent/customerDetails> <binding.jca …/> </reference>
</composite>
ERP
Enterprise
Services
CRM
BPEL Engine
Java EE Server
Java AppJava App
CRM Adapter
Web
Ser
vice
Web Service
© SAP 2007 / Page 19
ESB – Compositions programmed to the bus
Service Provider
Service Consumer
Event Consumer
B2B PartnerEvent
Provider
Application with
Eventing & BPM
Service-based communication
Event-based communication
Application with Mediation and MappingES
B
RegistryRegistry
BPEL Engine Java EE Server
Java AppJava App
ERP
Enterprise Services
CRM
SCA Domain
© SAP 2007 / Page 20
Benefits of SCA to ESB
Use Case Benefit of using SCA Standard
SOA does not always mean WS
Neutral to communication technologies
Supports WS, JMS, JCA bindings
Wires internal to SCA domain use proprietary technology
Bridging QoS Models of heterogeneous platforms
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
Managing changes to service provider/location
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 testing tools can be more effective
Tolerance to new application runtimes and communication technologies
Framework for bindings to different technologies makes it possible for developers to apply a consistent programming model
