Sanjay Patil Standards Architect – SAP AG April 2008

Präsentation zum Thema: "Sanjay Patil Standards Architect – SAP AG April 2008"—  Präsentation transkript:

1 Sanjay Patil Standards Architect – SAP AG April 2008
Service Component Architecture – Programming for the Enterprise Service Bus Sanjay Patil Standards Architect – SAP AG April 2008

2 Agenda ESB Scenarios Why does ESB need SCA? SCA for ESB Programming

3 ESB Scenarios A2A Integration Service Adaptation
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 Service Adaptation Non – WS Connectivity WS End Point Service Interface X Y

4 ESB Scenarios (cont’d)
System A Aggregation Logic WS End Point System B Service Interface Y A B Non - WS Connectivity 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 Virtualization Logic WS End Point System B Service Interface Y A B Non - WS Connectivity

5 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?

6 Agenda ESB Scenarios Why does ESB need SCA? SCA for ESB Programming

7 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 … * 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 Wholesaler Logistic Service Provider Customer We decided to base our scenario on a real life eSOA proof point – the sales order tracking scenario. This scenario was developed as [art of the ESEC project (enterprise services enablement center). The idea behind the project was to develop industry specific processes using SAP eSOA and to sell them to customers from this industry. This scenario was presented by Henning in the influencer summit and was sold to Grainger. The scenario automate the process of tracking a sales order and connecting with suppliers and logistic providers. In the implementation highlights we will show, we used a reduced version of this scenario (without the calls to the supplier and the logistic provider).

8 Defining Process Steps and Gathering Services Requirements
Search Sales Orders Display Customer Details Search Customers 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 We identified the process steps as described here. Using the ES workplace, we identified that the first 2 steps are covered by existing services. However, for the third step, we need to create a new service. Why – since we would like to show customer details from the ERP but in addition to show account executive information which is stored in a non sap system. Therefore, we need to define a new service Backend Enterprise Services CRM ERP

9 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 Web Service ESB: Protocol Bridging Service Enablement Mapping / Routing … Service Engine Web Service CRM Adapter ERP Enterprise Services CRM

10 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? Process Engine Do we really need this call as a Web Service? Web Service Service Engine Web Service CRM Adapter ERP Enterprise Services CRM

11 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 Process Engine Bridging of QoS Models Web Service Bridging of QoS Models Service Engine Web Service CRM Adapter Bridging of QoS Models ERP Enterprise Services CRM

12 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 Web Service Service Engine Web Service CRM Adapter - Although SOA approach was used in creating the solution, there are no guarantees that the solution will no be severely impacted by changes to the service providers or their location. ERP Enterprise Services CRM What if this system is moved or replaced/ outsourced?

13 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 Web Service Service Engine Web Service CRM Adapter - - Lack of a holistic view of the solution makes it difficult to manage the solution (e.g. undeploy, restart, etc for all the runtimes need to be tracked manually) - Testing is another area where high level project view is important. Testing of the individual services is not enough. Testing of the overall solution requires a holistic view of the entire solution. ERP Enterprise Services CRM What happens when this service is shutdown for maintenance, etc?

14 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? Process Engine New Protocol New Runtime New App Web Service Service Engine Web Service CRM Adapter The question of how new application runtimes and communication infrastructures are plugged into the bus is separate from the impact on the developer productivity in utilizing the new engines, infrastructure, etc. The first question is concerning vendors of platforms, engines, adapters, etc. Where as the second question affect the masses of developers and IT shops that depends upon these developers. ERP Enterprise Services CRM

15 Agenda ESB Scenarios Why does ESB need SCA? SCA for ESB Programming

16 Key Areas of SCA How do I define, use and administer policies for non-functional aspects (QoS, etc)?  SCA Policy Framework Spec How do I configure and assemble components to create composites?  SCA Assembly Spec Properties Composite SOAP/ HTTP Component JMS JCA 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, …

17 Modeling the Composite Application with SCA
<component name=„SalesOrderTrackingComponent“ …> <implementation.bpel process=„tracking:SalesOrderTrackingProcess“/> <Reference name=„customerDetails“> <binding.jca ... /> Properties Ref CRM Java Internal wire Service BPEL Ref ERP Composite <Composite name=„SalesOrderTracking“ <Service > <Component > <Reference > <Reference name=„salesOrderDetails“> <binding.ws ....>

18 XML Representation of the Composition
<?xml version="1.0" encoding="ASCII"?> <composite xmlns=" name=“SalesOrderTracking" > <service name=“SalesOrderTracking“ promote=“SalesOrderTrackingComponent”> <binding.ws port=" 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"/> <reference name=“salesOrderDetails“ promote=“SalesOrderTrackingComponent/SalesOrderDetails”> <binding.ws port=“…"/> </reference> <reference name=“customerDetails“ promote=“CustomerDetailsComponent/customerDetails> <binding.jca …/> </composite> ERP Enterprise Services CRM BPEL Engine Java EE Server Java App CRM Adapter Web Service

19 ESB – Compositions programmed to the bus
BPEL Engine Java EE Server Java App Service Consumer Event Consumer SCA Domain Application with Eventing & BPM Application with Mediation and Mapping ESB Registry ERP Enterprise Services Composite deployment translated into deployment of components to their runtimes and configuration of proxies for communication Deployed services are published to the SCA Domain using logical names Service interactions within the domain use a proprietary communication mechanism Changes to service lo CRM Service Provider Event Provider B2B Partner Service-based communication Event-based communication

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

21 Email: sanjay.patil@sap.com
Questions? Sanjay Patil SAP Labs – Palo Alto

22 Copyright 2007 SAP AG All rights reserved
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden. Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte können Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwähnte SAP-Produkte und Services sowie die dazugehörigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Ländern weltweit. Alle anderen in diesem Dokument erwähnten Namen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu Informationszwecken. Produkte können länderspezifische Unterschiede aufweisen. Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vorabversion und unterliegt nicht Ihrer Lizenzvereinbarung oder einer anderen Vereinbarung mit SAP. Dieses Dokument enthält nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP®-Produkts und ist für SAP nicht bindend, einen bestimmten Geschäftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP übernimmt keine Verantwortung für Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht die Richtigkeit oder Vollständigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewähr, weder ausdrücklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschließlich, hinsichtlich der Gewährleistung der Marktgängigkeit und der Eignung für einen bestimmten Zweck sowie für die Gewährleistung der Nichtverletzung geltenden Rechts. SAP übernimmt keine Haftung für Schäden jeglicher Art, einschließlich und ohne Einschränkung für direkte, spezielle, indirekte oder Folgeschäden im Zusammenhang mit der Verwendung dieser Unterlagen. Diese Einschränkung gilt nicht bei Vorsatz oder grober Fahrlässigkeit. Die gesetzliche Haftung bei Personenschäden oder die Produkthaftung bleibt unberührt. Die Informationen, auf die Sie möglicherweise über die in diesem Material enthaltenen Hotlinks zugreifen, unterliegen nicht dem Einfluss von SAP, und SAP unterstützt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewährleistungen oder Zusagen über Internetseiten Dritter ab. Alle Rechte vorbehalten.