1. 1 Web Services and Seamless Interoperability João Paulo Almeida (almeida@cs.utwente.nl) Luís Ferreira Pires (pires@cs.utwente.nl) Marten van Sinderen (sinderen@cs.utwente.nl) Centre for Telematics and Information Technology (CTIT), University of Twente

2. 2 Web Services are about… SOAP, WSDL, XML Schema, UDDI, BPEL4WS, …

3. 3 Web Services are about… and about… SOAP, WSDL, XML Schema, UDDI, BPEL4WS, … Web Services hosting platforms JAX-RPC / JSP / EJB / Java.NET / CLR / XML Web Services / C# CORBA / C++, Java, COBOL, … CCM Add your favourite: -middleware platforms -programming languages

4. 4 There are always other platforms involved

5. 5 Mismatch: Web Services x Hosting Platform Mappings: from and to Java in the JAX-RPC specification from and to.NET’s Common Type System from and to CORBA IDL recurring: and then to programming languages Can be automated, and spare us from a lot of work (WSDL may be “human readable” (?) but I prefer Java)

6. 6 Mismatch: Web Services x Hosting Platform Mismatch Example: A Java developer is used to passing remote object references as parameters in J2EE Not if an object is to be exposed as a web service endpoint (JAX- RPC) Lots of patterns used will depend on references

7. 7 Mismatch: Web Services x Hosting Platform Divergences in the behavior of components of different technology domains E.g., use of the Naming Service in CORBA Even if the mapping from SOAP/IIOP were transparent, requesters would have to be able to use the Naming Service Rule of thumb: Avoid exposing such “internal” characteristics in a web services definition Works with trivial web services Assumes services can be simplified regardless of complexity of service requester - service provider interactions

8. 8 Challenge: Seamless interoperation Developers should be shielded from: the existence of different middleware platforms and programming languages and from the resulting mismatch We need support to accommodate the differences, to: provide abstractions that are suitable and intuitive for application developers, and re-use specifications and components defined in terms of the abstractions of particular technology domains

9. 9 Opportunity: MDA and platform-independence

10. 10 Risk: it starts again...