service-oriented computing: bringing business systems to the web

6
May June 2007 IT Pro 19 1520-9202/07/$25.00 © 2007 IEEE Published by the IEEE Computer Society W EB 2.0 Service-Oriented Computing: Bringing Business Systems to the Web Yann Le Blevec, Chirine Ghedira, Djamal Benslimane, and Xavier Delatte T he notion of “service” has spurred major evolutions for both information systems and the Web. A software application is no longer considered a monolithic com- ponent; it can be divided into services that are smaller components defined by their function and accessible through well-defined interfaces and protocols. As a result, IT actors are using service-oriented architectures (SOAs) to re- model the information systems of many compa- nies while the Web is increasingly becoming a programmable place. In both domains, develop- ers build composite client applications to con- sume these services. Even boundaries between enterprise services and Internet services are vanishing. Some companies, such as StrikeIron (http://www.strikeiron.com) provide enterprise services that were previously always hosted inter- nally—like customer relationship management solutions. As a consequence, companies now have the technologies required to bring their business online. With Web services, private business processes can be exposed to partners through pub- lic composite Web applications.When new proj- ects emerge, companies need guidance to properly handle such work. In this context, we aim to pro- vide companies solutions—through a methodol- ogy, an architecture, and technical choices—that will help them solve generic problems such as security and application conception. CONNECTING BUSINESS SYSTEMS WITH WEB APPLICATIONS Our approach consists of four generic steps (see Figure 1a, next page) to provide Web services to business partners: 1. identify the required business functionalities, 2. implement the corresponding services, 3. expose these services to external partners, and 4. design a client (Web) application. We divided each step into smaller tasks that cross- domain actors, or experts, support. For example, identifying business functionalities requires the knowledge of business users and back-end experts.These actors will then formalize the busi- ness needs according to the systems’ capabilities. Turning business systems into enterprise services As we mentioned, the emerging concept of serv- ice is becoming critical. Unfortunately, classical As more business is done online, companies must realize the new opportunities that Web services technology can offer by cost effectively opening their information systems to their business partners.

Upload: x

Post on 10-Mar-2017

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Service-Oriented Computing: Bringing Business Systems to the Web

May ❘ June 2007 IT Pro 191520-9202/07/$25.00 © 2007 IEEE P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

W E B 2 . 0

Service-OrientedComputing: BringingBusiness Systems tothe Web

Yann Le Blevec, Chirine Ghedira, Djamal Benslimane, and Xavier Delatte

T he notion of “service” has spurred majorevolutions for both information systemsand the Web. A software application isno longer considered a monolithic com-

ponent; it can be divided into services that aresmaller components defined by their functionand accessible through well-defined interfacesand protocols. As a result, IT actors are usingservice-oriented architectures (SOAs) to re-model the information systems of many compa-nies while the Web is increasingly becoming aprogrammable place. In both domains, develop-ers build composite client applications to con-sume these services. Even boundaries betweenenterprise services and Internet services are vanishing. Some companies, such as StrikeIron(http://www.strikeiron.com) provide enterpriseservices that were previously always hosted inter-nally—like customer relationship managementsolutions.

As a consequence, companies now have thetechnologies required to bring their businessonline. With Web services, private businessprocesses can be exposed to partners through pub-lic composite Web applications. When new proj-ects emerge,companies need guidance to properlyhandle such work. In this context, we aim to pro-

vide companies solutions—through a methodol-ogy, an architecture, and technical choices—thatwill help them solve generic problems such assecurity and application conception.

CONNECTING BUSINESS SYSTEMSWITH WEB APPLICATIONS

Our approach consists of four generic steps (seeFigure 1a, next page) to provide Web services tobusiness partners:

1. identify the required business functionalities,2. implement the corresponding services,3. expose these services to external partners, and 4. design a client (Web) application.

We divided each step into smaller tasks that cross-domain actors, or experts, support. For example,identifying business functionalities requires theknowledge of business users and back-endexperts.These actors will then formalize the busi-ness needs according to the systems’ capabilities.

Turning business systems into enterprise services

As we mentioned, the emerging concept of serv-ice is becoming critical. Unfortunately, classical

As more business is done online,companies must realize the new opportunities that Web services technology can offer by cost effectively opening their informationsystems to their business partners.

Page 2: Service-Oriented Computing: Bringing Business Systems to the Web

20 IT Pro May ❘ June 2007

W E B 2 . 0

information systems are not nativelyservice oriented. Consequently, com-panies will have to adopt an SOA intotheir information system. The migra-tion might be progressive, with anopportunistic use of services in new ITprojects,or sudden,with a single migra-tion project. SOAs typically include aservice layer on top of existing systemsto create loosely coupled components.Implementing this new layer in aninformation system requires deployingseveral systems.Among them,the mid-dleware is the most important systemto set up. This platform will handlemuch of the technical burden thatresults from using these services.Fromenterprise application integration (gen-eral purpose middleware) to an enter-prise services bus (Web services dedi-cated middleware),many applicationsmight support the network protocolsand standards required for executingWeb services.

Here,we provide concrete solutionsbased on current technical trends.Wetherefore describe only the last twosteps of our approach, as steps 1 and2 are about methodology and busi-ness modeling (Oasis SOA ReferenceModel Tech.Comm.,Reference Modelfor Service Oriented Architecture 1.0.Committee Specification, 2005; http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.). Inthe next sections, we consider a com-pany that has deployed internally sev-eral enterprise services.Our next goalis to allow business partners to con-sume Web services.

Granting external consumers to access internal services

In Figure 1b, we propose a light reference architecturefor exposing Web services on a public network.This archi-tecture relies on well-known network standards (HTTPSwith certificates) and requires few additional systems. Inmany information systems, only the reverse proxy and thepolicy server will need to be added to the existing land-scape. Moreover, these two systems aren’t dedicated toWeb services and might be used for other purposes. Thereverse proxy processes incoming requests from a Webserver or a customer server in the same way. The reverseproxy is the only system that the service provider exposeson the Internet. It relies on a policy server and a

Lightweight Directory Access Protocol (LDAP) server todetermine the validity of incoming requests. Afterward,the reverse proxy transfers valid requests to the middle-ware platform and then to the back-end systems.Concerning network protocols, a Web service consumermust communicate with the reverse proxy using HTTPSthat includes a strong authentication scheme. Internally,our architecture relies also on HTTPS for communicationbetween business systems.

Fulfilling the security requirements At this point, the company already has internal Web

services.The challenge is to expose these Web services to

Web service provider

Web service consumer

Legend

Step

Subtask of a step

Partner scope

Has for next step

Actors

4. Design a client application

3. Expose the services to external partners

2. Implement corresponding services

1. Identify required business functionalities

Business userBack-end

expert

Middleware administrator Integration developer

Softwaredevelopers

Web developers

Networkadministrators

Middlewarereconfiguration

Deploymentand activation

of services

Definition of access

control lists

Acceptance of incoming

requests

Generation of client proxies

Integration of services in a Web

application

Development of services

Determination of used

components

Involved systems identification

Business needs formalization

(a)

Figure 1. (a) Our Web services methodology and

Page 3: Service-Oriented Computing: Bringing Business Systems to the Web

May ❘ June 2007 IT Pro 21

external consumers without compromising the businessdata the services exchange and the whole internal net-work (applications, systems, and data).We must considereach new entry point from the outside as a potential secu-rity hole.

With our reference architecture, we sought to protectinformation systems from common threats.Our first meas-ure is to set up a demilitarized zone (DMZ) to safeguardthe private network. In our approach, we deported only areverse proxy to the DMZ. Exposing a bigger system likethe middleware platform would have been more danger-ous: if the system is damaged or compromised, it will takemore time to recover.

Then, data are protected whilebeing transferred over the Inter-net by a secured tunnel (HTTPS)created between the service con-sumer and the reverse proxy.Thisprotocol is easy to implement andany business partner can use it.Although this protocol isn’tunbreakable, it should be difficultfor a third party to read or modifythe exchanged data.

Finally, the Web service con-sumer is authenticated while thereverse proxy processes its re-quest. It’s essential to avoid prop-agating invalid messages deeperin the information system.Therefore, our approach requiresa strong authentication based onX.509 certificates for all con-sumers. The policy server shouldauthorize valid requests thatmatch both the consumer profile(contained in an LDAP directory)and the requested resource withdefined policies.

An expendable architecture

Depending on available re-sources,our reference architecturecan be enhanced by DMZ man-agement,consideration of existingWeb service standards, and qual-ity-of-service (QoS) issues.

DMZ management. Maintain-ing a DMZ and its hosted sys-tems is a difficult task. Somecompanies delegate the adminis-tration of this zone to a thirdparty. In this case, DMZ admin-istrators in charge of the reverse

proxy are not the ones with the business knowledgerequired to define access control lists and routing mech-anisms. Therefore, this third party could maintain thereverse proxy and policy server. However, because thecompany needs to keep control over access management,it must continue to manage the LDAP server and cer-tificates administration.

Web service specificities. Our reference architecturecould be improved by considering more closely the exist-ing standards created for Web service technology. So far,we have mainly provided system- and network-based rec-ommendations.With Web services, much information canbe placed at the message level. Therefore, instead of

Web service provider

Web service consumer

Back-end systems (1)

Middleware application (2)

Web server (4)

LDAP server with X509

certificate (3)

Customer server (4)

Internet

Legend

Functionaldata flow

Technicaldata flow

Partner scope

Server

HTTPS with strongauthentication

based on X509 certificate

Firewall

System Xsupports step i

SOAP or RESTover HTTPS

X(i)

Reverse proxy (3)

Dem

ilitarizedzo

nes

Web browser

Navigation

JSONover HTTPS

SOAP or RESTover HTTPS

Flow initiatorXxxx

Network zone Network zonof a companyof a compan

Intern

al netw

ork

(b)

End user

Policy server (3)

(b) the corresponding technical architecture.

Page 4: Service-Oriented Computing: Bringing Business Systems to the Web

22 IT Pro May ❘ June 2007

using HTTPS internally, we could use XML encryption toprotect sensitive data with a thin granularity. Moreover,the reverse proxy could use Security Assertion MarkupLanguage (SAML) to insert a security token in the message (Oasis SOA Reference Model Tech. Comm.,Reference Model for Service Oriented Architecture 1.0,2005; http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm).Afterward, to validate an incom-ing message, an internal system just needs to validate theassociated security token. However, such modificationsrequire applications that can interpret and use these stan-dards.As an example, some enhanced reverse proxies mayprovide a wider range of functionalities dedicated to Webservice issues (“Real-World Solutions for Securing WebServices,” white paper, Vordel, 2005; http://www.vordel.com/downloads/sdaolnwod/vordel_tech_white_paper.pdf).

QoS issues. Providing a service to business partnersisn’t just a matter of offering a functionality. Non-functional properties, or QoS issues, are also critical inthe relationship between the provider and its consumers.For instance, providing security to services doesn’t changethe content of exchanged messages even though it seemsobvious to both parties. Therefore, while implementingWeb services, a service provider should take care of nonfunctional parameters such as availability, precision,reputation, conformance, execution time, and so on (Y. Le Blevec et al.,“Exposing Web Services to BusinessPartners: Security and Quality of Service Issue,” Proc.IEEE Int’l Conf. Digital Information Management[ICDIM 2006], 2006; http://liris.cnrs.fr/publis/?id=2457).Moreover, once QoS parameters are available, it becomesquite easy to establish contracts, called service level agree-ments, on expected and guaranteed QoS metrics. QoS andcontracts may be implemented according to the WebServices Agreement Specification (Web Services Agree-ment Specification, Grid Resource Allocation AgreementProtocol Working Group, 2005; http://www.gridforum.org/Public_Comment_Docs/Documents/Oct-2005/WS-AgreementSpecification Draft 050920.pdf).

Once a Web service is securely and reliably exposed on theInternet, future consumers must build a client application.

CONSUMING BUSINESS SERVICES IN COMPOSITE WEB APPLICATIONS

Composite Web applications consume external services.However, to provide a satisfying user experience, theyshould rely on emerging Web technologies and new Webservice consumption models.

Simple consumption modelWeb applications can consume simple Web services: a

user asks for some data that are connected to back-endsystems, then the Web server invokes the correspondingWeb service, and finally, the service response sends theupdated content to the user.

The main issue in this scenario is to define the commu-nication channel between the Web server and the serviceprovider. If the network protocol is easy to determine,choosing the appropriate specification to encode messagesin the HTTP content might be difficult. Two major speci-fications exist in this field:Representational State Transfer,or REST (R.T. Fielding, “Architectural Styles and theDesign of Network-based Software Architectures,” doc-toral dissertation, Dept. Information and ComputerSciences, Univ. of Calif., Irvine, 2000; http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm), which is popu-lar among Web developers, and SOAP, well implementedin the SOA world. While REST might be easier to dealwith because of its tight coupling with HTTP, SOAP pro-vides useful features (through the Web services standards).Ideally, the Web service provider should support both spec-ifications. Moreover, involved parties must also pay atten-tion to interoperability issues, especially encoding errorsthat the different behavior of languages cause.

How users navigate a Web site differs from the tradi-tional consumption of a Web service.When users performan action, such as browsing a page or clicking a button,they expect a result in no more than a few seconds. In oursimple case, the Web service returns a response in mil-liseconds. This constraint is convenient because the Webserver can immediately create the associated page.Unfortunately, the execution time of some services can belonger. Some Web services don’t even send any response.As a result, delivering content asynchronously to the userrequires deploying new Web technologies.

Interactive Web applicationsRecently, Web developers have focused on enhancing

the user experience on their Web sites through imple-menting features such as the WebOS, personalized home-pages, and webmails. All of this has resulted from theemergence of asynchronous calls from the browser to theWeb server that lets Web developers provide more inter-active pages.

With client-side scripting (such as JavaScript and Flash)and XmlHTTPRequests, data can be retrieved asynchro-nously by the browser from the Web server without reload-ing the current page or asking for a new one throughAsynchronous JavaScript Technology and XML,or AJAX.Many development components support this technology:libraries (such as Dojo), tools (such as ATF for eclipse),and frameworks for languages (such as Ruby on Rails,Cake PHP, and Django for Python). Unfortunately, in anevent-based scenario,AJAX isn’t satisfying because it pullstoo many requests from clients. With Comet, events canbe sent to the browser without previously requesting them.The drawback is that the Web server must maintain anadditional opened connection with all the connectedclients that will be only used for event triggering. Finally,JavaScript Object Notation provides a simple way to

W E B 2 . 0

Page 5: Service-Oriented Computing: Bringing Business Systems to the Web

May ❘ June 2007 IT Pro 23

(de)serialize structures and objects. Compared to XMLmessages, JSON saves bandwidth and is quicker to process.

With these new technologies, developers can adapt Webapplications to better fit Web service consumption models.

Synchronous versus asynchronous consumption

In a Web application, users need to be notified of the sta-tus and result of their requests. As an example, if a Webinterface handles transmitting a sales order, the user mustknow if the back-end system has processed his or herrequest and what the final result is (order accepted ordeclined). Depending on the Web service’s response type,the Web server might use one of the four consumptionmodels presented in Figure 2 to send back such informa-tion to the end user.

To design a Web application based on Web services, thefirst key question to answer is does the Web server wait forthe result of an invoked Web service (synchronous) or doesthe Web service send this result later (asynchronous)?Unfortunately for Web developers, the fewer synchronous

calls to Web services that exist, the safer it is from a businesspoint of view.In our sales order example, if a technical erroroccurs (such as system unavailability) on the server side,a synchronous call will reply that the sales order couldn’t be processed through the SOAP Fault message. No recov-ery mechanism can be implemented.The user has no otherchoice than to try the same operation again later, as Figure 2a illustrates. In an asynchronous scenario,once thesales order is sent to the Web service, it will be processed assoon as the involved systems are ready. Therefore, a goodpractice is to use synchronous calls for accessing back-enddata and to use asynchronous communication as soon asback-end data are modified (through create, update, ordelete actions).You can implement asynchronous calls withthe “Reply to” tag of WS-Addressing (Web ServicesAddressing [WS-Addressing],World Wide Web Consortuim[W3C] member submission, 10 Aug. 2004; http://www.w3.org/Submission/ws-addressing/). During the serviceinvocation, the requester provides a response URL. Oncethe service has finished its task, the service provider sendsthe result back to the response URL.

: EndUser

: EndUser : EndUser

: EndUser

: Browser WebServer : WSConsumer : WSProvider : Browser : Persistency WebServer : WSConsumer : WSProvider

: Browser WebServer : WSConsumer : WSProvider : Browser WebServer : WSConsumer : WSProvider

: navigate(): requestURL()

: invokeServiceA()

: navigate()

: navigate()

: notify()

: navigate()

: notift()

: requestURL()

: requestURL(): requestURL()

: bindConnection_C()

: notifyEvent()

: invokeServiceB()

: invokeServiceB(): invokeServiceB()

: returnResponse()

: returnResponse()

: returnResponse()

: retrieveInvokeResult_A()

: retrieveInvokeResult_A()

: retrieveInvokeResult_A()

: storeEntry()

: checkNewEntries()

(a)

(b)

(d)

(c)

Figure 2. Several models of consumption of Web services from a Web application.

Page 6: Service-Oriented Computing: Bringing Business Systems to the Web

24 IT Pro May ❘ June 2007

We designed three asynchronous models based on per-sistency, AJAX, and Comet, respectively. The first one(Figure 2b) relies on a persistent layer—that is, the Webserver sends the invocation result to another system thatthe user can access later.A persistent layer might be imple-mented with emails where results are sent to the user’semail inbox. Another possibility is to create a news feed(such as RSS or Atom) that the user or a group of people(with permission) can access.The two other consumptionmodels (Figures 2c and 2d) use asynchronous communi-cation between the browser and the Web server.Therefore,the same Web interface notifies the user asynchronouslywith invocation results. Note, you can use JSON to encodeasynchronous messages to improve this architecture’soverall performance.

Design issuesWithout providing details about implementation issues

that are too closely related to the chosen technologies, webriefly present here the key design orientations for Webdevelopers when deploying the previously described con-sumption models.

First, concerning the design of the software architecture,all tiers (data sources,business logic,and presentation logic)must be clearly separated so as to obtain a maintainablesource code. Moreover, the use of the Model ViewController (MVC) design pattern highly simplifies serviceconsumption: Web service invocations are wrapped intomodels,user inputs in controllers,and user outputs in views.Finally,one last issue is the portability of a Web applicationamong Web browsers, especially for user interface render-ing and for JavaScript execution. To improve an applica-tion’s behavior, Web developers should rely on dedicatedlibraries that provide robust and portable functionalities.

Second, composite Web applications provide more thanjust the direct consumption of a single service. In compos-ite Web applications, m user inputs might be associated toperform n service invocations to return o user outputs.Therefore, the business logic of composite Web applica-tions should provide business process management func-tionalities so as to support such choreography. However,even though the business logic is more complex than theone exposed in Figure 2, we can enrich the consumptionmodels for composite applications with more inputs, invo-cations, and outputs.

Finally, concerning security,Web developers need to becautious not to compromise the security of their Web appli-cations and create a weak point in the overall architecture.Security in such Web applications is basically the same asin other Web applications that don’t use Web services:Webdevelopers should be worried about data protection, phis-ing risks, and JavaScript manipulations. Therefore, in ourprototype architecture, we have clearly differentiated theservice layer with its authentication mechanism (LDAP)

from the Web application layer with its own security meas-ures (login and password).As an example,Web users don’tauthenticate through the LDAP mechanism and they are never considered as the service requesters. The enduser ID is simply mentioned in the SOAP message.Consequently, the Web server authenticates the Web usersas in all Web applications.

FUTURE WORKGlobally,exposing data and systems to the outside world

is quite challenging. Even though it seems straightforwardfrom a technical perspective, security issues make this workcomplex. Therefore, involved actors should always beaware of all incurred threats: from denial of service to datamanipulation by third parties.

Alcatel Vacuum Technology France has deployed a pro-totype architecture according to our recommendations. Inthis prototype, a third party is in charge of the DMZ andadministrates the reverse proxy and policy server.We can’tprovide more details about the DMZ in this article for con-fidentiality reasons. However, the company already main-tains in its private network an LDAP server (openLDAP),a back-end system (SAP R/3), and a middleware solution(SAP Exchange Infrastructure). Externally, the companyhas installed on a certified hosting provider a Web server(Tomcat) that uses AJAX and JSON. SOAP handles com-munications between the Web server and the middleware.

I n the future, we hope to integrate into our referencearchitecture better support of QoS provisioning andcontract binding. A precise monitoring of QoS met-

rics would bring transparency to the system and allowautomation in resource management. Another goal is tosecure the access to the Web server through a strongauthentication mechanism that relies on other communi-cation channels (such as a security token sent by SMS anda hidden URL given by emails). ■

Yann Le Blevec is a PhD student in computer science atLIRIS, France, and a researcher at Alcatel Vacuum Tech-nology France. Contact him at [email protected].

Chirine Ghedira is an associate professor at ClaudeBernard University and member of the LIRIS-CNRSresearch laboratory. Contact her at [email protected].

Djamal Benslimane is a full professor at Claude BernardUniversity and member of the LIRIS-CNRS research lab-oratory. Contact him at [email protected].

Xavier Delatte is CIO of Alcatel Vacuum TechnologyFrance. Contact him at [email protected].

W E B 2 . 0