The Service Revolution – software engineering without programming languages
Gustavo Alonso
Institute for Pervasive Computing Department of Computer Science
Swiss Federal Institute of Technology (ETH Zurich)
ECOWS’06 - Zurich
The two sides of SOA
The beautiful garden = Semantic Web
Fully transparent integration at the semantic level
Semantic matchmaking
Automatic composition through pre- and post- conditions
Theorem proven driven QoS
Automatic, world wide service search This will not work any time soon:
It is not a real problem
Ignores that the service matching is not interface based
“AI mistakes” revisited = it is not the logic but the underlying data
Ignores the power of vertical standards in this area
The Holy Grail: Automatic Software Generation
High Level Declarative Programming
Enactment, enforcement
adaptation, failure handling,
notification Extension,
compilation, resolution,
monitoring Programmer domain
The ugly city = System Integration
SOA is not an abstract idea, it is a response to
Very well defined needs in enterprise computing
Changes in technology (cluster, networking, distribution)
The Internet
Business-to-Business integration
Enterprise Computing coming of age
Large scale distributed information systems
To understand SOA, the key is to understand the underlying problems, not just the technology involved in solving them
Automatic Plumbing Generation
The promise of SOA is to facilitate integration by
Letting the system automatically decide on integration decisions - protocols to use
- intermediate processing needed - routing and distribution
- data transformations
Enforcing standards for defining and operating with services
Enforcing the use of service interfaces
Related to this, there are many additional opportunities:
Languages for orchestration and composition
Reasoning about compositions
Integration by non-experts (IBM’s situational integration)
Facilitate integration
In the medium term, service
orientation will solve the problem of connectivity at the syntax level
Model Driven Architectures
Business Processes
Orchestration
extensions
protocols
data map
mode
extensions
protocols
data map
mode Programmer domain
System Domain
Example of easier integration
WS Invocation Framework
Use WSDL to describe a service
Use WSIF to let the system decide what to do when the service is invoked:
- If the call is to a local EJB then do nothing - If the call is to a remote EJB then use RMI - If the call is to a queue then use JMS
- If the call is to a remote Web service then use SOAP and XML
There is a single interface description, the system decides on the binding
This type of functionality is at the core of the notion of Service Oriented Architecture
SOA and web services are there because of the need to solve the system integration problem not because of any immediate need for the semantic services web
Service Revolution: integration not programming
The key issue in enterprise computing today is integration:
Enterprise Application Integration
Transactional and Message Oriented Middleware
Enterprise Software Bus
Data integration
Enterprise-wide Architectures
Programming is to integration what laying bricks is to architectural design
What SOA is about
SOA is about:
Non-functional properties: performance, reliability, security, …
Large scale composition
Document and message based interaction
Distributed systems architecture
Run time properties and contracts
Protocols, data formats
Conventional software engineering cannot address:
SOA and web services bring to the fore the dependencies of existing programming
languages on (single CPU) hardware concepts
Two contemporary examples
XML
Programming language variables
Semi-structured Documents
Procedural interfaces
Document based interfaces
Behavioral interfaces
Variable assignment
Declarative queries
Impedance mismatch
Asynchronous Data Streams
Procedural control flow
Event based control flow
Language based distribution
Platform based distribution
Behavioral interfaces
Sequential programs
Highly parallel and concurrent
Model mismatch
Objects – Components - Services
Object orientation
Compiler based
Object/method interfaces Behavior explicit in object Program is closed world Programming language Compiler based
Object/method interfaces Behavior explicit in object Program is closed world Programming language
Component systems
Middleware based Component interfaces Behavior in composition Program is open world Middleware + plumbing Middleware based
Component interfaces Behavior in composition Program is open world Middleware + plumbing
Service platforms
Container + middleware Service interfaces
Behavior in code, container and composition
Autonomic, large scale Container + middleware Service interfaces
Behavior in code, container and composition
Autonomic, large scale
Programming languages Component Models - Middleware
Service oriented architectures
Services not components
The two sides:
Integration is based on services
Programming is based on objects and components
There are similarities in theory, in practice they are very different
Services are not object oriented
Services have document based interfaces
Services have a behavioral contract with their consumers
Services are reusable by definition
Services are (should be) loosely coupled
Services are autonomous
Services have (very) explicit boundaries
The post-modern programmer: there is no perfect OO language, there is no
universal solution to all software development problems
Steve Cook: Object Technology – A Grand Narrative?
ECOOP’06
SOA is HAD
HAD is an old concept in distributed information systems
H = Heterogeneous
A = Autonomous
D = Distributed HAD is
The essence of and the reason for SOA
The problem SOA tries to solve
HAD is where the OO paradigm has failed
CORBA
Object Oriented Databases
Reuse
No HAD in OO: OO Detours
(based on Steve Cook, ECOOP 06) Reuse Problem: Objects ignore the environment where they live
Real objects in different systems are autonomous
Real objects in different systems are heterogeneous
Distribution Problem: Abstracting away the problem’s essence
Tight coupling (language, interaction, development, operation)
Database Problem: impedance mismatch
Still present with XML, messages, and events
Modeling Problem: from OO models to software systems
Objects are too low level to model real HAD systems
The new Software Engineering for SOA
WS standards
rom: roadmap.cbdiforum.com/reports/protocols/
Separation of concerns
qcc.cuny.edu/xmlcenter/protocolstack.htm
The value of new technology
There is no problem in system design that cannot be solved by
adding a level of
indirection. There is no performance problem that cannot be solved by
removing a level of
indirection.
Services = run time Software Engineering
A Service contract involves the interface, the Service Level
agreement and QoS
Contracts are key to be able to develop, debug, optimize and
maintain systems developed as a combination of services
Service contracts are not the static, compile time pre-
and post-conditions of conventional programming
languages
They are an additional software layer in charge of the dynamic
aspects of using services Service contracts are not the
static, compile time pre- and post-conditions of conventional programming
languages
They are an additional software layer in charge of the dynamic
aspects of using services
Crash course on dynamic AOP
An aspect has
A join-point: where in the code the advice has to be executed
An advice: the code that needs to be executed when the join-point is reached
Adaptation is achieved by
weaving an aspect at run time that will execute the advice when a particular event in the execution occurs
Example, replace all methods Data_Transfer, with a new method Data_Transfer2.
The join-point identifies the method (Data_Transfer)
The advice contains the new method (Data_Transfer2).
When Data_Transfer method is called, Data_Transfer2 is executed instead
• Make app state persistent
• Make all calls transactional
Trap all calls to me
and encrypt using this module Trap all calls
to me
and encrypt using this module
Encrypted calls Encrypted calls
I only accept encrypted calls Sorry, I do not
encrypt calls
Run Time Service Container
Trap any state change Trap any state
change Add a TP-
monitor Add a TP- monitor
Popovici et al., ECOOP 2003
PROSE: a platform for run time adaptation
PROSE allows designers to modify any aspect of a running Java:
At run time
Without stopping or reloading
Using Java to express the changes
Using a rich collection of interception points
PROSE is a real system widely used:
Prose 2002: adaptation through run time debugger
Prose 2004: adaptation through labeling and JIT
Prose 2006: around advice through JIT manipulation
Download and more info from http://prose.ethz.ch
More run time: Service composition
JOpera Distributed Kernel
Navigator Navigator
Dispatcher Dispatcher Dispatcher
Process Template
Plugin Process Template
Plugin
Process Template
Plugin Process Template
Plugin
UNIXUNIXUNIX SOAPSOAPSOAP JAVAJAVAJAVA ............
State Information
Storage Event Queues
Task Execution Scheduler Kernel
Download and more information: www.jopera.ethz.ch
Where we all miss the point
JOpera (like most similar systems, including BPEL):
Can compose services but cannot really compose processes - Modularity of composition is not well understood
The problem is not the control flow but the data flow - Impedance mismatch still there
Too dependent of graphic representation
- Certain complex operations will never be graphical
A process is software
- Version control, documentation, comments
Cannot really support large scale design - The workflow is only one aspect
- Garbage collection, exceptions, concurrency, …
Conclusions
SOA and web services could be a passing fashion The problems they try to tackle will remain
Cost of application integration
Lack of models, languages, and tools
Non-functional properties of large scale systems
Composition
Services
The first step to address these problems is to recognize them as fundamental problems and not just things that cannot be done
within the current paradigms
