bridging the gap between legacy services and web services

Bridging the Gap between Legacy Services and Web Services

Tegawendé F. BissyandéJoint work with

L. Réveillère, Y-D Bromberg, J.L. Lawall and G. Muller

Thursday, December 2, 2010

Web Services

Bridging the Gap between Legacy Services and Web Services Middleware 2010, Bangalore, INDIA

Web service

Authentication

Desktop apps

Accounting

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

Stocks

Weather

Databases

Web Services realm

Web Services realm


Two worlds

Legacy services domain

Corporate Email

Domotics service disovery

File sharing

Streaming and VoIP

Network supervision

…

IMAP POP3

SMTP

RTSP MGCP

SIP SIMPLE

TFTP

NNTP

FTPUPNPSLP

Salutation

SNMP

SGMP CMIP

NTP STUN

…

Heterogeneous Application Layer Protocols (ALPs)


Migration is a Challenge (1)

1st Approach : Re-Write the Legacy service into WS Needlessly Invasive

o Hard to recover the logic perfectly

Expensive and time-consumingo Investments made in existing systems are lost

Unreliable and restrictedo New protocols require new clients

A few attempts : WSEmail, WIP/WSIP, etc.



2nd Approach : Implement a WS Interface to legacy services Leverages best the value locked in legacy services

It still works for me

I can integrate this service now



2nd Approach : Implement a WS Interface to legacy services Leverages best the value locked in legacy services

Approaches differ in :o Complexity

Existing tools are not always appropriate

Solutions are often partial (support of different types of legacy services)

o 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


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


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

Our generative language-based approach (1)


Janus : Description of the operations that the wrapper must support

Legacy ALPsspecifications

Descriptions of the legacyservice functionalities

High-level descriptionsJanusz2z

z2z: Protocol specifications (Middleware’09)



Two automated generation steps Generation of the remaining z2z specifications and WSDL Generation of the wrapper C code



WS description WS protocols specifications+WS-ALP translation specification

WS message parsers

Consistency checks + Generation

Contract-first

High-level descriptions

Translation engine

Generation of C code

Janusz2z



A dedicated runtime system Optimized processing of WS requests and ALP messages



WS description WS protocols specifications+WS-ALP translation specification

WS message parsers

Consistency checks + Generation

Contract-first

A deployable WS wrapper

Translation engine

Generation of C code

Runtime system

High-level descriptionsJanusz2z

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

Development Scenario


1

2

Compiler

3

4?

Case study : WS - IMAP


How to describe a service with in Janus?

Janus by the example : Describing a WS Interface for an IMAP server


import protocol.imap.*;import utils.List;

service ImapServer (String hostname, int port){ /* Janus datatypes */ class Mail { int id; String body; }

/* Janus operations */ List<Mail> pullMails(String hostname, String login,... ){...}

serverResponse imapCreateFolder(..., String foldername, ...) {...}}

Contents of a WS message encapsulating a “mail”.

The WS will be deployed here

Which legacy service functionalities are extracted

Janus by 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”)throw new ServiceFault(“[login]”, “authentication failure”);

req = new selectFolder(foldername); resp = req.send();... req = new listMessage(); resp = req.send(); ... ids = List.parse2int (resp.line, “ ”); for (int id :ids) {

req = new getMail(id); ... m = new Mail(id, resp.line); ... } req = new Logout(); ... return mails;}

The variables for assigning request data

Creating the appropriate request according to the protocol description

You don’t have to manage how the messages are sent in the network

If it fails, stop, and send a WS Fault messageGet all the mail you can, and log out!

Send back the operation results

How should the WS wrapper handle a WS Invocation request on the

« pullMails » operation?

Janus by the example : Adding features


import protocol.rtsp.*;service mediaPlayer(...) {String SESSION_ID;...Media PLAY(PlayRequest preq){ ... req = new Setup(...); resp=req.send(); SESSION_ID = resp.sessionId; ...}

Media STOP(StopRequest sreq) { ... req = new Teardown(..., SESSION_ID); ...}...}

import protocol.ssdp.*;multicast service controlPoint(...) {...List<UPnPService> SEARCH(SearchRequest sreq){ ...}...}

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

z2z specifications: Complex translation module code, WS

protocol descriptions, WS message parsers

Low-level efficient C codeStraightforward code

How much code…


Developer code Generated Code

Legacy service+ ALPs

descriptions

z2z specs, parsers, WSDL docs

Wrapper source code

(LoC)

WS wrapper (size in KB)

Wrapper Runtime System

Total

IMAP Server wrapper

IMAP 345 680 1861 44 80 124

How much code…




descriptions


Wrapper source code

(LoC)



Total

IMAP Server wrapper

IMAP 345 680 1861 44 80 124

SMTP Server wrapper

SMTP 204 513 918 24 80 104

How much code…




descriptions


Wrapper source code

(LoC)



Total

IMAP Server wrapper

IMAP 345 680 1861 44 80 124

SMTP Server wrapper

SMTP 204 513 918 24 80 104

Media Service wrapper

RTSP +SDP

582 646 2488 48 80 128

UPnP service discovery

UPnP 375 540 1877 32 80 112

Around 77% of the final code is provided by the compiler

Code size < 130 KB

Do we perform well?


Janus wrappers vs. hand-made wrappers Janus runtimeTomcat server + general purpose WS stack

Do we perform well?


Janus wrappers benefits from a fine grained runtime system

WS – SMTPWS – IMAP

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


Questions, comments?

Thursday, December 2, 2010

bridging the gap between legacy services and web services

Documents

legacy services approaches

web services realmbridging

web servicesmiddleware

legacy servicesit

web servicesbridging

web servicestegawend

ws interface

new protocols4