WEB BUSINESS PLATFORMS ON THE ‘CLOUD’ – AN ENGINEERING PERSPECTIVE Harshavardhan “Harsh” Jegadeesan Business Suite Core SAPLabs, India As part of cloud symposium, at ACM Bangalore Compute 2009

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

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

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

4. XML / JSON
OASIS / W3C …
#1 Evolving Standards Problem
Handling heterogeneity in the service
ecosystem

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

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

7. #4
Creation and Maintenance of
Consumption APIs
Catering to heterogeneous service consumers
Browsers
Mash-ups

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

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

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)
Criterion #1: A solution must support Service

Representation at a conceptual and technology
agnostic level
Criterion #2: The Service Representation must be

easily convertible to executable service
specifications
Criterion #3: The Service Representation must

have minimal concepts supporting maximal
expressiveness
11

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

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

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

15. SOLUTION CONTEXT
- REFERENCE ARCHITECTURE
15

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

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

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

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

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

21. QUESTIONS
&
DISCUSSIONS
21

22. ABSTRACT
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 quot;cloudquot;. 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.
SPEAKER BIO
Harsh currently works as a Project Manager 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:
22
harshavardhan.jegadeesan@sap.com