Towards Recovering the Broken SOA Triangle: A Software Engineering Perspective

1
Towards Recovering the Broken SOA Triangle A
Software Engineering Perspective

• Anton Michlmayr, Florian Rosenberg, Christian
  Platzer, Martin Treiber, Schahram Dustdar
• Distributed Systems Group
• Institute of Information Systems
• Vienna University of Technology
• http//www.infosys.tuwien.ac.at/
• http//www.VitaLab.tuwien.ac.at

2
Outline

• Introduction Motivation
• VReSCO Architecture Components
• Dynamic Binding Invocation in VReSCO
• Implementation
• Related Work
• Conclusion

3
SOA Theory vs. Practice

• SOA Model intends 3 actors using
  Find-Bind-Execute cycle
• Provider registers the service
• Consumer finds the service...
• ...binds to the service provider
• ...and executes the service
• SOA Practice Often no registry
• Public registries did not succeed
• Existing registry standards (UDDI and ebXML) are
  to heavy-weight
• Best practice Exchange WSDLs and endpoints per
  email

4
Motivation

• Current registry standards did not fully succeed
• Registries could be more than just a lookup
  service
• Dynamic SOA needs support for
• Dynamic (late) Binding Linking abstract services
  to concrete service implementations
• Service Composition using Quality of Service
  (QoS) attributes and metadata (e.g.,
  pre-/post-conditions)
• Notifications when certain events occur (e.g.,
  new service is published, QoS of services change,
  etc.)
• Service Versioning, Search, Service Metadata,
  etc.
• VReSCO aims at solving some of these issues

5
Motivating Example

• Telecommunication Company provides different
  services to different consumers in a uniform
  manner
• Public Services
• Customer Services
• Inhouse Services
• Partner / competitor services consumed
• Number Porting
• Supplier Services
• Payment Services

6
VReSCO Overview

• VReSCO Interfaces are exposed as web services
• Publishing Interface
• Metadata Interface
• Query Interface
• Composition Interface
• Notification Interface
• Binding Interface
• Clients access these interfaces using the VReSCO
  client library
• Additional components are hidden from the clients

7
VReSCO Components

• Publishing Metadata Service
• Used for static and dynamic publishing of
  services, associated metadata and QoS attributes
• Claim-based User Access Control
• Querying Searching Service
• Query finds exact matches of services in the
  registry
• Search finds fuzzy matches of service keywords
  using a Vector-space engine (Platzer et. al.
  ECOWS05)
• Binding Invocation Service
• Dynamically bind and invoke services
• Two types QoS- and content-based dynamic binding

8
VReSCO Components (contd)

• QoS Monitor (Rosenberg et. al. ICWS06)
• Measures performance and dependability attributes
  (e.g., Response Time, Execution Time,
  Availability,...)
• Client-side approach based on aspect-oriented
  programming (AOP) and low-level TCP analysis
• No access to service implementation is required
• Composition Service
• Goal Specify composition requests in a
  domain-specific language and return deployable
  compositions
• Notification Service
• Goal Receive notifications if certain events
  occur

9
Dynamic Binding Issues

• UDDI/ebXML provide no dynamic binding support
• Get a list of services by querying a registry
• Select one service and try to invoke it
• If the invocation fails take some action (e.g.,
  re-query registry, select another service, etc.)
• Client is responsible to carry out the rebinding
• BPEL provides limited support for dynamic binding
• Endpoints are usually statically defined at
  design time
• Dynamically reassign partnerLink to endpoints
• Assumption Service interfaces are identical

10
VReSCO QoS-based Binding

• Specify the desired service using a query (based
  on functional and non-functional attributes, e.g.
  QoS values)
• Rebinding is done dynamically using a rebinding
  strategy
• e.g., UpdateOnBetterMatch, UpdateIfNotAvailable,
  etc.
• Re-binding times Periodically, OnInvocation,
  OnRequest, etc.
• BindingListener notifies the client on rebinding

11
VReSCO Dynamic Invocation

• Current practice Pre-generated stubs
• Generate stubs from WSDL (e.g., WSDL2Java,
  SvcUtil)
• Invoke web services using these stubs
• Goal Dynamic Invocation using endpoint only
• Dynamic Invocation is done using dynamic service
  proxies
• ProxyFactory is used internally to generate
  proxies
• Download WSDL and metadata from given endpoint
• Create and compile proxy at run-time
• Proxy invokes service operations using reflection

12
VReSCO Binding Details
13
VReSCO Content-based Binding

• Content-based dynamic binding
• Define mapping between service category and
  service identifier used in the application logic
• Service category is part of service metadata
  (public taxonomies such as dmoz.org or
  user-defined taxonomies)

• Next step What if service interfaces do not
  match?
• Conversion rules are used to hide service
  heterogeneity
• Metadata define how input/output parameters are
  transformed
• Service proxy applies these rules on service
  invocation

14
Implementation

• VReSCO is implemented in .NET 3.0 using WCF
• Framework to build host service-oriented
  applications
• VReSCO will not be restricted to .NET
• VReSCO interfaces are exposed as web services
• Light-weight Registry Database
• Efficient and extensible data model
• Instead of using UDDI or ebXML
• Object-Relational Mapping (ORM)
• NHibernate for persisting services and metadata
• Query builds upon Hibernate Query Language (HQL)

15
Related Work

• Pautasso and Alonso SC05 discuss
• Different notions for modeling and evaluating
  bindings
• Integrate flexible binding in JOpera using
  reflection
• Di Penta et. al. present WS-Binder SOSE06
• Dynamic binding in BPEL processes using proxies
• Pre-execution global binding (using genetic
  algorithms) run-time re-binding (single service
  or workflow slice)
• SeCSE project Spanoudakis, Zisman et. al.
• Monitoring Discovery in SCS SCC05
• 3 types of service discovery Early, run-time,
  architecture-driven SOSE06

16
Conclusion

• SOA Triangle seems to be broken
• VReSCO infrastructure provides support for
• Registry database using a simple data model
• Publishing, Querying and Searching of services
• Monitoring the QoS attributes of services
• Dynamic binding and invocation of services
• Ongoing and Future Work
• Conversion rules to hide service heterogeneity
• Composition Engine
• Notification Engine

17
Thanks for your attention!

• Anton Michlmayr
• Distributed Systems GroupInstitut für
  Informationssysteme
• Vienna University of Technology
• http//www.infosys.tuwien.ac.at/
• http//www.VitaLab.tuwien.ac.at