100 likes | 228 Vues
This paper discusses the challenges and solutions associated with seamless interoperability in web services, addressing mismatches between different hosting platforms and programming languages. It explores key technologies like SOAP, WSDL, and JAX-RPC while emphasizing the need for general abstractions that shield developers from underlying complexities. The authors advocate for the Model-Driven Architecture (MDA) to promote platform independence and improve service interactions, ultimately facilitating the integration of diverse systems and enhancing usability for application developers.
E N D
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
Web Services are about… • SOAP, WSDL, XML Schema, UDDI, BPEL4WS, …
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
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)
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
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
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