Bridging the Gap between Legacy Services and Web Services

1. Thursday, December 2, 2010 Bridging the Gap between Legacy Services and Web Services Tegawendé F. Bissyandé Joint workwith L. Réveillère, Y-D Bromberg, J.L. Lawall and G. Muller

2. Web Services • A service that : • can describe itself • Allow others to locate it • can be readily invoked by others • Mature technologies for : • Machine-to-machine communications • Service composition • Well-known set of standards : • SOAP/WS-*, REST, • WS-BEPEL, WS-CDL Authentication Web service Desktop apps Stocks Weather Accounting Web Services realm Databases

3. Two worlds SLP UPNP Salutation Heterogeneous Application Layer Protocols (ALPs) IMAP POP3 SMTP Corporate Email File sharing Domotics service disovery Network supervision Streaming and VoIP … RTSP MGCP Web Services realm Legacy services domain SIP SIMPLE NTP STUN SGMP CMIP NNTP … SNMP FTP TFTP

4. Migration is a Challenge (1) • 1st Approach : Re-Write the Legacy service into WS • Needlessly Invasive • Hard to recover the logic perfectly • Expensive and time-consuming • Investments made in existing systems are lost • Unreliable and restricted • New protocols require new clients • A few attempts : WSEmail, WIP/WSIP, etc.

5. Migration is a Challenge (2) • 2nd Approach : Implement a WS Interface to legacy services • Leverages best the value locked in legacy services I can integrate this service now It still works for me

6. Migration is a Challenge (2) • 2nd Approach : Implement a WS Interface to legacy services • Leverages best the value locked in legacy services • Approaches differ in : • Complexity • Existing tools are not always appropriate • Solutions are often partial (support of different types of legacy services) • The details in the extraction of service functionalities • Black box approach (You may not get what you had before  ) • Grey box approach(We’ll try to break it down to what we can  ) WS wrapper = WS interface to the functionalities of an ALP-based application

7. Developing a wrapper (1) • Implementation of a gateway between two worlds • Need to master the technologies involved • Expertise in WS paradigm + knowledge on ALPs • How to reproduce the interaction models(sessions, multicast, multiplicity of ALPs, …) • Efficiency and safety constraints • Understanding of low-level network programming • Knowledge on systems programming

8. Developing a wrapper (2) • WS has characteristics one must take into account • SOAP+HTTP lead to complex and verbose messages • Functionalities must be extracted accordingly • Often unwise to mimic protocol behaviors • Message transmission synchrony • Messages return values

9. Our generative language-based approach (1) Janus:Description of the operations that the wrapper must support z2z: Protocol specifications (Middleware’09) z2z • High-level descriptions Janus Legacy ALPs specifications Descriptions of the legacy service functionalities

10. Our generative language-based approach (1) • Two automated generation steps • Generation of the remaining z2z specifications and WSDL • Generation of the wrapper C code z2z • High-level descriptions Janus Legacy ALPs specifications Descriptions of the legacy service functionalities Consistency checks + Generation Contract-first WS protocols specifications+ WS-ALP translation specification WS message parsers WS description Generation of C code • Translation engine

11. Our generative language-based approach (1) • A dedicated runtime system • Optimized processing of WS requests and ALP messages z2z • High-level descriptions Janus Legacy ALPs specifications Descriptions of the legacy service functionalities Consistency checks + Generation Contract-first WS protocols specifications+ WS-ALP translation specification WS message parsers WS description Generation of C code • Translation engine • A deployable WS wrapper • Runtime system

12. The Janus DSL • Need to enforce good practices in WS development • Contract-first strategy • Need for a better programming language • Type safety • Support for stateful WS • Expressiveness and Extensibility • Hide subtleties of WS paradigm and ALPs • Need automation to support wrapper developers • Account for the issues in system and network programming

13. Development Scenario 1 2 ? 3 4

14. Case study : WS - IMAP How to describe a service with in Janus?

15. Janusby the example : Describing a WS Interface for an IMAP server import protocol.imap.*; import utils.List; service ImapServer (String hostname, intport){ /* Janus datatypes */ class Mail { int id; String body; } /* Janus operations */ List<Mail> pullMails(String hostname, String login,... ){...} serverResponseimapCreateFolder(..., Stringfoldername, ...) {...} } The WS will be deployed here Contents of a WS message encapsulating a “mail”. Which legacy service functionalities are extracted

16. Janusby the example : Describing a WS Interface for an IMAP server /** Retrieve all unread mail from an IMAP Server*/ List<Mail> pullMails(String hostname, String login, ...) { request<imap> req; response<imap> resp; Mail m; List<Mail> mails = new List<Mail> (); ... req = new Login(login, passwd); resp = req.send(); if (resp.code == “error”) thrownewServiceFault(“[login]”, “authentication failure”); req = newselectFolder(foldername); resp = req.send();... req = newlistMessage(); resp = req.send(); ... ids = List.parse2int (resp.line, “ ”); for (int id :ids) { req = newgetMail(id); ... m = new Mail(id, resp.line); ... } req = new Logout(); ... returnmails; } How should the WS wrapperhandle a WS Invocation request on the « pullMails » operation? The variables for assigning request data You don’t have to manage how the messages are sent in the network  Creating the appropriate request according to the protocol description If it fails, stop, and send a WS Fault message Get all the mail you can, and log out! Send back the operation results

17. Janusby the example : Adding features import protocol.rtsp.*; service mediaPlayer(...) { String SESSION_ID; ... Media PLAY(PlayRequestpreq){ ... req = new Setup(...); resp=req.send(); SESSION_ID = resp.sessionId; ... } Media STOP(StopRequestsreq) { ... req = new Teardown(..., SESSION_ID); ... } ... } Global variables are detected as session variables // Use of a WS standard to support session Switch from SOAP/HTTP to SOAP/UDP and rely on WS-Addressing import protocol.ssdp.*; multicast service controlPoint(...) { ... List<UPnPService> SEARCH(SearchRequestsreq){ ... } ... }

18. How much code… Straightforward code Low-level efficient C code z2z specifications: Complex translation module code, WS protocol descriptions, WS message parsers

19. How much code…

20. How much code… Around 77% of the final code isprovided by the compiler Code size < 130 KB

21. Do we perform well? • Janus wrappers vs. hand-made wrappers • Janus runtime • Tomcat server + general purpose WS stack

22. Do we perform well? Janus wrappers benefits from a fine grained runtime system WS – IMAP WS – SMTP

23. Concluding remarks • How do we improve wrapper development? • Accommodating WS developers • Programmers are familiar with Java-like syntax • Encapsulating subtle and error-prone code • WS developer can focus on the service description • Benefiting from the DSL approach • Important features are provided within the language rather than in a library as in Java • Code can be checked for various coherence properties • Future work • More instanciations • Other applications domains & other middleware protocols (RMI, CORBA) • Extending Janus runtime system • REST support, more WS-* standards

24. Thursday, December 2, 2010 Questions, comments?