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. [ECOWS‘05]) • Binding & Invocation Service: • Dynamically bind and invoke services • Two types: QoS- and content-based dynamic binding

8. 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

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 [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]

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 ViennaUniversityofTechnology http://www.infosys.tuwien.ac.at/ http://www.VitaLab.tuwien.ac.at