Web Business Platforms On The Cloud An Engineering Perspective

1. WEB BUSINESS PLATFORMS ON THE ‘CLOUD’ – AN ENGINEERING PERSPECTIVE Harshavardhan “Harsh” Jegadeesan SAP Labs, India

2. CONTEXT <ul><li>Web-Business Platforms </li></ul><ul><li>Platform Strategy </li></ul><ul><ul><li>“ Opening-up” of the platforms using SOA-based web APIs </li></ul></ul><ul><ul><li>Platform Adoption and Creation of an ecosystem – of developers, partners and entrepreneurs – around the platform </li></ul></ul>

3. So what are the Engineering Challenges faced by platform owners while adopting a Platform Strategy? Granularity Elastic Infrastructure Multi-tenancy Integration Customization …

4. Handling heterogeneity in the service ecosystem SOAP vs. REST WS-* XML / JSON OASIS / W3C … Evolving Standards Problem #1

5. Issues with automated service consumption Inadequate service descriptions developerKey merchantID Lean Service Metadata Problem #2

6. Service Differentiation in a Services marketplace #3 “ Unintrusive” Service Differentiation Service Capability on-offer Terms of Offer

7. Catering to heterogeneous service consumers Language-specific APIs Transport Protocols Data Standards Browsers Mash-ups Applications Creation and Maintenance of Consumption APIs #4

8. How can customers extend the services? Support for Customizing and Extending Service Offerings #5

9. Business users prefer visual paradigms for specifying service artifacts Support for Visual Syntax for Service Specification #6

10. How can platform owners address these challenges? How would a solution approach look like? What criteria would any solution satisfy?

11. CRITERIA FOR SOLUTION (1) <ul><li>Criterion #1: A solution must support Service Representation at a conceptual and technology agnostic level </li></ul><ul><li>Criterion #2: The Service Representation must be easily convertible to executable service specifications </li></ul><ul><li>Criterion #3: The Service Representation must have minimal concepts supporting maximal expressiveness </li></ul>

12. CRITERIA FOR SOLUTION (2) <ul><li>Criterion #4: The Service Representation must support different roles involved in the development of the service </li></ul><ul><li>Criterion #5: The Service Representation must have strong underpinnings in the application domain </li></ul><ul><li>Criterion #6: The Service Representation must be open-standards compliant and must leverage existing tools </li></ul>

13. CRITERIA FOR SOLUTION (3) <ul><li>Criterion #7: The solution must support unintrusive changes to commissioned services to support differentiation </li></ul><ul><li>Criterion #8: The solution must support creation of language-specific Web APIs to support a heterogeneous platform audience </li></ul>

14. WHAT DOES A ‘SERVICE’ REPRESENT? <ul><li>A Service represents: </li></ul><ul><ul><li>Capability on-offer </li></ul></ul><ul><ul><ul><li>Represents the underlying business function or capability </li></ul></ul></ul><ul><ul><li>Terms of Offer </li></ul></ul><ul><ul><ul><li>Represent the terms at which this capability is offered. </li></ul></ul></ul><ul><li>E.g. SHIPPINGSERVICE </li></ul><ul><ul><li>Capability on-offer: to ship an item from one place to another </li></ul></ul><ul><ul><li>Terms of Offer: Cost, Delivery time, Payment Options </li></ul></ul>

15. SOLUTION CONTEXT - REFERENCE ARCHITECTURE

16. OUR SOLUTION APPROACH <ul><li>Our solution approach is based on Model-Driven development. </li></ul><ul><li>Metamodels </li></ul><ul><li>Six Model Views </li></ul><ul><ul><li>We have developed Six Model Views to address different facets of coarse services development </li></ul></ul>Domain-Driven Design Metamodel Resources Metamodel Services Metamodel

17. MODEL VIEWS & VIEW POINTS Model View Viewpoint addresses Service Description View Description and classification of Services based on ownership domain Service Capability View Defines the capability on-offer. Description of Service, Service Properties, Interfaces, Operations, Messages and message-exchange pattern. Service Policy View Defines the term of offer of a service. Definition of Service Policies. Service Realization View Defining the service provisioning approach, either service implementation from underlying IT assets or through composition of constituent services Service Mediation View Defining how existing services could be re-purposed to address different consumer goals using process or data mediation. Service Deployment View Describes service interaction points and service invocation mechanisms

18. METAMODELS, MODELS & TRANSFORMATIONS Metamodels Model-to-Model Transformation Models Executable Specifications Provisioning Code (Java, .NET) SOAP / REST Interfaces Service Descriptions (WSDL / WADL) Policy Description (WS-Policy) Model-to-Text Transformation Consumption APIs (MOF 2) UML Infrastructure DDD Metamodel Resources Metamodel Services Metamodel Domain Model Resource Model Service Description Model Service Capability Model Service Policy Model Service Realization Model Service Mediation Model Service Deployment Model

19. USING THE MODEL TO CREATE SERVICE CONSUMPTION APIS Models Technology Platforms (Programming Languages) Domain Model Resources Model Services Model (Service Capability Model) UML2 Model Classes Diagram) Model-to-Model Transformation Model-to-Model Transformation Model-to-Model Transformation Model-to-Text Transformation DLL Client-Library .NET Platform JAR Files Java Platform PHP, Ruby, Pearl, Python

20. CONCLUDING REMARKS <ul><li>By abstracting service representations using conceptual models we support: </li></ul><ul><ul><li>Increased longevity of the solution </li></ul></ul><ul><ul><li>address the evolving standards problem, lean service metadata problem </li></ul></ul><ul><li>By defining “terms of offer” as policies, we support unintrusive change of terms of offer to make service offering attractive </li></ul><ul><li>Using model-to-model and model-to-text transformations we support easy creation and evolution of service consumption APIs </li></ul>

21. QUESTIONS & DISCUSSIONS

22. <ul><li>ABSTRACT </li></ul><ul><li>Web businesses such as eBay®, Amazon® and a whole lot of others have long seized to be mere websites; they have morphed into web business platforms on the "cloud". By adopting a platform strategy, they are building an ecosystem of developers, partners and entrepreneurs to build innovative applications for customers. As platform owners, catering to his heterogeneous ecosystem is a huge engineering challenge in itself. This session, we would discuss some of these challenges along with some recipes to overcome them. </li></ul>Harsh currently works as a Project Lead in the SOA team within the Business Suite organization in SAP Labs, India. Prior to this, he was working with the Research & Breakthrough Innovation group on SAP® ByDesign®. He follows his passion for teaching, as an adjunct faculty with BITS, Pilani, teaching graduate courses is software engineering. He actively contributes to JournalServer.Org, a free library of scholarly articles. His areas of interest include service-oriented architectures, enterprise systems and business process platforms. He can be reached at: [email_address] SPEAKER BIO