1. 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 2

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 3

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 4

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 5

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 6

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 7

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 8

9. Dynamic Binding Issues  UDDI/ebXML provide no dynamic binding support 1.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

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 10

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 11

12. VReSCO Binding Details 12

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) 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

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) 14

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

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 16

17. 17 Thanks for your attention! Anton Michlmayr Distributed Systems Group Institut für Informationssysteme Vienna University of Technology http://www.infosys.tuwien.ac.at/ http://www.VitaLab.tuwien.ac.at