1 towards recovering the broken soa triangle: a software engineering perspective anton michlmayr,...
TRANSCRIPT
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
Outline
Introduction & Motivation VReSCO Architecture & Components Dynamic Binding & Invocation in VReSCO Implementation Related Work Conclusion
2
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
3
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
4
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
5
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
6
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. [ECOWS‘05])
Binding & Invocation Service: Dynamically bind and invoke services Two types: QoS- and content-based dynamic binding
7
VReSCO Components (cont‘d)
QoS Monitor (Rosenberg et. al. [ICWS‘06]): 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
8
Dynamic Binding Issues
UDDI/ebXML provide no dynamic binding support1. Get a list of services by querying a registry
2. Select one service and try to invoke it
3. 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
9
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
10
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
11
VReSCO Binding Details
12
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)
13
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
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)
14
Related Work
Pautasso and Alonso [SC‘05] discuss: Different notions for modeling and evaluating bindings Integrate flexible binding in JOpera using reflection
Di Penta et. al. present WS-Binder [SOSE‘06]: 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 [SCC‘05] 3 types of service discovery: Early, run-time, &
architecture-driven [SOSE‘06]
15
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
16
17
Thanks for your attention!
Anton MichlmayrDistributed Systems GroupInstitut für InformationssystemeVienna University of Technology
http://www.infosys.tuwien.ac.at/ http://www.VitaLab.tuwien.ac.at