XML Web Services - Telenor Group · XML Web Services 1 Guest Editorial; Do Van Thanh 3 What is an XML Web Service?;Erik Vanem, Do Van Thanh 16 Distributed Processing Platforms: Tansparencies;

XML Web Services

1 Guest Editorial; Do Van Thanh

3 What is an XML Web Service?; Erik Vanem, Do Van Thanh

16 Distributed Processing Platforms: Tansparencies; Jan A. Audestad

27 Web Services – An Evolution of the Distributed Computing Model; Tron Syversen

30 Web Service Development Explained;Anne Marie Hartvigsen, Luis Arturo Flores, Do Van Thanh

37 Major Web Service Products and Relations to Mobile Telco Services; Erik Lillevold, Do Van Thanh

47 Security in Web Services; Erik Parr, Erik Berg, Sune Jakobsson

58 Evolving Service Creation; New Developments in Network Intelligence;John-Luc Bakker, David Tweedie, Musa R. Unmehopa

69 Real World XML Web Service Scenarios for Telcos;Erik Vanem, George Bilchev, Edward Buckley, Thomas Hoppe

80 XML in Electronic Commerce and Electronic Business;Svein Tore Johnsen, Bernard Quarre

97 Electronic Gateways – Forging the Links in Communications Services ValueChains; Derrick Evans, Dave Milham, Elayne O’Sullivan, Martin Roberts

105 Next Generation Infrastructure for Electronic Collaboration; Øyvind Aassve

110 The Self-Service Channel – “Dine Sider”; Robert Landsem

114 Web Services in Action: The User Profile Web Service;Anne Marie Hartvigsen, Do Van Thanh

Contents

Telektronikk

Volume 98 No. 4 – 2002

ISSN 0085-7130

Editor:

Ola Espvik

Tel: (+47) 913 14 507

email: [email protected]

Status section editor:

Per Hjalmar Lehne

Tel: (+47) 916 94 909


Editorial assistant:

Gunhild Luke

Tel: (+47) 415 14 125


Editorial office:

Telenor Communication AS

Telenor R&D

NO-1331 Fornebu

Norway

Tel: (+47) 67 89 00 00


Editorial board:

Berit Svendsen, CTO Telenor

Ole P. Håkonsen, Professor

Oddvar Hesjedal, Director

Bjørn Løken, Director

Graphic design:

Design Consult AS, Oslo

Layout and illustrations:

Gunhild Luke and Britt Kjus,

Telenor R&D

Prepress and printing:

Optimal as, Oslo

Circulation:

3,750

1

When people say that they go on the netthey usually mean the World Wide Web.For most people the Internet is usually asso-ciated with the World Wide Web, which isonly one of the applications of the Internet,although a really popular one. Just beforethe current depression it was quite easy toget a job with decent salary with only afair knowledge of HTML, the HyperTextMarkup Language of the World Wide Web.Everything related to the World Wide Webbecame hype. The most recent phenomenonis the XML Web service. All the vendorsand analysts are talking about them. XMLWeb Services are becoming the next “new”and big thing in the Internet. It is consid-ered as a new vision for distributed com-puting on the web offering an XML-basedaccess via transparent Internet protocols(HTTP), relieving distributed computationsfrom the need to be based on specializedmiddleware platforms, thus enabling theuse of services over company borders, fire-walls, different suppliers, infrastructuresand technologies.

Nevertheless, most ironically, nobodyseems to agree about the definition. So,what is an XML Web service? Does itrequire any particular transport like HTTPor SMTP? If so, can you use others, likeMSMQ? Does it mandate the use of XMLand SOAP or can other content types suchas MIME, JPG, MP3, or URL-encoded datain a query string be used as well? However,the most basic questions are: What hasXML to do with services? Is it just anextended Markup Language? Many ques-tions are left without answer.

Anyway, XML Web Services should havesome potential since big companies likeMicrosoft, IBM, Sun, HP BEA, Oracle,etc. have invested quite a lot of effort andmoney in them. Microsoft is betting andpromoting fiercely the concept of Web Ser-vices. After its shift to supporting the Inter-net a few years ago, Microsoft is preachingWeb Services through its .NET initiative.Bill Gates claimed that “The Power of theXML Web Services model is amazing”.In answer to Microsoft’s .NET, Sun an-

nounced the Sun ONE initiative that in-cludes Web Services support in Sun’s Fortefor Java Tools and in iPlanet’s Web, appli-cation and integration servers. IBM sup-ports Web Services in its Websphere whichconsists of the Websphere applicationServer, the Web Services Developmentenvironment for building and deployingWeb Services.

The XML Web Services concept is alsogaining momentum in the Telecom world.Indeed, telecom operators started manyyears ago to look for a safe and efficientway of exposing and offering their networkcapabilities to third parties through stan-dardisation activities in Parlay/OSA. TheXML Web Services concept could be theideal solution since it does not let itselfstopped by firewalls or software incompati-bility problems as distributed computingmiddleware like Corba. Projects aiming atinvestigating the feasibility of the XMLWeb Services concept and establishingtestbeds for Web Services have been ini-tiated by both the EU Commission andEURESCOM, the European Institute forResearch and Strategic Studies in Telecom-munications. In fact, some of the articles inthis Telektronikk issue result from their pro-jects. At Telenor, a workshop “XML WebServices: the Services of the Future” organ-ised in June this year attended by Web Ser-vices experts from both academia andindustry has gained a lot of attention andparticipation.

The main goal of this Telektronikk issue isto present a clear overview about XMLWeb Services, what they are, how to buildand use them, what their benefits are, etc. Itis also aiming to create an opportunity forworldwide experts to express their opinionsand experiences about XML Web Services.The issue has some articles that cover thefundamentals of XML Web Services andcan serve as an introduction to the concept.Other articles are aiming to provide a gen-eral understanding of Distributing Comput-ing and explaining XML Web Services inthe context of Distributed Computing. Themajor Web Service products and vendors

Guest EditorialD O V A N T H A N H

Do Van Thanh

Front cover:XML Web Services

The artist Odd Andersen seesvarious providers of XML WebServices as distinct parts ofglobal market areas actingwithin the physical bound-aries of bandwidth and net-work. Today they offer partic-ular solutions – later they mayco-operate or merge theirprovision into a commonsolution – here visualised byextending particular globalareas into each other. The in-and outgoing lines – alsocrisscrossing within the web –indicate the user’s access toservice components neededto fulfil his/her demand.

Ola Espvik, Editor in Chief

Telektronikk 4.2002

2 Telektronikk 4.2002

are also summarized in an article, such thata reader wishing to build Web Services canget started easily.

No matter how wonderful is the XML WebServices concept, it can never be a successwithout security, which is also covered inan article. How XML Web Services fit inthe evolution of the telecom service cre-ation is also explained. The businessaspects of XML Web Services surely playa decisive role in their success.

The XML Web service scenarios for telcosare treated thoroughly. There are also arti-cles that consider Electronic Commerce,

Electronic Business and Electronic Gate-ways. This Telektronikk issue concludeswith three applications of the Web Serviceconcept, namely an infrastructure for elec-tronic collaboration, a self-service channeland a user profile Web Service. Finally, Ihope that the reader will find this issue bothpleasant and useful.

Enjoy your reading!

3

1 IntroductionMost people today are well familiar with theWorld Wide Web. As the name indicates it isa global web of servers (web servers) that areinterconnected and that offer each other accessto their files. In this way people may easily andrapidly exchange information from anywhere inthe world. Traditionally, the WWW has mainlycontained static information or content intendedfor the human user and presented to him througha web browser. The information accessible onthe web servers has typically been contained inHTML documents that dictate how the actualpresentation of the data will be and that containlinks to other documents contained on other webservers. Lately however, the WWW have be-come more dynamic with frequent informationupdates and relocations. The WWW concept isalso extended to contain not only content butalso functionality; i.e. one can not only accessinformation available on the WWW but also getcertain functions performed. These functions canbe spread out through the whole web, and beaccessed by other applications with Internetaccess. To put it simple, the web is evolvingfrom being basically static content available tohuman users to include also functionality orapplication components available to other appli-cations.

Different solutions for distributed computing,allowing applications to communicate with otherapplications across computer boundaries, havebeen around for a while already. However, theyall have a lot of shortcomings that limit theirrange of use. Object frameworks such as COMand CORBA coupled with wire protocols (IIOP,DCOM and RMI) were introduced to allowapplications to talk to each other over a network.However, these solutions were not interoperableand even though there have been some efforts inthe industry to amend this, they have not beenwidely successful. Being non-interoperable asthese solutions are, it basically means that bothsides of the communication link need to use thesame distributed object model. This works fine

in most cases where both sides belong to thesame LAN and are controlled by the sameorganisation that can decide which systems touse. However, with the emergence of the Inter-net, the distributed networks became very largeand very decentralized and it is generally nolonger possible for anyone to control both endsof the communication link. This makes applica-tion-to-application communication and dis-tributed computing over the Internet quite chal-lenging with these protocols. Another difficultissue is firewalls. When communicating over theInternet, across company borders, one needs topass through firewalls that generally do not havemany open ports. Very often, the widely usedports for HTTP and SMTP are the only ones thatare open.

So XML Web Services has emerged to remedythis situation and allow applications to commu-nicate with other applications in a well-definedway. The various applications may reside ondifferent machines anywhere on the Internet orwithin the same intranet and the communicationshould be able to traverse both company borders(firewalls) and technological borders (when thetwo applications are implemented on differentplatforms, with different language, etc.). Oneshould keep in mind, however, that the XMLWeb Services proposal is not merely a substituteto replace the existing solutions for distributedcomputing. It rather supplements them with theexposition of services on the Web. A likely WebServices scenario will be made up of two levels.The first level is an internal system that imple-ments the applications based on traditional plat-forms and communicating internally with tradi-tional distributed computing technologies orsome proprietary solutions. These applicationscan then be exposed externally using XML WebServices so that others are able to utilize them.

2 What is XML?XML is one of the cornerstones of XML WebServices and the specifications associated withXML Web Services are all based on XML. In

What is an XML Web Service?E R I K V A N E M A N D D O V A N T H A N H

XML Web Services are considered by many as the services of the future, but what exactly are Web

Services? Is it simply services delivered via the World Wide Web? And what about XML, is it just a new

and improved version of HTML and what does it have to do with services? This article will try to give a

basic overview of XML Web Services and describe its most important features in a simple and compre-

hensible way. Before studying the concept of Web Services, the article introduces XML and describes

how XML documents are created and parsed. It then proceeds with Web Services and how they are

used. Finally before the conclusion, some more details about the standards associated with XML Web

Services are given.

Do Van Thanh (44) obtained hisMSc in Electronic and ComputerSciences from the NorwegianUniv. of Science and Technology(NTNU) in 1984 and his PhD inInformatics from the University ofOslo in 1997. In 1991 he joinedEricsson R&D Department in Osloafter 7 years of R&D at NorskData, a minicomputer manufac-turer in Oslo. In 2000 he joinedTelenor R&D and is now in chargeof PANDA (Personal Area Net-work & Data Applications) re-search activities with a focus onSIP, XML and next generationmobile applications. He alsoholds a professor position at theDepartment of Telematics atNTNU in Trondheim. He isauthor of numerous publicationsand inventer of a dozen patents.

[email protected]

Erik Vanem (30) received hisMSc in Physics from the Univer-sity of Oslo in 1996. Before join-ing Telenor R&D in 2000 heworked as a geophysicist atPGS Reservoir, as a researchassistant at the NorwegianDefense Research Establish-ment and as a physics teacherat the Oslo University College.Since 2000 he has worked withuser centric services, mobileapplications and services, Voiceover IP and mobility manage-ment in next generation wirelessnetworks. Recently he has beenworking with distributed com-puting and XML Web Servicesin the PANDA group (PersonalArea Networks and Data Appli-cations) at Telenor R&D.

[email protected]

Telektronikk 4.2002


this section the main features of XML will beoutlined and it will be indicated why XML isa well-suited tool for Web Services. The W3CXML recommendations are available at [1].

What is XML? Since XML can be used in avariety of different areas of data computationand communication, different opinions exist ofwhat XML is. So to keep things clear and avoidconfusion, let us first say a few things aboutwhat XML is not.

• XML is not a programming language;• XML is not a database;• XML is not the next generation of HTML;• XML is not specific to any horizontal or

vertical market segment.

XML stands for eXtensible Markup Languageand is a specialisation of SGML (Standard Gen-eralized Markup Language), which has been anISO standard since 1986. It is a clearly defined,system-independent way of representing data.With XML, all conceivable kinds of data can bestructured, described and interchanged. An XMLdocument is in text format and this makes itreadable to both machines and human beings.Human being, of course, should not have to readthe XML files, but it can be useful when thereis a need. Finally, XML is non-proprietary andlicence free so that anyone can build their ownsoftware around it without paying anything toanybody.

Figure 1 Web Services as thenext step in the evolution ofdistributed computing

Heterogencous systems running application components and communicatingwith Web Services thorugh the WWW and trough firewalls

WORLD WIDE WEB

Terminals

Mainframerunningapplications

Standalone PCs running applications

LAN

PCs running applications andcommunicationg with specificmeddleware through a LAN

Terminals

ORB

5Telektronikk 4.2002

The data in an XML file is enclosed in tags,much like HTML files. In the HTML specifica-tions, however, it is specified what each tag andattribute mean, and one is limited to using onlythose tags that are predefined. XML on the otherhand is extensible, meaning that everyone isallowed to write their own tags that describe thecontent. Another difference from HTML is thatthe tags in XML relate to the actual meaning ofthe enclosed textm whereas in HTML the tagsmost often define how the data will be presentedby a browser. Since XML documents containcustom-made tags and attributes that may bespecifically defined by the author of the docu-ment, there must be a way for others to knowtheir meaning and thereby know how to interpretthe enclosed text. This is done with an XMLschema language, e.g. Document Type Defini-tion schema language or XML Schemas 1 or 2,that define the tags in an XML document. Asimple XML example is given in Figure 2 whichshows what an XML file might look like, andwith an example DTD file that defines the tagsused in the XML document.

The example shows an XML file containing apricelist for cars. First in every XML documentis the XML prolog. As a minimum, every XMLdocument must always contain prolog with adeclaration that identifies the document as anXML document. This is the first line in theexample document in Figure 2. In addition,optional information can be contained in the pro-log. For example, specifications of which tagsare valid in the document can be declared in aDTD directly within the prolog, or a pointer tosome external specification file can be placed inthe prolog.

Following the XML prolog is the document’sactual content or data, sometimes referred to asthe Root Element. The root element is the high-est-level element and this can again contain

other elements in a hierarchical structure that isdefined in the DTD. In the XML file this meansthat all other tags will appear between the<rootElement> and </rootElement> tags. Theexample file has <priceList> as its root element,and according to the DTD, this element containsone or more (indicated by the plus sign) <car>elements. Every <car> elements must in turncontain one <name> element and one <price>element in that order. The <name> and <price>elements are again the actual data to be parsed oranalysed by the XML parser – PCDATA. In thissimple example, DTD is used to illustrate how todefine the tags or elements. A significantly morepowerful, but also more complex language fordoing this is XML Schema. For more details onXML Schemas, see [2].

With XML, the data is separated from the for-matting instructions. To specify how documentsare presented on a screen, in print, or how theyare pronounced separate stylesheets are used.XSL is a language for expressing such style-sheets and consists of three parts; XSLT fortransforming XML documents (e.g. XML datainto an HTML/CSS document), Xpath to accessor refer to parts of an XML document, and XSL-FO an XML vocabulary for specifying format-ting semantics. For more details on XSL, see [3].

2.1 XML Data for MultipleApplications

XML documents can contain data that are meantfor different applications that will need the datafor different purposes. An important aspect ofXML is that it is self-describing and that differ-ent parts of the data are identified. In the exam-ple above the parts of the data that contains thename of the cars are easily distinguished fromthe price. In this way the different parts of thedata can be used in different ways by differentapplications. The applications have to agree onthe tag names, of course, but if they have the

Figure 2 A simple XMLexample

DTD(Document Type Definition)

<!ELEMENT priceList (car) +><!ELEMENT car (name, price) ><!ELEMENT name (#PCDATA) ><!ELEMENT price (#PCDATA) >

XML

<?xml version=”1.0”?>

<priceList><car>

<name>Ford</name><price>150 000</price>

</car><car>

<name>Nissan</name><price>145 000</price>

</car><car>

<name>Opel</name><price>140 000</price>

</car></priceList>


right DTD (or XML Schemas), they can processthe documents according to specified rules.

An XML document can also contain processinginstructions of the following format:

<?target instructions?>

These processing instructions give informationto an application that processes the XML data,where target is the name of the application andinstructions contain the information. Becausethe instructions are application specific, XMLfiles can have multiple processing instructionsthat tell different applications to do similarthings in different ways.

XML is modular, meaning that one is allowed todefine a new document format by combiningand using other formats. When doing this, how-ever, there is a possibility that the two formatshave elements or attributes with the same name.For example if combining the XML exampleabove with a format describing customers ordrivers, it is likely that these will also contain a<name> element. To avoid mixing two differentelements with the same name but differentmeaning, XML provides a namespace mecha-nism that is used to identify the different ele-ments in a document. XML namespaces use pre-fixes to the elements to achieve this and in theabove example, one can use the namespaces carand customer to distinguish between the differ-ent <name> elements. The qualifying namewould then contain a namespace-prefix followedby a colon and the local name: <car:name> and<customer:name>. However, one must makesure that the prefixes one uses are globallyunique and not used by anybody else; i.e. thattwo different namespaces never have the samename. This is obtained by using URIs as names-pace names. These URIs could be controlled byan organisation so that others do not use them.In the above example, the following namescould be globally unique:<http://www.cardealer.com/car:name> and<http://www.cardealer.com/customer:name>.There will then be one XML schema bound toeach specific namespace that defines all ele-ments and attributes belonging to that name-space. For more about XML namespaces, see [4].

With a basic understanding of XML and how itcan be used by multiple applications in differentways, it is about time to proceed and considerthe Web Service concept. More interesting liter-ature can be found at [5, 6].

3 What is a Web Service?What then, is a Web Service? Several definitionsof Web Services exist, and the following are justsome examples:

• Web Services are self-contained, modularapplications that can be described, published,located, and invoked over a network, gener-ally, the Web – IBM [7].

• A Web Service is a unit of application logicproviding data and services to other applica-tions – Microsoft [8].

• A Web service is a software application iden-tified by a URI, whose interfaces and bindingare capable of being defined, described anddiscovered by XML artifacts and supportsdirect interactions with other software appli-cations using XML based messages via inter-net-based protocols – W3C Web ServicesArchitecture Working Group [9].

• Web Services are modular, self-describingapplications that can be published, locatedand invoked from just anywhere on the Web ora local network [10].

• Web Services are loosely coupled, reusablesoftware components that semantically en-capsulate discrete functionality and are dis-tributed and programmatically accessibleover standard Internet protocols – The StencilGroup [11].

Others may offer alternative definitions of WebServices and although the various definitions arenot identical, they all share the same generalview of what Web Services are.

Web services can be said to describe any compu-tational functionality that can be found andinvoked over any network in a component basedmodel. These functionalities are reusable soft-ware components that allow other developersthan the ones that have created them, to reusethem as building blocks of code and to assemblethem and extend them in new ways. In this wayWeb Services continue the rising of object-ori-ented design in software development, anddevelopers do not need to write a complete setof instructions from start to finish.

A Web Service represents self-describing andself-contained application meaning that it encap-sulates discrete functionality that performs a sin-gle task. It describes its own inputs and outputsin such a way that other software can determinewhat it does, how to invoke it and what to expectas a result in return. Web Services are designedto be used by other programs rather thanhumans, so they do not have a graphical userinterface. However, even though they are notdesigned for direct human interaction, theymight be incorporated into software designed forhuman interaction. For example, a Web Service


can be accessed by an application that generatesan HTML page to be displayed in a browser.

The different Web Services software compo-nents are loosely coupled and do not dependupon a tight interconnection. The Web Servicesdevelopers thus do not need to have full controlover both ends of the connection and a muchsimpler level of coordination is required thanwith traditional design. The fact that the compo-nents are loosely coupled also means that moreflexible reconfiguration is allowed. Finally, WebServices are distributed and can be accessed viatransparent widely adopted Internet protocolslike HTTP, SMTP, FTP, etc. By using these pro-tocols, the same as traditional web content, WebServices can communicate through most fire-walls, and can thus be used across companyborders.

Once a Web Service is deployed, it can be foundand accessed by other applications and otherWeb Services. A Web Service can be mixedand matched with other Web Services in a valuechain allowing construction of more complexservices out of multiple simple Web Services.This is illustrated in Figure 3.

The actual service logic of the different WebServices in Figure 3 can be implemented on dif-ferent platforms and with different programminglanguages. They can also belong to differentorganisations or domains as the invocations andresults are communicated via e.g. HTTP that cantraverse firewalls.

3.1 XML Web ServicesWeb Services as described above should be uni-versally accessible programmatically, regardlessof what platform the Web Service runs on orwhat programming language it uses internally.This means that any application that is madeto interact with a certain type of Web Servicesshould be able to exploit any of those Web Ser-vice that is exposed on the Internet without anyneed for extra programming or adjustments. Inorder to achieve this, standard protocols for WebServices are important. XML has been mostimportant as a way to standardise data formatsand exchanging data and most of the standardprotocols for Web Services use XML as its foun-dation. Having seen various definitions of WebServices, the following can be used as a defini-tion of XML Web Services:

XML Web Services are Web Services that useXML as a means of standardising data for-mats and exchanging data.

3.2 Three Distinct Roles in a WebServices Scenario

In an XML Web Services scenario, three distinctroles that interact with each other can be identi-fied. These roles are the service provider, theservice requestor and the service broker. Figure4 illustrates these roles and their interactions.

The service provider creates the service andmakes it accessible for clients over the Internet.The service can be created in any language onany platform as long as it supports the publishand bind interactions. A Web Service providerdiffers from an application service provider(ASP) in that the offered Web Services are dis-tributed components. The ASP on the other handdelivers entire applications from a central host-ing location, which are generally not extensible.

A service requestor is the client that uses theWeb Service. This client can also be written inany language and on any platform as long as it isable to find and bind to a Web Service. A WebService can itself take the role of a servicerequestor when it takes advantage of otherWeb Services as illustrated in Figure 3.

The service broker is the one that brings the ser-vice requestor and the service provider togetherby providing an interface between the publishand find interactions.

The interactions between these roles are the fol-lowing:

Publish: The service broker offers a publishinterface where the service providercan tell the service broker about the

Figure 3 A value chainof Web Services

Figure 4 The three rolesin a Web Services

scenario and their interactions

WebService 1

WebService 2

WebService 3

WebService 4

Invoke

Result

Invoke

Result

Invoke

Result

ServiceProvider

ServiceBroker

ServiceRequestorBind

Publis

h Find


services it provides. The published informationshould include data about the service itself, itsinput and output, and where it can be accessed.In addition, an unpublish interface is offeredthat lets the service provider remove advertise-ments of published services.

Find: In addition, the service broker offers afind interface where the servicerequestor can inquire about a particularWeb Service or a category of Web Ser-vices, where services can be searchedfor by specifying a variety of searchparameters.

Bind: The bind interaction represents theactual invocation of the Web Service.Binding in this context can be com-pared to a function call, where parame-ters are passed to the function and areturn value is received as a result.

Neither the find nor the bind operations needto be performed every time a service requestorwants to invoke a service, however. If the ser-vice requestor has found a suitable service once,the results can be cached and used every time itneeds to bind to this specific service. Only incases where the bind operation fails, for exam-ple when the service has been moved to a differ-ent location or modified, will the servicerequestor need to inquire the service brokeragain and refresh the cached information.

3.3 Main Uses of Web ServicesThe three roles in Web Services scenarios identi-fied above can all exist within the same enter-prise domain or they can belong to differentdomains within the Internet. This results in awide range of different areas where Web Ser-vices can be used. Basically, the main uses ofWeb Services can be divided into three cate-gories:

• Application integration Web Services• Business integration Web Services• Commercial Web Services

Normally, the first type of Web Services anenterprise would implement is application inte-gration Web Services (Web Services will be asuitable technology for Enterprise ApplicationIntegration, EAI). These are Web Services usedinternally within an Intranet to integrate differentbusiness applications that run on different plat-forms. Often, different systems like for exampleUnix and Windows coexist within an enterprise,and Web Services can enable them to communi-cate with each other. Legacy applications canexpose part of their interfaces as Web Servicesto allow integration with other business applica-tions in a heterogeneous environment withoutthe need to rewrite a huge amount of code.

The next step is usually business integrationWeb Services that integrate applications be-tween company borders. A few key partners out-side the company can be chosen and Web Ser-

Figure 5 Businessecosystem that benefits fromdifferent types of Web Services

Customer 2

Company B

Company A

Customer 3

Customer 1

Provider 3

Provider 2 Provider 1


vices are used to ensure interoperability betweenthe partners’ applications across the public Inter-net. Due to the lack of widely adopted specifica-tions, however, the companies must agree uponthe technologies used to develop these interoper-ating Web Services. This category of Web Ser-vices is ideally suited in a B2B context, i.e. forelectronic business administration between abuyer, a seller and possibly a third party.

As the final step, companies might want to ex-tend their services to reach more partners andcustomers in a commercial Web Service. Theycould use Web Services to sell various contentor business services over the Internet to potentialcustomers anywhere on the web in a pay-per-usemanner or through subscriptions. Examples ofsuch services could be location specific weatherforecasts, currency exchange, authentication ser-vices, etc.

These different categories of Web Services cancoexist in a system that connects internal sys-tems together, expose services to a number ofexternal partners and customers as well as utiliz-ing Web Services provided by others in a busi-ness ecosystem as illustrated in Figure 5. In thisfigure, company A and company B both useapplication integration Web Services to integratethe internal applications within their enterprise.They use business integration Web Services tointegrate with each other’s applications as wellas with other business partners’ applications andfinally, they offer commercial Web Services to anumber of different customers.

3.4 Web Services RequirementsA number of basic requirements must be ful-filled if such interoperable, ubiquitous Web Ser-vices as described above are to become a reality.As a minimum, there is a need for widelyadopted specifications that are neutral to bothplatform and programming language for thefollowing:

• Publication of services• Discovery of services• Description of services• Invocation of services

In other words, a commonly agreed mechanismfor publishing services so that others can findthem is required as well as a well-defined way tosearch for services providing certain functions.Without these mechanisms, only a very re-stricted number of clients that are informeddirectly by the service providers will be able usethe services. In addition, the published servicesmust be fully described so that a service request-or can develop a client that knows how to invokeit. Finally, a protocol that allows invocation ofthe service over the Internet must be specified.

To what extent Web Services will be a successdepends on whether these basic requirements,which basically all deal with interoperabilitybetween different implementations, are fulfilledor not. Assuming they can be fulfilled, the basicWeb Services architecture will look like theillustration in Figure 6. In this figure, it shouldnot matter if the Web Service client and the WebService are implemented on different platforms,as long as the communication between them fol-low well specified rules. In the next section, thedifferent standards associated with XML WebServices that address these requirements will bediscussed.

On top of the basic interoperability requirementsthat are needed to make the Web Services archi-tecture work in the first place come other re-quirements such as stability, reliability and effi-ciency, security, scalability, availability, man-ageability, accountability, etc. A thorough dis-cussion of these requirements is consideredbeyond the scope of this article, but it should besufficient to mention that the degree of successand the range of use of Web Services willdepend on how these are met as well.

4 Standards Associated withXML Web Services

In order to meet the four basic requirements dis-cussed in the previous section, major industryactors have joined forces and proposed severalXML based solutions that are now more or lesscommonly agreed upon. Three of these initia-tives, UDDI, WSDL and SOAP will be dis-cussed in more detail in this section.

4.1 Publishing and Discovering WebServices – UDDI

In order for Web Services to work satisfactorily,there is a need for a standard way to publish anddiscover Web Services. The Universal Descrip-tion, Discovery and Integration (UDDI) specifi-cations [12] proposed by UDDI.org define a wayfor businesses to list themselves and their ser-vices on the Internet (or intranet) that is com-monly accepted to be the standard XML Web

Figure 6 Basic Web ServicesarchitectureRegistry

Web Service Web ServiceClient

3. ServiceInvocation

1. Publishservicedescription

2. Discoveryof suitableservecesand how tocommunicate with them


Services way of doing this. All information con-tained in the UDDI registries is formatted inXML.

The UDDI registries provide two groups ofAPIs: Publishing APIs that allow creation anddeletion of entries in the registry, and inquiryAPIs that allow search for entries in the registryby different search criteria. The APIs are in-voked by sending appropriate SOAP messagesto the registries, so each UDDI registry musthave some kind of server process that receivesand responds to SOAP messages. In fact, UDDIitself can be thought of as an XML Web Service.

A UDDI registry contains a number of entrieswith each UDDI entry consisting of three parts:

• The white pages• The yellow pages• The green pages

In analogy with traditional telephone books, thewhite pages describe the company offering theservices. It contains information such as com-

pany name, address, telephone number and othercontact information. The yellow pages includeinformation about the type of business and theindustry categories that the company belongs to;i.e. it shows the services a certain business pro-vides. The green pages contain the informationabout the specific services that are offered. Here,the service should be described in enough detailfor someone to be able to write an applicationthat uses or consumes the Web Service. Figure 7shows an example UDDI entry containing whitepages, yellow pages and green pages.

A UDDI entry is an XML document with rootelement <businessEntity>. This corresponds tothe white pages where the business informationis contained. This root element can contain zeroor more <businessService> elements that corre-spond to the yellow pages and that each repre-sents a family of technical services. The<businessService> thus shows the services a cer-tain business provides. Besides a description ofthe services, each <businessService> contains anumber of <bindingTemplate> elements. Theseelements provide references to technical infor-mation about a service (e.g. a WSDL document),access point for the service, etc.

As already mentioned, two groups of UDDIAPIs exist that allow publishing and searchingfor services. The publishing APIs permit cre-ation and deletion of all kinds of entries. Onecan publish a whole new business entity or addnew service categories or individual services toan existing business. Generally, a userID andpassword would be required to invoke the pub-lishing APIs. The Inquiry APIs provides waysto find services and to get more details aboutservices. They allow searching for all kinds ofentries, in the white, yellow or green pages,based on different search criteria. One cansearch for businesses based on location or name,businesses and services based on industry cate-gories or types of services, or one can search forspecific services.

It is a goal to establish a global network ofUDDI registries resembling the Domain NameSystem (DNS). All these registries shouldexchange and share their information, so thataccessing one registry should provide all infor-mation contained in all registries. Already, thereis a number of UDDI registries, and the numberof registries is expected to grow in the future andform a hierarchical structure. The goal of a net-work of UDDI registries is illustrated in Figure 8.

4.2 Describing Web Services – WSDLAfter a service is found, one needs to know whatthis particular service can do, where it is locatedand how to invoke it or format messages to it.From the service provider’s point of view, there

Figure 7 An UDDI entrycontaining white pages,yellow pages and green pages

Figure 8 The UDDIservice cloud

<businessEntity> - Business informationname, contact, description….

<businessService> - service info

<bindingTemplate>

- technical infoaccess point,referenceto WSDL

ServiceProvider

UDDIRegistry

A

UDDIRegistry

C

UDDIRegistry

B

ServiceRequestor

UDDIRegistry

DUDDI Service Cloud

UDDI Publish UDDI Find


is a need to be able to give information to othersabout what their service can do and how to makea client that can use it. The WSDL specifications[13] specify how this can be done. The specifica-tions were originally developed by IBM andMicrosoft and have now been submitted to W3Cto become a standard.

A WSDL document is an XML based descrip-tion of services to make them programmaticallyaccessible to other applications. It must containenough information for others to be able to writea client program that uses the services it de-scribes. WSDL defines the data types and mes-saging as well as the specific location of the ser-vice. It is in itself independent of underlyingprotocols, but in the real world it mostly usesXML Schemas to define data types and SOAP(over HTTP) for messaging. Simply put, WSDLspecifies the What?, Where? and How? of theservices it describes.

A WSDL document contains two parts: A re-usable part, sometimes referred to as the inter-face part, and a non-reusable part, also called theimplementation part. The reason for this is theassumption that certain services can be standard-ised in the future. The interfaces of these ser-vices can then be described in a generic waywithout specifying its exact location. One canthen deploy the service at multiple locationswithout having to duplicate the interface descrip-tion. An example WSDL document showing allits elements is given in Figure 9.

The root elements of a WSDL document arecalled definitions, and these again contain a<types> element, one or more <message> ele-ments, <portType> elements, <binding> ele-

ments and <service> elements. The non-reusablepart of the document is the part containing the<service> elements.

At the highest level, there is a need to define thedata types used by the described Web Serviceand this is done within the <types> element.Usually, the data types are described as an XMLSchema. In the <message> element, the differentmessages that are sent to and from the serviceare described. Each message can again containzero or more <part> elements that correspondto the parameters of the message. An operationcorresponds to a method call tying the messages(defined in <message>) together in request-response pairs. An <operation> element contains<input> and <output> messages that refer to cor-responding messages. One or more operationsbuild a <portType> element, which basicallyrepresents a set of functions that the Web Ser-vice can process. The following is an example ofwhat this could look like in a part of a WSDLdocument:

<message name=”Request”><part name =”Astring” type=”xsd:string”/><part name=”Bstring” type=”xsd:string”/>

</message>

<message name=”Response”><part name=”Result” type=”xsd:float”/>

</message>

<portType name=”GettingResultService”><operation name=”GetResult”>

<input message=”Request”/><output message =”Response”/>

</operation></portType>

Figure 9 A WSDL document• Reusable part

(Interface)

• Non-reusable part(Implementation)

<definitions>

<types>[XML Schema describing the used datatypes]

</types>

<message>[Description of messages]

</message>

<portType>

</portType>

<operation>[Tying messages together in pairs]

</operation>

<binding>[Description of network protocol for invocation]

</binding>

<service>

</service>

<port>[Specify the service address]

</port>

</definitions>


In this example, the GettingResultService con-tains an operation that takes two strings, Astringand Bstring, as input and returns a float calledResult. In general, it should be noted that each<portType> could contain several operations.

Next, the <binding> element describes the mes-sage protocol with which the service can bereached. There can be multiple different bind-ings for the same <portType> in a WSDL, oneof which can be SOAP over HTTP.

In the non-reusable part of the WSDL document,<service> elements are used to describe the ser-vices. Inside the <service> elements are <port>elements that specify the actual network end-points of the service. A service can be madeaccessible on many ports, for example it can beavailable via both SOAP and plain HTTP GET.In this case two <port> elements should bedefined, each with a different name. One portshould specify the SOAP address, i.e. theaddress of the actual SOAP server handling therequest, and the other should specify the HTTPaddress.

The following gives an overview of how WSDLworks: When a service is deployed, its descrip-tion and a link to it is published in a UDDI reg-istry. When someone finds and wants to use it,

they can query the WSDL file to find out thelocation of the service, how to access it andwhich function calls to use. The information inthe WSDL file is then used to generate a clientthat can call the Web Service. This is illustratedin Figure 10.

4.3 Invoking Web Services – SOAPWith well-defined ways of publishing Web Ser-vices, finding Web Services and describing WebServices, the one basic requirement that is miss-ing is a standard way to invoke Web Services.First, consider the generic Web Services archi-tecture in Figure 11.

The Web Service is merely a layer that offersprogrammatic access to a service. The serverlogic itself can be implemented on traditionalplatforms using other kinds of middleware andusing any kind of programming language. Theaccess to the service consists of a façade thatexposes the operations or methods supported bythe business logic and a listener that is unawareof the service logic. This listener will typicallybe a SOAP application as SOAP is emerging asthe most widespread way to invoke Web Ser-vices over the Internet. One must not necessarilyuse SOAP for Web Services invocation, but as itis the choice of most vendors, its acceptance as astandard is growing.

The SOAP specifications [14], like the WSDLspecifications, were first released as a joint effortby IBM and Microsoft and have also been sub-mitted to the W3C organisation to become astandard. It defines the structure of SOAP mes-sages, a model for exchanging SOAP messagesand how SOAP messages over HTTP can beused for Remote Procedure Calls (RPC).

SOAP is a lightweight protocol that defines auniform way of passing XML encoded data. Indoing so it allows code of any kind, on any lan-guage and on any platform to cross-communi-cate, also between parties with no prior knowl-edge of each other or each other’s platforms. It isessentially a one-way messaging protocol, mean-ing that a sent message does not necessarily leadto a response message (unless something wentwrong while sending it), but two SOAP mes-sages can be combined in for example an HTTPrequest-response pair. Each SOAP messagecontains one XML document with root element<Envelope> and a <Header> and a <Body> ele-ment. Figure 12 shows the structure of a SOAPmessage.

The <Envelope> element serves as a containerfor the other elements of the SOAP message,and for this reason a SOAP message is oftenreferred to as a SOAP envelope. The <Header>element is optional and can add different fea-

Figure 10 How WSDL works

Figure 11 GenericWeb Services access

WebServicesrequester

UDDIregistry

find

publish

publish

Web Services provider

WSDL document

2

4

3

1

Invoke Web Services

XML Request

XML Response

List

ener

Ser

vice

Fac

ade

Service logic


tures to the SOAP message without affecting thepayload. Authentication is an example of suchan extension. An authentication server can pro-cess the header entries, independent of the<Body> element, and remove the information itused to validate the signature. The rest of themessage will be passed on to the SOAP serverthat will process the body of the message. Thepayload of a SOAP message is the <Body> ele-ment that contains the actual application specificdata that is to be processed by the end-point.

SOAP can be used in combination with a num-ber of other protocols. In the SOAP specifica-tions, however, the only bindings that are de-fined describe how SOAP can be used in combi-nation with HTTP. It is also described how touse SOAP messages for (RPC).

In a typical SOAP message exchange model,there are three basic components: A SOAPclient, a SOAP server and the actual service.The SOAP client creates an XML document, theSOAP message, with the information needed toremotely invoke a method over a network. ThisSOAP message is then typically sent overHTTP, allowing it to traverse almost any fire-wall. On the server side, a SOAP server listensfor SOAP messages and acts as a distributor andinterpreter of these. It then translates the XMLstructure in the SOAP message into a languagethat the actual service can understand. It alsotranslates the response from the service into aSOAP response that is sent back to the SOAPclient. In Figure 13, a SOAP message exchangeexample is given.

The exchange of SOAP messages does not haveto follow a traditional client-server model, asSOAP supports message chains or intermediates.A logical entity that performs some processingof a SOAP message is referred to as an endpoint.An endpoint can function both as a sender and areceiver and this allows for processing chains tobe created. These endpoints, which act as bothsender and receiver, are called intermediates andcan sit on the path a request takes from a senderto a receiver. The endpoints can use the<Header> elements to determine which parts, ifany, of the message is addressed to them. If theendpoint is an intermediate, it can remove theparts of the message addressed to it before send-ing it through to the next endpoint.

Figure 12 The structure of a SOAP message

Figure 13 A SOAPmessage exchange example

<Envelope>

<Envelope>

<Header>Contains optional context information</Header>

<Body>Contains the actual message to beprocessed by the end-point</Body>

SOAPResponse

SOAPRequest

Internet

SOAPProcessor

APIApplicationServer

Action

Result8

Java

C

Perl

Etc.

XMLParser

HTTP

HTTP

XMLParser

Java

C

Perl

Etc.

SOAPProcessor

API ApplicationServer

1

23

45

7

6

1

2

3

4

5

6

7

8

A command is executed that generatesa process witin the application. The resultarrives in the application interface.

The message is translated into XML formatand sent to the Web server.

The XML parser checks the coherence ofthe XML document and sends the SOAPmessage via HTTP.

The XML parser checks the validity ofthe message using the HTTP and XMLheaders and accepts or rejects it.

The message is routed to the relevantapplication server and translated so thatit is meaningful to the application.

The target application executes the taskand a result is produced.

The return is done in the same way.Translated to XML and sent by HTTP.

The result is returned. The result maybe displayed in a browser, access to adatabase, some actions, and so on.


4.4 Web Services Process FlowsOnce Web Services are commonplace on theInternet, new services can be composed byaggregating existing services, like illustrated inFigure 3. Usually, the different input and outputoperations must be performed in an exactly pre-defined order or sequence, and this operationsequence needs to be defined. To do this in aWeb Services environment would require tech-nologies that are able to describe Web Servicescompositions or workflows within newly createdapplications and even between companies.Appropriate usage pattern of a collection of WebServices to achieve a particular business goalshould be specified, e.g. a description of thebusiness process. The interaction pattern of acollection of Web Services should also be speci-fied resulting in a description of the overall part-ner interactions. For systems spanning enterpriseboundaries and systems made from differenttechnologies, an XML based process flow andpattern description would be useful. XLANG[15] and WSFL [16] are initiatives fromMicrosoft and IBM respectively, that addressesthese issues often referred to as orchestration.

5 ConclusionThis article has introduced and explained theWeb Services concept. It has outlined the mostimportant technologies normally used for XMLWeb Services and basically given a high levelunderstanding and answer to the question:“What is an XML Web Service?”.

XML Web Services are a new brand of servicesthat can be expected to have a big impact on theWorld Wide Web. As put by the XML ProtocolWorking Group at W3 in their charter [17]:

Today, the principal use of the World WideWeb is for interactive access to documentsand applications. In almost all cases, suchaccess is by human users, typically workingthrough Web browsers, audio players, orother interactive front-end systems. The Webcan grow significantly in power and scopeif it is extended to support communicationbetween applications, from one program toanother.

The Web Services model, continuing the historyof distributed computing, is a promising way toachieve such a universal application-to-applica-tion communication. It can lead to better cross-business integration, improved efficiency, costsavings in application development (due to fasterapplication development) and closer customerand vendor relationships. The three basic build-ing blocks in the Web Service model are invoca-tion, description and publishing/discovering ofservices. A number of different technologiescan represent each of these building blocks, but

some specifications emerge as the dominantones and are therefore more important than theothers, simply because they are commonlyaccepted as standards and agreed upon by majoractors. These dominant technologies are SOAPfor invocation of Web Services, WSDL fordescribing Web Services and UDDI for publish-ing and discovering Web Services.

All these specifications are based on XML mak-ing XML one of the cornerstones of XML WebServices. XML is important as it defines a stan-dardised way to format and exchange data, and itthus enables applications created with differenttechnologies, platforms and languages to com-municate with each other. Web Services usestandard Internet protocols like HTTP and thisallows ubiquitous access from across companyborders and firewalls. Various types of devices,from personal computers and servers to differentkinds of smart devices will be able to collaborateseamlessly.

The utilisation of XML Web Services technol-ogy can help bring the Internet to a new level,taking it from the traditional information-basedInternet to the emerging service-based Internet.In the service-based Internet, machine-to-machine communication will be commonplaceand service-based application development willbe prevailing. New opportunities for en evenricher and more meaningful collaborationbetween businesses and people will flourish andthose who take advantage of these opportunitiescan benefit greatly from it.

References1 Extensible Markup Language (XML) 1.0

(Second Edition). (26 June 2002) [online] –URL: http://www.w3.org/TR/REC-xml

2 XML Schema Part 0: Primer. (27 June 2002)[online] – URL:http://www.w3.org/TR/xmlschema-0/

3 The Extensible Stylesheet Language (XSL).(27 June 2002) [online] – URL:http://www.w3.org/Style/XSL/

4 Namespaces in XML. (27 June 2002)[online] – URL:http://www.w3.org/TR/REC-xml-names/

5 Harold, E R. XML Bible. Foster City, CA,IDG Books Worldwide, 1999. (ISBN 0-7645-3236-7)

6 Goldfarb, C F, Prescod, P. The XML Hand-book. Upper Saddle River, NJ, Prentice-Hall,1998. (ISBN 0-13-081152-1)


7 IBM developer Works: Web architecture:Web Services architecture overview. (27June 2002) [online] – URL: http://www-106.ibm.com/developerworks/library/w-ovr/

8 XML Web Services. (27 June 2002) [online]– URL: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsspecsover.asp

9 Web Services Architecture Requirements.(27 June 2002) [online] – URL:http://www.w3.org/TR/wsa-reqs

10 Cauldwell, P et al. Professional XML WebServices. Birmingham (UK), Wrox Press,2001. (ISBN 1-861005-09-1)

11 Defining Web Services. (27 June 2002)[online] – URL: http://www.stencilgroup.com/ideas_scope_200106wsdefined.pdf

12 UDDI. (10 July 2002) [online] – URL:http://www.uddi.org/specification.html

13 Web Service Definition Language (WSDL).(10 July 2002) [online] – URL:http://www.w3.org/TR/wsdl

14 Simple Object Access Protocol (SOAP).(10 July 2002) [online] – URL:http://www.w3.org/TR/SOAP/

15 XLANG. (11 July 2002) [online] – URL:http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

16 Web Services Flow Language (WSFL 1.0).(11 July 2002) [Online] – URL: http://www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

17 XML Protocol Working Group Charter.(12 July 2002) [online] – URL:http://www.w3.org/2000/09/XML-Protocol-Charter

AcronymsAPI Application Programming InterfaceASP Application Service ProviderB2B Business-To-BusinessCOM Component Object ModelCORBA Common Object Request Broker

ArchitectureCSS Cascading Style SheetsDCOM Distributed COMDNS Domain Name Service

(Domain Name System)DTD Document Type Definition

(Document Type Description)EAI Enterprise Application IntegrationFTP File Transfer ProtocolHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolIIOP Internet Inter-ORB ProtocolLAN Local Area NetworkPCDATA Parsed Character DataRMI Remote Method InvocationRPC Remote Procedure CallSGML Standard Generalized Markup

LanguageSMTP Simple Mail Transfer ProtocolSOAP Simple Object Access ProtocolUDDI Universal Description, Discovery and

IntegrationURI Uniform Resource Indicator

(Universal Resource Identifier)URL Uniform Resource Locator

(Universal Resource Locator)WSDL Web Services Definition Language

(Web Services Description Language)WSFL Web Services Flow LanguageWWW World Wide WebW3C World Wide Web Consortium XML eXtensible Markup LanguageXpath XML Path LanguageXSL eXtensible Stylesheet LanguageXSL-FO XSL Formatting ObjectsXSLT XSL Transformations

Telektronikk 4.2002

1 Why DistributedProcessing?

Distributed processing simply means that com-puters in different locations cooperate in order toperform common tasks. Therefore, distributedprocessing is nothing new in telecommunica-tions: in automatic telecommunications systemsdistributed processing has always been requiredin order to establish calls in the network. It isnot so obvious that operations of telecommuni-cations network require even larger and morecomplex interconnected computer resources inorder to obtain information for charging andbilling customers, collect performance statisticsrequired for evolution and maintenance of net-works, perform remote management and surveil-lance of switches, routers, satellite earth stations,SDH multiplexers and other equipment, and exe-cute a number of other complex tasks. The oper-ations system is also one of the most hetero-geneous systems that exist being composed ofall imaginable types of computing devices hav-ing been manufactured during the last twentyyears. Not only is the physical topology complexbut the software functions these computers exe-cute are written in an admixture of most mod-elling and programming languages developedduring the last thirty years or more.

Installations such as satellite earth stations, tele-phone exchanges, large databases, and local areadata networks consist of clusters of several com-puters. Power plants, oil refineries, flight ticketbooking systems, and signal systems of railwaysalso consist of clusters of cooperating comput-ers. Distributed processing is required in theproduction of almost all services and goods.The common denominator of all these systemsis that they are heterogeneous.

All the above systems belong to a single organi-sation and are usually manufactured by onemanufacturer – or if several manufacturers aredesigning different parts of the system such asin telecommunications networks, the design is inaccordance with precise interface and interopera-tion specifications developed by the owner ofthe system. This makes it easier to handle het-erogeneity. When such systems are distributedover many administrative domains and employ-ing a multiplicity of technologies, we are againfacing immense problems related to heterogene-ity. Now we are also facing the additional, andby no means simpler problem, of agreeing todevelop a single technological standard.

The reasons to develop standards for distributedprocessing were several. The owners of largesystems want to reduce the market power of theequipment manufacturers by specifying opensoftware interfaces so that different manufactur-ers can compete to deliver software and hard-ware components for the same application. Thiswas the driving force behind the InformationNetworking Architecture (INA) developed byBellcore between 1985 and 1995. Their intentionwas followed up by the development of theTelecommunications Information NetworkingArchitecture (TINA) by an international consor-tium consisting of telecom operators and manu-facturers of ICT equipment and systems. Thiswork took place between 1992 and 2000. WhileINA should primarily offer distributed process-ing in telecommunications systems only, theintention of TINA was to develop a general plat-form suitable for both operating the telecom net-work and processing services implemented inthis network.

Some systems have become so large and sodynamic that they need the support of platformsshielding the application from the effects of soft-ware and configuration errors. There are complexglobal systems for passenger transfer in interna-tional air transport, for monetary settlementsbetween airlines, and for rebooking of flight tick-ets. The CORBA (Common Object Request Bro-ker Architecture) platform was developed by theObject Management Group (OMG) in order tooffer a possible solution to these challenges. Aslightly modified CORBA platform is the base-line architecture of TINA. Though the CORBAplatform is commercially available from severalmanufacturers, it never became the commercialsuccess that OMG expected.

None of the platforms developed so far havebecome commercial successes. However, theneed to develop such platforms has becomemore urgent. The reason is the large number ofcooperative systems now being explored. Theseinclude platforms for peer-to-peer communica-tions and anarchistic networks, international sys-tems for road payment, platforms for medicalmonitoring, swarms of interacting sensors, plat-forms of wearable computers, and many moresophisticated applications. Most of the newapplications also include mobile interfaces withstrong data-security protection requirementsmaking it more urgent to standardise distributedprocessing platforms.

Distributed Processing Platforms:TransparenciesJ A N A A U D E S T A D

Jan A Audestad (60) is SeniorAdvisor for Telenor CorporateUniversity. He is also AdjunctProfessor of telematics at theNorwegian University of Scienceand Technology (NTNU). Hehas a Master degree in theoreti-cal physics from NTNU in 1965.He joined Telenor in 1971 afterfour years in the electronicsindustry. 1971 – 1995 he didresearch primarily in satellitesystems, mobile systems, intelli-gent networks and informationsecurity. Since 1995 he hasworked in the area of businessstrategy. He has chaired a num-ber of international workinggroups and research projectsstandardising and developingmaritime satellite systems, GSMand intelligent networks.

[email protected]

16


Detailed descriptions of the different platformsare found in the specifications developed bystandardisation organisations and industrialgroups (ITU, ETSI, ISO, OMG, TINA Consor-tium, IEEE). The general principles for dis-tributed processing were developed by ISOunder the heading Open Distributed Processing(ODP). The ODP standard defines the underly-ing principles of specifying and designing dis-tributed platforms: it is not concerned with spec-ifying any particular type of platform. Becauseof its general nature, the ODP standard is stillthe most important reference to distributed pro-cessing.

The description of the transparencies givenbelow builds on the experience with ODP,CORBA and TINA. The reason for choosingthese standards as the basis for this article is thatthey are specifications of large, universal sys-tems for distributed processing. The ideas weredeveloped in large groups with continuousreview of the solidity and applicability of theideas both from a technological and a commer-cial viewpoint. Future platforms should build onthese experiences in order to generate new ideasand to save time by not reinventing the wheel.

2 Baseline Principles ofDistributed Processing

One major problem concerning the design ofcomputer platforms for distributed processing isthe definition of the functions that the platformshould offer. These include runtime managementof the platform, storing and retrieving permanentand temporary data, organisation of the softwaremodules, and management of the distributedprocessing itself.

The most important principle of designing a dis-tributed computer application is that first theactual configuration of the system is ignored,that is, the design is based on the assumptionthat the computer system consists of onemachine and one user. This means that the appli-cation is defined in the same way as for main-frame computer-applications in general. Afterthis has been accomplished, the application isdistributed on the computers making up the sys-tem. The purpose of platforms for distributedprocessing is then to enable the system itself toensure interoperability of the software objectsmaking up the application irrespective of howthe objects are distributed over the individualcomputers of the system.

In this way, the design of the application is inde-pendent of the actual configuration of the sys-tem: how many computers it consists of, whichcomputer does what task, where the computersare located, how the computers communicate,and how the hardware and software configura-

tion changes over time. The advantage of thisdesign method is, of course, that the actual com-plexity of the system is hidden so that the de-signer of the application software need not takeinto account how the final system is configuredwhen writing the software.

The mechanisms for managing interoperabilityof the software objects are the transparenciesdescribed below.

Figure 1 shows what the configuration of thedistributed system looks like. It consists of theapplication software interfacing the platformsoftware in each computer. The distribution plat-form then interfaces the runtime system of thecomputer in such a way that it looks as if theplatform is common for all the computers ofthe distributed system.

The distributed processing platform connectstogether all the computers in the system – or thecomputing nodes as they are denoted in ODP.The platform software is contained in each com-puter, and it is written in accordance with theinterface towards the operating (or runtime) sys-tem of the computer. This interface is machinedependent so that different versions of the plat-form software must be written for different oper-ating systems: Microsoft windows, Linux, Unixand so on. However, the platform ensures thatcomputers with different operating systems caninteroperate in order to execute the distributedapplication.

The software of the distributed platform is alsocalled middleware since it acts as a mediatorbetween the application and the runtime systemof the computer.

The application software objects are written in astandard language such as Java or C++ that canbe compiled at each computer. The ApplicationProgramming Interface (API) ensures that allsoftware objects are written using a commonsyntax such that objects designed by different

Figure 1 Distributedcomputation

Computer 1

Applicationsoftware

Runtimesystem

Platformsoftware

Computer 2

Applicationsoftware

Runtimesystem

Platformsoftware

Machineindependent

API

Machinedependentinterface

Distributionplatform

Inter-computer communication


manufacturers can be purchased and imple-mented on the same platform.

The basic requirements of platforms offeringdistributed applications are as follows.

• Concurrency. Many applications require pro-cessing of concurrent (or simultaneous) pro-cesses in a single machine, in a complex ofmachines at one site, and in machines atremote locations. In this context, concurrentprocesses are independent processes sharingthe resources of the computers in some prede-fined way. Distributed platforms for telecom-munications applications and database appli-cations must offer concurrency. The transac-tion network for money transfer betweenbanks is a concurrent system.

• Parallel processing. Parallel processing com-prises two algorithmically different methods:distribution of a single algorithm on severalcomputers where each computer executesparts of the problem (e.g. factoring large num-bers, searching over large databases for ille-gally decoding a cryptogram, or decoding thehuman genome), and complex programs con-sisting of many tasks that can be executed atthe same time but where execution of the dif-ferent tasks must be synchronised in order toproduce the final result. Most distributed sys-tems are concerned with problems of the latterkind.

• Timesharing. Timesharing is quasi-parallelprocessing within a single processor. Thismeans that each concurrent process isassigned cyclically occurring timeslots whereit uses the resources of the computer alone.Between each timeslot, the state of the compu-tation; that is, the set of intermediate results, isstored in memory. In this way, the processingtime is evenly distributed between the concur-rent applications.

• Timesharing may sometimes be combinedwith priority where the processing timeslotsallocated to each concurrent process dependon type of process, its real-time requirement,or other information.

• Many distributed processes require real-timeprocessing; that is, the processing has to becompleted within strict time limits. If it cannotbe completed within this time, the processinghas to be terminated in a controlled manner.

• Weak coupling means that only a small num-ber of messages are exchanged between anypair of software objects involved in a parallelprocess. This implies that distributed applica-tions should be designed in such a way that

software processes requiring heavy exchangeof information should, if possible, be con-tained within the same object. If a process ormachine is overloaded, it is often better thatit ignores new requests and leaves it to therequesting process to detect and act upon lackof response. Similarly, if an acknowledgementthat a message has been received is not strictlyrequired, it should not be sent in order toreduce processing load and protocol capacity.When specifying and designing systems,much work should be put in weakening syn-chronisation, removing unnecessary acknowl-edgements and defining procedures forautonomous fault handling. This is probablythe single most important activity whendesigning a system.

• Information hiding is a concept that applies toboth software objects and systems. Objects aredesigned in such a way that only the knowl-edge (syntax and semantics) of the interfaceof the object is required in order to access theservices offered by the object. This is one ofthe most important aspects of object-oriented(OO) design. Systems are specified anddesigned in a similar manner: the only infor-mation ensuring cooperation between systemsis the syntax and semantics of the protocolinterconnecting them. Information hiding isthus the most important mechanism there isin order to handle heterogeneity. This is soobvious that it is often overlooked.

• Weak synchronisation means that a system,process or object has no a priori knowledgeof when it will be invoked by another process,which process is initiating the request, orwhether the invocation is remote or local.

• Heterogeneity implies that the platform mustbe such that it can be implemented in differenttypes of equipment ranging from microproces-sors of mobile phones to mainframe comput-ers, equipment of different vendors, andequipment spanning a considerable range ofage, say ten years or more.

• Fault management. Each system, process orobject must be able to react to faults on itsown, including autonomous processes for faultdiscovery, fault diagnostics, fault recovery,isolation of faulty software and hardware,redundancy management, and backup memorymanagement. Autonomous fault recovery iscomplex and expensive but is one of the stan-dard features of telecommunications systems.The reason why this is so important for tele-communications systems is the enormousimpact even a short outage may have on soci-ety. Failure of several of the new applicationsmentioned above will have similar severe


impact on businesses, public management andsociety as a whole.

The purpose of the transparency is to implementthese and several other objectives. However,before describing the transparencies, let us havea look at what telecommunications networks andapplications look like.

3 General Model of Tele-communications Systems

Any type of terminals can be connected to thetelecommunications system as shown in Figure2. The network consists of two parts:

• The network infrastructure offering accessconnections to the user equipment, and trans-port and routing of bits (including mobility)between access points.

• The operations system responsible for allmanagement of the telecommunications sys-tem, including recording of usage informationand statistics, performance monitoring, faultsupervision and recovery, reconfigurationmanagement, quality of service and securitymanagement, and handling of subscriptionprofiles. The operations system is built oncomplex, distributed platforms meeting mostof the requirements listed in Section 2 above.

Note that in this model the user equipment is notpart of the network.

Figure 3 shows the same configuration exceptthat now platforms are included. There is oneplatform supporting the distributed processingof the network infrastructure and the operationssystem, and there is another platform imple-mented on the terminals offering distributed pro-cessing to them. The platform supporting thenetwork and the platform existing on the userterminals may be the same type of platform orbe different. The functionality of the two plat-forms is not interconnected but is serving twoindependent purposes.

Figure 4 shows how the Internet is configured.The reasoning that follows applies to all applica-tions except telephony1) since all new applica-tions are implemented on the Internet or a net-work with similar functionality. (We may safelyassume that the basic principles of the Internetwill be implemented in all telecommunicationsnetworks in the foreseeable future.)

The Internet offers IP at the interface to the userterminal. The IP protocol does not offer servicecapabilities beyond routing, mobility and a fewother capabilities; for example, predeterminedrouting for support of real-time applications suchas telephony and video. This is true both for IPversion 4 and IP version 62). IP does not offersimple integrity services such as secure delivery Figure 3 Processing platform

1) The telephone network is different because the telephone apparatus does not offer significant functionality beyond that of making telephone calls.The network then contains all functions required for intelligent management of services. In the Internet, this management can be done in the terminals.

2) Capabilities beyond routing and simple mobility support are not really implemented in IP version 4 although several additional capabilities arespecified in the standard. This is why IP version 6 was developed.

Figure 2 Telecommunicationsnetwork

Networkinfrastructure

Operations system

Networkinfrastructure

Operations systemPlatform

Platform


of information and recovery of information lostin the network. IP offers a transparent interfaceto TCP, UDP or any other transport protocol.

TCP and UDP are end-to-end protocols; that is,they offer only interconnection of software pro-cesses existing in terminals. TCP and UDP aretransparent vehicles for transporting informationbetween these software processes. The informa-tion contained in the information field of a TCPor UDP packet can be structured (e.g. a remoteprocedure call) or unstructured as in the transferof a video picture or a file. There is no way inwhich you can tell which type of information istransferred by simply looking at the TCP/UDPheader. It is only the sending and receiving ter-minals that know what type of information isbeing transferred and how it is to be interpreted.For example, in file management the transfermay alternate between structured information(management of file parameters) and unstruc-tured information (transfer of file content).

The network operator may well offer access toservices that require TCP/UDP as the vehicle fortransferring information. If so, these services areaccommodated in equipment connected to thenetwork in the same way as any other terminal.In other words, the network operator has noadvantage of offering services above TCP/UDPcompared to a service provider connected to thenetwork. Regulations even prohibit the networkoperators from offering such access to them-selves at a lower price than to other providersoffering equivalent services. Depending upon

how clever the operator is, the service offer maybe better and cheaper than that of the competi-tors. This is not an advantage gained by owningthe network but by being cleverer in marketingand pricing the service.

A platform supporting distributed computing isthus offered on top of TCP/UDP. This platformmay offer distribution of processing and storingof information, enhanced mobility such as mov-ing sessions between terminals, transaction ser-vices, and transparent data security services suchas access control, authentication and confiden-tiality.

The applications are implemented on top of theplatform as explained above. In Figure 4 this iscalled the socio-robotic layer; socio because itincludes communication between people, androbotic because it includes communicationsbetween machines. The socio-robotic layer cor-responds to the application shown in Figure 1.

4 Transparencies

4.1 IntroductionThe remainder of this paper is concerned withthe transparencies. Formally the transparenciescan be defined as the set of functions that mapthe design from a mainframe description onto adistributed configuration. The principle is illus-trated in Figure 5. The transparencies thus for-malise the principle stated at the beginning ofSection 2.

Figure 4 Network,platform and applications

RouterRouter

(Disributed computer application)

Platform(Transparencies

transport protocol (TCP/UDP)

Host (PC, server, database, sensor...)

Network

IP(Terminal mobility, routing)

Demarcationline betweenplatform andnetwork

Socio-robotic layer


4.2 AccessAccess transparency hides from the applicationsmessage formats and protocol details requiredfor operating in the heterogeneous environment.The application will thus see a standardisedinterface to its surroundings independent ofwhere (e.g. remote or in the same machine) thecooperating application is located and on whichtype of computer hardware it is operating. Thetransparency is the most important element insolving the core issues of heterogeneity: differ-ent types of computer hardware and operatingsystems, different data rates and transfer proto-cols offered at different network interfaces, anddifferent capabilities of the terminals. Therefore,every distributed system must support this trans-parency.

In Figure 5, there may be different protocolsbetween the different computers in the dis-tributed environment: one protocol can be TCPover WAP, one UDP over Bluetooth and oneTCP over IP.

The platform contains various software objectsimplementing the transparency. One such set ofobjects adapts the general protocol offered atthe API to the system-dependent protocol imple-mented on the connection. The transparency alsoensures binding; that is, establishing the connec-tion to the right peer object, retaining this rela-tionship as long as required so that messages arenot misrouted, and removing the connectionwhen it is no longer needed. In some cases, itmay even be necessary to install protocol soft-ware or set protocol parameters at the initiationof the connection involving negotiations with thebinder object of the peer system in order to agreeon a common protocol. The application is igno-rant of these activities taking place.

The access transparency makes it possible toinstall the same software at fixed locations oper-ating at 100 Mbps and mobile phones offering9600 bps. The protocols at these locations willhave different characteristics but the platformwill ensure that the software object installed atthe different locations will interface the protocolin the appropriate way.

4.3 LocationLocation transparency hides the location of anapplication from other applications. The trans-parency ensures that an object can be inserted inan arbitrary computer and still be found by anyother object wanting to communicate with it.The location address of cooperating objects needthen not be included in the program code of theobjects: it is enough to indicate in the programcode which other type of object is needed inorder to complete the task. The transparency isrealised by two simple functions: when a new

object is registered in the system, the identityand the location of the object (that is, in whichcomputer it is installed) together with other rele-vant information such as the services it offers areannounced to one or more address directories.When another object wants to use the servicesoffered by the object, it passes its request to thebinder of the access interface. The binder thensearches for the address of a suitable objectoffering the service in the address directories.

The implementation of location transparencyseems simple, but it is not. It is a simple andunproblematic task to store the address of theobject in the computer where it is located andin computers placing remote calls to this objectregularly. It is more difficult to agree on aworldwide structure consisting of address direc-tories accessible to anyone. Some questions are:who should own these databases; should it costanything to access the directory and to registerinformation in it; and who is responsible for thecorrectness of the information contained in thedirectory? These aspects are not technical butlegal and commercial, and are therefore muchharder to solve.

4.4 ConcurrencyConcurrency transparency or transaction trans-parency coordinates the interactions arisingwhen several applications interact with oneanother at the same time. The transparency pre-serves the consistency of an object being usedconcurrently by several other objects. The con-currency mechanism is built into the platformand not included in the individual objects mak-ing the objects simpler and more universal. Themechanism in the platform serialises and com-

Figure 5 Mapping frommainframe to

distributed system

Mainframeruntime system

Application

Softwareobject

Distributiontransparencies

Runtimesystem

Runtimesystem

Runtimesystem

Distribution network

Platform


pletes individual transactions on an object inaccordance with the ACID rules. ACID standsfor the following:

• Atomicity. A transaction is completed eitherfully or not at all (partial transaction resultsdo not exist).

• Consistency. The action of the transactionalways leads to a result that is in agreementwith the specifications of the transaction ser-vice.

• Isolation. A transaction in a concurrent systemis performed as if it was alone (serialisation).

• Durability. The data can only be changed bytransactions: only a new transaction can alterthe result of the previous transaction.

In addition to the ACID requirements, the plat-form must also protect against deadlock; that is,the platform must always be able to terminatea transaction (for example by cancelling it) alsowhen the transaction fails to terminate on itsown. This task is particularly challenging if theoperation consists of a complex set of linked andnested transactions between several objects.

The concurrency transparency also hides to anobject that several objects are concurrently usingthe other object.

4.5 Migration and RelocationMigration transparency is an extension to loca-tion transparency making it possible for the sys-tem to change the location of an applicationwithout the application knowing that it is moved.Such relocation may take place even while otherapplications are interacting with the process be-ing relocated without disrupting ongoing inter-actions. Migration may be required in order toreconfigure the processing load of computers,move the computation session from one user ter-minal to another, or do system maintenance.

When an object is migrated, the following activi-ties may take place:

• The processing of the object is stopped, andthe processing state of the object and address-ing information required for reconnecting theobjects to its peers are stored in a backupmemory. The processing state consists of apointer indicating exactly which programstatement is the next to be executed and thetemporary results of the computation stored atthat instant. This is also called checkpointingand is used for other processing purposes also(maintenance and fault recovery). Connec-tions to other objects are suspended until theobject has been relocated.

• Then the data of the processing state is trans-ferred to the other computer so that the objectcan be reinitiated at the correct state in thenew computer. Either the complete programlisting of the object (compiled or uncompiled)or a reference to the template in which theprogram listing can be found is also senttogether with the data.

• The new computer installs the object and initi-ates it with the processing-state data.

• Finally, the connections with other objects arere-established. This is in itself a complex pro-cess involving the binders of the access system.

Migration of objects may also make use of syn-chronised replicated objects (see below) where areplica of the object to be moved is first initiatedin the new location. Then the replicated objectis synchronised to the original object, and whenthis has been completed, the original object isterminated. Synchronisation makes use of check-pointing and transfer of the checkpoint data tothe replicated object.

The location of the new object may then bestored temporarily in databases so that the objectcan be found if needed by other applications.

This capability of hiding that relocation takesplace is called relocation transparency. Migra-tion transparency and relocation transparency aretherefore two aspects of the same mechanism:migration transparency allows applications to bemoved while the relocation transparency hidessuch events from other applications bound to theapplication being moved.

4.6 ReplicationReplication transparency hides the replication ofone object from the objects using it. Replicationmeans that two or more objects are doing thesame task and that each object is a replica of thesame object type. The replicated objects may runin different computers. The platform takes careof synchronisation and other processing depen-dencies of the replicated objects.

The replicated objects may be fully synchro-nised, that is, they do exactly the same process-ing at the same time. The platform synchronisesthe objects and ensures the integrity of the datathey contain. This type of replication is used inorder to create security groups where the objectsact as hot standbys for one another: if one objectfails, the other objects can still execute the task.Synchronous replication is also used when thesame information is required at different placesat the same time and where it is more practicalthat two objects are used instead of one, e.g. toreduce processing load and processing delay.


One object may interface one, several or all ofthe replicated objects of a set. The platform takesthen care of how the communication is arrangedand managed.

Mobile agents may be asynchronous or syn-chronous replicated objects sent to different com-puters where they are executed. The process send-ing out the mobile agents is not aware of howmany replicas exist and where they are located.Processes in the platform manage the multiplebinding to all the agents and organise the informa-tion exchange between home base and agent.

The replication and migration transparencies areimportant tools for managing processing load.

4.7 PersistencePersistence transparency implies that activationor deactivation of objects is not explicitly visibleto other objects. Hence, the transparency sup-ports evolution of the system in the sense thatnew software may be added or old softwareremoved without having impact on other partsof the system.

The transparency also hides from other objectsthat the software of the cooperating object iscompiled and instantiated when an operationtowards it is invoked; i.e. the object is not persis-tent but created whenever someone uses it.

The program code of the objects can be loadeddown from specification repositories possiblysubject to commercial rules. The platform mustthen contain the software (the factory software)capable of loading down the template and thecompiler that compiles the program code of theobject. The actual object compiler may then beassociated with the template and not be stored inthe computer where the object is initiated. Thisallows more flexible computer configurationsince the computers need not be prepared a pri-ori for all the compilers and languages in whichthe objects are written.

4.8 FailureFailure transparency hides failure of one objectfrom other objects and prevents other processesfrom failing as a secondary effect. The trans-parency also hides encapsulation of failedobjects, recovery actions taken to restore normaloperation, and any subsequent rearrangement ofthe system.

The automatic restart systems of telephoneexchanges and satellite earth stations are exam-ples of implementations of failure handling ofthe type to be implemented in distributed pro-cessing platforms.

4.9 SecuritySecurity transparency comprises several com-plex functions such as access control, authenti-cation, certification, confidentiality and dataintegrity, non-repudiation, notary public ser-vices, anonymity management, and non-trace-ability. Each of these functions can in fact beviewed as a separate transparency because theimplementation of each of them requires its ownnetwork functionality. The transparencies arealso difficult to implement because they requireaccess to specialised equipment including publickey and naming directories, key generation anddistribution systems, databases containing accesscontrol information and access decision algo-rithms, certification management systems, andsystems for producing and storing non-repudia-tion information.

Examples of platforms offering automaticauthentication and encryption without involvingthe call handling functions are the GSM platformand the UMTS platform. These transparenciesare simple. However, transparent access controland notary public services are very complex anddifficult to implement. Figure 6 shows howsecurity features can be built into the platform.

The example shows two communicating objects:the client object initiating the interaction and thetarget object. The security system consists ofsoftware in the end systems, that is, the sendingand the receiving computers, and in a number ofthird parties offering support to the end systems.

The end systems may contain the followingfunctions: Figure 6 Security

transparency

Clientobject

Targetobject

Third parties

Naming directory• Public key managerKey management• Generation• DistributionCertificationNotary public• Witnessing• Event storageAnonymity

Platform

Access control• Operation• Interface• UserIdentification• Name• Authenticity• SignatureConfidentiality• Hashing• Encryption

Othertransparencies

Access control• Operation• Interface• UserIdentification• Name• Authenticity• SignatureConfidentiality• Hashing• Encryption

Othertransparencies

Message Recovered message API

Secured message

Network


• Access control provided for each operation,access control associated with each objectinterface, and access control associated witheach user. The sending system will checkwhether communications with the targetobject is allowed, whether the parameters ofthe operation is within allowed limits, andinsert access information that the receivingsystem can use in its analysis. The receivingsystem will analyse whether the user isallowed to access the system (only my wifeand I have read access to our joint bankaccount but we do not have write access),whether the interface is allowed to service theaccess request (the read interface cannot beused to change the amount of money on theaccount), and whether the invoked operationis allowed (my wife and I can invoke readoperations and payment service operations).Access control may in addition depend onother parameters or events such as type ofauthentication, certificates provided by thirdparties, message confidentiality and integrity,and the time when the operation was received.

• Identification including secure naming ser-vices, retrieval of public keys from third par-ties, authentication of client and target objects,and provision of electronic signatures to beattached to messages. The keys used forauthentication may also be secret keys gener-ated by a third party. Retrieval of public keysand generation of secret keys may require cer-tification by a third party.

• Confidentiality services include encryptionand integrity protection, for example, byhashes, timestamps or nonces. Third partiesmay generate and distribute encryption keysand nonces.

Third parties may support capabilities beyondthose just described. This may include anonym-ity where aliases replace plaintext addresses overunsecured connections (GSM offers this featureover the radio connection), and notary publicservices offering non-repudiation. The latterincludes witnessing that events take place andstoring data associated with the event. The datacan be retrieved later in order to settle disputesconcerning whether or not an event took placeat a certain time.

4.10 MobilityMobility transparency enables design of soft-ware processes independent of whether they arerun on mobile or fixed systems. The problemassociated with mobility and transparency isillustrated in Figure 7. The figure shows a userrunning a session at a terminal connected via anaccess to a network, that is, involving five ele-ments each having its own characteristics: userprofile, session characteristics, terminal charac-teristics, access type, and network characteris-tics. There are three mobile interfaces: betweenthe user and the terminal, between the sessionand the terminal, and between the terminal andthe network, the latter being managed by the net-work. The platform implemented above TCPmust support user mobility and session mobility.This implies also that the relationships betweenuser and user profile and between session andsession characteristics are retained during mobil-ity. However, how the user profile and the ses-sion characteristics are to be interpreted, dependson the terminal characteristics, the access typeand the network characteristics.

User mobility implies that the user moves fromone terminal to another. The major concern hereis to retain the user profile and adjust it in accor-dance with the new terminal characteristics, thenew access type, and the new network character-istics associated with the new access. The userprofile is concerned with which applications theuser is allowed to initiate (files, programs, operat-ing systems, e-mail, Internet), which access rightsare assigned to him as a user, and which securityfeatures are required for different types of access.This means that the capabilities available to theuser may be different if the access is inside a fire-wall or outside the firewall. The mobility trans-parency shall take care of these functions.

Session mobility makes use of the migration andrelocation transparency in order to move parts ofthe session. In addition, session mobility re-quires management of the session characteristicsand adjusts it in accordance with other systemcharacteristics similar to user mobility. When asession is moved, for example, from one side ofa firewall to the other, this is likely to requirereestablishment of the security features.

Figure 7 Mobility

Network characteristicsDepends on access

Network

Access typeNew

Terminal characteristicsNew

Terminal characteristics Mobile interface

Access type

Mobile interface

User mobility

Session characteristicsInvariant

User profileInvariant

Session mobility

Terminal mobilityMobile interface

Terminal Terminal

User User

Session Session


4.11 Processing Dependency andGrouping

Processing dependency and grouping trans-parency hides how timesharing and other depen-dencies between applications are realised. It alsohides all types of grouping of objects into pro-cessing entities and the reason for forming suchgroups (commercial packaging, load optimisa-tion, or timing constraints). Note that the sameapplication may be organised differently in dif-ferent machines and by different organisationsbut that the modelling of the application shouldbe independent of this.

In CORBA the processing dependency trans-parency supporting timesharing is implementedas threads in the computing node software. Otherdependencies such as handling of internal proce-dure calls versus remote procedure calls andshared memory are also implemented in organis-ing objects (groups and clusters).

4.12 FederationFederation transparency implies that the dis-tributed system may be modelled and designedindependently of business relationships andownership of applications over systems spanningseveral owners. This is particularly importantwhen designing telecommunications systems.

A distributed system may be divided intodomains representing ownership, technology andother aspects varying over the system. Such sub-divisions are then not visible to the users of theplatform.

4.13 ScalabilityScalability transparency means that the systemmay grow in size and incorporate new function-ality without redesigning the system architectureand software objects already installed. The loca-tion transparency takes care of the flexibleaddressing and identification required forsmooth scalability. The access transparencypartly solves the heterogeneity issues. The feder-ation transparency takes care of heterogeneityassociated with ownership and administrativeresponsibility so that the platform can span sev-eral organisations and businesses. However, thisis not enough to ensure that new computers con-taining the distribution platform can be installedin the system without extensive managementactivities involving already installed computersand systems such as reconfiguration of the archi-tecture and re-initiation of the platform.

The scalability transparency must supportsmooth introduction of new platform capabili-ties, facilitate easy installation of new hardware(user terminals, databases, servers, mainframecomputers and so on), and rearrangement andevolution of the platform topology.

The Internet is the best example of systems withextreme agility with regard to scalability. Themost important feature there is that routers arecharged with the autonomous task of figuringout what their environment looks like. Thisincludes also topological information such aswhich other routers are in the environment. Thetraffic handling capacity of the resulting networkis not system optimal since each router makes itsown independent decision. The advantage is, ofcourse, that the network does not need manage-ment resources in order to update topologicaldata: the identity of the nearest neighbours,which routers are operational and which arefaulty and taken out of service, instantaneousmaps of the traffic distribution, and tables indi-cating how calls shall be forwarded at eachrouter.

However, the type of platforms considered inthis paper are platforms interfacing TCP, UDPor another end-to-end transport protocol. There-fore the scalability of the Internet will have noimpact on the scalability of these platforms.Scalability must be implemented once morein a different part of the system.

5 ConclusionWe have described twelve transparencies thatshould be included in platforms for distributedprocessing. The most complex platforms, includ-ing CORBA and TINA, only offer access trans-parency and location transparencies as manda-tory platform elements. However, even thesetransparencies do not offer full support of allthe characteristics required for flexible serviceimplementation.

Some of the transparencies described above areincluded not as transparencies in CORBA andTINA but as other service features of the plat-form (persistence, processing dependencies andgrouping, and simple security services).

The reason why even these advanced platformsdo not offer more is that it is difficult and expen-sive to implement the transparencies.

Platforms for distributed processing have existedas commercial products for not more than six orseven years. The specifications of some of theplatforms are still not complete and will never befinished. It will probably take at least ten moreyears before platforms with the desired charac-teristics are available for general commercialuse. The platform software is complex and huge.Therefore, the platform can only be accommo-dated in future generations of microprocessors.However, the technology must be developednow in order to be available within the nextdecade or so.


Several of the transparencies are much morecomplex and commercially important than theother transparencies. These are particularly con-currency, security, mobility and scalability.These are also the transparencies that are themost urgent to implement. The reasons are:

• Concurrency or transaction handling isrequired in large applications such as banking,finance and e-commerce. Banking includesdiverse applications such as transfer of moneybetween banks, remote management of users’accounts, electronic payment of services andgoods, and automatic payment of road toll,parking charge and energy usage charge. Suchtransactions will soon be required by comput-ers everywhere: the PC at home, cash registersin shops, e-money databases, the electricitymeter, the road payment chip, the parkingmeter, and so on. The transparency will there-fore be used in a number of diverse applica-tions. To be more general: whenever informa-tion is stored in or retrieved from any deviceeven remotely resembling a database, transac-tion services are involved.

• Security is hardly being implemented in anysystem yet. The transaction services describedabove rely heavily on security: confidentiality,e.g. in order not to disclose secret keys ex-changed between payer and merchant, data-integrity hashing and timestamping to protectagainst manipulation of content, non-repudia-tion to prove that a transaction has taken place,authentication to establish secure identity, andaccess control to protect against fraudulentmanipulation of any type of information, in-cluding bank accounts. Security will also, forthe similar reasons as for transactions, becomea key feature in remote access to business sys-tems, in cooperative work, and in distributedmanagement systems of government and busi-nesses. The urgency of implementing securityon a grand scale is also evident from the factthat the number of security attacks on com-puter systems at least doubles every year. Thisis the highest form of e-persecution mania!

• Mobile access both on radio and fixed lines isubiquitous. Presently only terminal mobility isgenerally supported (radio systems and mobileIP). This type of mobility is well handled bythe network. Personal mobility allows peopleto access the same processing session at dif-ferent terminals with different capabilities andcharacteristics. Session mobility moves pro-cessing sessions between different computersand between different users. Personal mobilityand session mobility are still not solved in asatisfactory way. These advanced forms ofmobility also require strict security.

• Scalability must be built into the platformfrom the beginning. Platforms are too oftendesigned for a single application, employing asingle technology, fitted to the needs of a sin-gle user, or installed in a single system. Roadpayment platforms are designed for the singlepurpose of collecting road toll, are employingpassive radio beacon technology, are specifiedand used by a single road authority, and areimplemented as a system consisting of a smallnumber of toll stations, a financial institutionhandling the administration of collectedmoney, and the management system of theroad authority. Such systems are certainly notscalable in any interpretation of that word.

There are several reasons why standardised plat-forms are not becoming the expected commer-cial success. The platforms are complex andexpensive to build so that most of the sales pricedepends on the number sold. Therefore, thebuilding and marketing of new platforms is arisky business. The platform may not offer whatthe users want, the reason being that the specifi-cation is done in large groups run by organisa-tions having diverse motives for implementingplatforms. Such platforms consist often of setsof compromises satisfying as many compro-mises as possible. The result is that the platformis not attractive to anyone; it contains too muchof what is not needed and too little of what isneeded. It takes much time (ten years is ratherthe rule than the exception) to finish the specifi-cations. The platform design is then facing adifferent reality when it is finished than whenit was conceived.

These problems do not imply that joint efforts tospecify platforms is a waste of time and shouldbe abandoned. Platforms are more needed thanearlier so that the efforts should go on; sooner orlater the process converges and platforms thatare commercially viable are a reality.

However, platforms developed by a singleorganisation may not reach the market either.The OLE platform of Microsoft is an exampleof this.

If the reader is involved in designing or purchas-ing distributed platforms, he or she is referred tothe vast amount of available literature on plat-forms. Detailed data concerning ODP, CORBAand TINA can be found on these Internetaddresses:

www.iso.org and search for Open DistributedProcessing

www.omg.www.tinac.com

27

Today, the Internet’s two most popular servicesare e-mail and the World Wide Web. However,as the Internet evolves over the next few years,we are likely to see Web services becomeequally popular since they, ultimately, willenable companies to conduct e-Business moreeffectively and at less cost. Web services are thenext-generation component model for distributedcomputing and a natural extension of integrationtechnology. The promise of Web services is theability to enable services to freely communicateover the public network, as well as create aservice-oriented approach to computing.

Web services are used for deploying, providing,and orchestrating access to business functionsover the Web. Web services are built on existingtechnologies, such as XML, so they can beimplemented easily and incrementally. Yet theefficiencies they are capable of bringing aboutcould dramatically change the way e-Businessis conducted.

In contemplating the adoption of Web services,it is important to remember that whenever acompany seeks to provide services and goodsusing Internet technologies, it can find itselfinvolved in large integration projects that lead tobusiness, technical, and political challenges. Notsurprisingly, when such projects fail, the conse-quences are disastrous. Therefore, Web servicesand successful integration go hand in hand.

Origins in ComponentArchitectureThe historical trend that has led us towards Webservices has its roots in component architectureof the 1980s. Components were originally devel-oped in the context of graphical user interfaces(GUIs) and allow the re-use of existing applica-tion code. Within this architecture, code is com-piled into several independent units instead ofinto a single entity. These units or componentscommunicate via an infrastructure provided bythe operating system.

But component architecture allowed developersto do even more than simply build GUIs. Soonits use grew from managing communicationbetween components on the same computer tocommunicating with component infrastructureson other computers across a network. Dis-tributed component architectures enabled therapid development of complex, distributed appli-cations. This led to the specification of CORBA

(the Common Object Request Broker Architec-ture) in 1991 and Microsoft DCOM componentarchitecture, as well as the development of theSun J2EE distributed architecture.

Distributed component architectures have oneserious limitation: generally they can only beused across a tightly managed network, such asa corporate intranet. They do not play well in anopen, fragile environment, such as the publicInternet. Hence the need for Web services in anInternet world. In the same way that componentmiddleware allows one piece of software tomake use of the functionality contained inanother piece of software on another computer,Web services use the Internet’s protocols to pro-vide a component infrastructure for the develop-ment of distributed components that function onthe public net. Web services are modular appli-cations that can be described, published, located,and invoked over a network through standard-ized XML messaging. They are defined by newstandards – like Simple Object Access Protocol(SOAP), Web Services Description Language(WSDL), and Universal Discovery Descriptionand Integration (UDDI). Web services offer anew model for creating e-Business applicationsfrom reusable software modules that areaccessed on the Web.

Benefits of Web ServicesFrom a technical standpoint, Web services offeran easier way to develop applications that needto be accessed over the Web. It is important tonote that Web services do not solve all integra-tion requirements, only the ability to communi-cate with other software modules over the publicnet. Additional integration technologies are stillneeded to handle integration between data,applications, and business processes. Alsoneeded are the enterprise-class capabilities tosurround the Web services, enabling them tobe secure and scalable.

From a business standpoint, Web services allowa company to concentrate development effortson computing assets that drive revenue. Businessmodels and relationships are evolved as neces-sary, the costs of integration reduced, interac-tions with marketplaces established more effi-ciently, and business functions delivered to abroader set of customers and partners. Web ser-vices technology enables the outsourcing of ser-vices that provide no business benefit. BecauseWeb services decouple applications and infra-

Web Services – An Evolution of theDistributed Computing ModelT R O N S Y V E R S E N

Tron Syversen (30) works assales executive and specialiston mobile solutions for iAny-where Solutions, a subsidiary ofSybase Inc. His job consists ofsales, promotion and marketingof mobile solutions. ThroughiAnywhere Solutions, Sybaseoffers customers and partnersa complete product portfolio ofmobile software. Tron likes towork with tailored solutionsbased on mobile databasesand synchronization technology.He has a technical backgroundand has been working with intro-ducing Sybase mobile technol-ogy on the Nordic market forthe last three years.

[email protected]

Telektronikk 4.2002


structure, a company can quickly compose anddeploy solutions based on reusable componentsfrom the lowest-cost provider, whether internalor external. These solutions can change thetarget, and even the nature of interactions, inresponse to changing business conditions. Orga-nizations can leverage a flexible and dynamicbusiness model, which maximizes their reach tocustomers, partners, suppliers, and marketplaceswhile minimizing their costs and time to market.

Sybase’s Solution for WebServicesOver the last 18 years, Sybase has been deliver-ing enterprise-class infrastructure softwareaimed at helping customers with their distributedcomputing needs. This software, which couplesintegration with distributed computing, isSybase’s heritage. We were the first vendor tointroduce a database for distributed computing,the first to release replication and distributeddata access in a heterogeneous environment, thefirst to handle both Java and COM componentsas well as to adopt J2EE technology, and thefirst to bridge mobile users with the enterprise.

Most recently, we extended the integration capa-bilities of most of our software infrastructure toinclude the developing, accessing, providing,and orchestrating of Web services. From withinthis infrastructure, customers can expose exist-ing software components from multiple vendors’technologies and have the unique advantage ofbeing able to quickly adapt to Web services.This is accomplished in two ways. First, SybaseWeb services can expose a wide variety of exist-ing software components, including Java, EJBs,database stored procedures, CICS components,and mobile wireless services.

Second, we help customers adapt to Web ser-vices by providing a solution that lets them adaptWeb services incrementally; that is, when appro-

priate and at different times. In the evolution ofdistributed computing, it will be many years be-fore Web services are mainstream, so their fulladoption will occur in a number of steps. Forexample, a company may itself adapt Web ser-vices but its partners and suppliers – as well asdifferent divisions within that company – willproceed on a different schedule. In such cases,Sybase Web services can bridge heterogeneoustechnologies at a logical level and act as a cen-tral control above the other services. We can alsoact as a hosted service, allowing customers toconnect quickly to their partners using the tech-nology of choice and eliminating the need toinstall and maintain multiple gateways and con-nectivity software.

Sybase is providing a comprehensive portfolioof open-integration for Web services and deliv-ering them in four ways:

• Development of Web services – software thatsupports the development and automation ofWeb services

• Providing Web services – software that hoststhe Web services

• Accessing Web services – software that con-nects to a service and delivers the value of thatservice to its intended user(s)

• Orchestrating Web services – a set of softwareservices that are designed to help coordinatethe activities of services while they are beingused.

An example of a Sybase enabled Web servicesproduct is our Enterprise Application Server(EAServer) version 4.1. EAServer supports theopen standards and technologies necessary todevelop, publish, and provide Web services-based applications, including UDDI, SOAP,J2EE, WSDL, and the ability to interface witha public UDDI registry.

Mobile Web ServicesAs a part of Sybase’s comprehensive Web ser-vices strategy iAnywhere Solutions, a subsidiaryof Sybase INC, will enable delivery of Web ser-vices to mobile and wireless users. This includesan integrated software platform for extendingthe reach of e-Business applications, messages,enterprise data, and Internet content to mobileand wireless devices, including smartphones,PDAs and laptops. By exposing this functional-ity as Web services, other applications andservers can easily tap into this platform to lever-age mobile-specific features. For example, anapplication can access a Web service running ona middleware platform to send an SMS messageto a user’s phone.

Integrate

Integrate

UDDI, WSDL, SOAP

Provide

Orchestrate

Access

Develop

Java

EJB

.NET

C++

NVO

CICSStored ProceduresApplicationsMobile MessagingServicesVertical ComponentApplications (EBA)


ConclusionSybase believes that the next generation ofe-Business will be “services-oriented” becauseof the increasing need to decouple applicationsand infrastructure for the rapid construction anddeployment of flexible solutions. Standards-based Web services – teamed with integrationtechnology – open the door to more effectiveand efficient e-Business. These services supportmassive automation and integration of applica-tions and business processes, allow rapid accel-eration of the e-Business innovation-integrationcycle, and reduce infrastructure costs and com-plexity. The underlying technology is still evolv-ing, but through the efforts of Sybase and others,companies will be able to adapt to Web servicesquickly, achieving business value today andbeing well positioned for tomorrow. To encour-age standards that will make Web services amore valuable part of the Internet, Sybase is nowworking through two major organizations: theWeb services Interoperability (WSI) Organiza-tion and OASIS (Organization for the Advance-ment of Structured Information Standards).

Company profile

Sybase is a leading provider of enterprise software products and services, includ-

ing enterprise portals, vertical solutions and mobile technologies. Such products

and services enable companies to build robust e-business infrastructures for inte-

grating, managing, and delivering information anywhere it is needed. With nearly

5,350 employees and 2000 revenues of $960.5 million, Sybase is one of the

largest independent software companies in the world. Today Sybase’s end-to-end

solutions are defining the requirements for enterprise solutions, Web computing

and Mobile computing. These solutions currently focus on four principal vertical

markets: financial services, telecommunications/media, healthcare, and the

government/public sector.

Sybase’s headquarters are located in Dublin, California, and operates in over

60 countries. The company’s stock is traded on the NYSE under the symbol SY.

iAnywhere Solutions, a subsidiary of Sybase, Inc., is the market-leading provider of

mobile and wireless solutions that enable anywhere, anytime access to enterprise

information. More than 6 million users at 10,000 customers sites worldwide rely

on iAnywhere Solutions to power solutions that help to improve productivity,

streamline operations and create new revenue streams. With more than a decade

of experience, iAnywhere Solutions provides a one-stop source for organizations’

m-business needs across key markets including financial services, healthcare,

government, utilities, transportation and retail.

Telektronikk 4.2002

1 IntroductionThis paper explains Web service development ingeneric terms – without discussing implementa-tion details on different platforms. The first partfocuses on the process of developing a Webservice, while the second part concerns clientdevelopment. Finally we list useful sources of in-formation in regard to Web service development.

2 How A Web Service Is MadeThis chapter tries to explain the generic processof creating a Web service, regardless of plat-forms and other implementation details. Itassumes the following definition of a Webservice:

A Web service is application logic that ismade available on the Internet using thefollowing standards: XML for data descrip-tion, SOAP for message wrapping, WSDL forservice description and UDDI for servicediscovery.

We describe two scenarios for developing Webservices: Starting from scratch or starting withan existing service.

2.1 Developing a Web Service fromScratch

Starting from scratch means creating all thefunctionality in a service from the bottom up,before exposing the desired functionality toWeb service clients. The process is as follows:

1 Create service functionality2 Generate Web service interface3 Deploy service4 Publish service

2.1.1 Create Service FunctionalityThe service logic must be developed accordingto the goals of providing the service. The plat-form and internal workings of the service are

irrelevant in a Web service perspective, sinceWeb services depend on the model shown inFigure 1.

In this way Web services allow for cross-plat-form interoperability in a way that makes theplatform irrelevant. Internally the service mayconnect to a database, an Enterprise Java Bean,a COM object, a legacy application, etc., buttowards the Web service client all communica-tion will be done using higher level, universalprotocols. This is the same principle that allowsa Web browser and a Web server to be imple-mented with completely different technologiesbut still communicate without problems usingthe common, universal standards HTTP andHTML.

Once the functionality is in place, the next stepis to expose it as one or more Web services.

2.1.2 Generate Web Service InterfaceThe functionality created in the first step needsto be given a Web service interface in order tobe a Web service. The tool the programmer isusing should implement the Web service layerautomatically if the developer specifies whatfunctionality to expose as a Web service. Butwhat does it mean that the tool generates a Webservices interface? There are two steps involvedin exposing functionality as Web services:

a) Create SOAP interfaceb)Create WSDL service description

2.1.2.1 Create SOAP Interface: the WebService Proxy

For a Web service to be called by remote clients,a service listener and a service proxy need to bein place, as shown in Figure 2. This will all betaken care of by the tools/platform you choose tobuild your Web services on, but it is still impor-tant to have a general idea of what is going on.

Web Service Development ExplainedA N N E M A R I E H A R T V I G S E N , L U I S A R T U R O F L O R E SA N D D O V A N T H A N H

Luis Arturo Flores (24) obtainedthe Computer Systems Engin-eering degree with Honors dis-tinction from the Monterrey Tech(ITESM) in Mexico, complement-ing his studies with universityprograms in the University ofMelbourne, Australia; and theWashington College at Mary-land, USA, where he is a mem-ber of the Honor Society. In2002–2001 he participated inInformation Systems projects inMexico and the United Statesbefore joining Telenor R&D inJune, 2001. At Telenor he per-formed research focused on theSession Initiation Protocol andXML Web Services, togetherwith Dr. Prof. Do Van Thanh.

[email protected]

Anne Marie Hartvigsen (25)finalised her Master in Informa-tion Systems at Agder Univer-sity College in June 2002, withthe thesis “Studying EmergingTechnologies in Telenor –Using Web Services to ProvideUniversally Accessible UserProfiles”. She also holds aCand.Mag. in social sciencesfrom the Norwegian Universityof Technology and Science(NTNU). Formerly a visitingresearcher at Telenor R&D,working in the PANDA (Per-sonal Area Network and DataApplications) research group,she is now employed as a sys-tems developer at the Telenorspin-off Xymphonic Systems.

[email protected]

This paper explains in generic terms how Web Services and Web Service clients are developed.

Figure 1 Web Services abstract implementation details

ApplicationCode

WebService

ServiceClient

Platform andlanguage specificcommunication

Platform andlanguage agnostic

communication

30

31

The service listener receives incoming SOAPrequests, which the service proxy parses andinterprets, and decodes into calls to invoke theapplication code created in the first step. Thisproxy must understand how to handle all thingsthat can occur in a SOAP request. When it re-ceives a request from the listener it performsthree steps:

1 Deserialise the message from XML into thenative format that the application coderequires;

2 Invoke the code;

3 Serialise the response to the message backinto XML and hand it back to the listener fordelivery back to the requester.

It is the proxy and the listener that are oftenreferred to as SOAP wrapping, meaning thatthey provide an abstract layer between the ser-vice implementation and the calling client.Because this is merely a standardised way ofwrapping existing functionality, it is quitestraightforward to add, and Web services toolswill do it automatically. There already existSOAP toolkits for all the popular programminglanguages and environments (see http://www.soaplite.com or http://www.soapware.org fordetailed product listings). The proxy componentneeds to know exactly which code to invokewhen a particular message is handed to it, anddifferent Web service tools have different mech-anisms for doing this.

SOAP is an infrastructure technology, and oncethis interface is generated, SOAP works “behindthe scenes” to make sure the service and a clientmay interoperate. Ideally the SOAP componentsare completely transparent to the applicationcode, so that the code does not even know it isbeing invoked through a Web service.

2.1.2.2 Create WSDL Service Description:the WSDL File

Once the SOAP wrapping is in place, it is possi-ble for clients to issue SOAP requests to the ser-vice and receive SOAP responses back. But theclient is not able to send requests or handle theresponses if it does not know what kind of

requests the service accepts, or what kind ofresponses it can expect to get back. This infor-mation is provided in the service’s WSDL file.

The WSDL file defines the Web service in termsof its logical and physical interface.

• A service consists of one or more ports.

• Each port is on the one hand bound to a spe-cific URI, and on the other hand to what iscalled a binding.

• A binding is a combination between an opera-tion (method signature) that can be invokedand a specific protocol that can be used toinvoke it (e.g. SOAP).

• Each operation is composed of messages,which again consist of parts (data values) thathave their own names (e.g. strUserID) andpart types (e.g. string). The part types (datatypes) are defined using XML Schema.

• Operations are grouped together in logicalport types.

The separation between logical elements – porttypes, operations, messages – and physical ele-ments – data types, protocols, URIs – makes iteasy to for example offer the same service onseveral different protocols (e.g. SOAP, HTTPGET, HTTP POST) and/or from several differ-ent locations (URIs).

As with the SOAP proxy, the WSDL file is cre-ated automatically, since it merely provides aformal description of an already existing service.This description is expressed in an XML docu-ment that adheres to the WSDL protocol fordefining services. This makes it possible forother applications to read the WSDL file pro-grammatically, and to generate client proxiesfor the Web service automatically.

2.1.3 Deploy the Web ServiceThe Web service must run in an environmentthat allows clients to access it. Usually thismeans deploying the service to a Web applica-tion server.

Do Van Thanh (44) obtained hisMSc in Electronic and ComputerSciences from the NorwegianUniv. of Science and Technology(NTNU) in 1984 and his PhD inInformatics from the Universityof Oslo in 1997. In 1991 hejoined Ericsson R&D Depart-ment in Oslo after 7 years ofR&D at Norsk Data, a minicom-puter manufacturer in Oslo. In2000 he joined Telenor R&D andis now in charge of PANDA (Per-sonal Area Network & DataApplications) research activitieswith a focus on SIP, XML andnext generation mobile applica-tions. He also holds a professorposition at the Department ofTelematics at NTNU in Trond-heim. He is author of numerouspublications and inventer of adozen patents.

[email protected]

ApplicationCode

ServiceProxy

ServiceListener

Web application server

ApplicationInvocation

XMLRequest

XMLRequest

Figure 2 Generic Web Services architecture

Telektronikk 4.2002


Once the Web service layer is implemented anddeployed, all that remains to be done is publish-ing the service so that clients may find it.

2.1.4 Publish the Web ServiceThe last step in creating a Web service is pub-lishing it to the UDDI business registry. It is ofcourse possible to have Web services that are notregistered in UDDI, but that assume that suitableclients get to know about the service in otherways. The purpose of registering the service inthe UDDI registry is to allow potential users ofthe service to find it based on its functionality.

Example: A developer is creating a Web site thatrequires users to be authenticated. Instead ofprogramming this functionality herself, thedeveloper can search the UDDI registry for Webservices providing this functionality. There thedeveloper may find several authentication ser-vices, e.g. Microsoft’s Passport service. Otherinformation also resides there, such as informa-tion about the company offering the service, andthe terms for using the service (the serviceprovider can for example require that the clientpays per use, or an annual fee, or nothing at all;there may be restrictions of how many times perday the service can be invoked, etc.). By study-ing the information, an appropriate service canbe chosen, and integrated in the Web site solu-tion with the help of the service’s WSDL file. Ifafter some time the developer does not want touse the selected service anymore, it should beeasy to find an equivalent service (presumingone exists) in the UDDI registry and switch tothat instead.

UDDI is a technical specification for building adistributed directory of businesses and Web ser-vices. The data model is an XML Schema fordescribing businesses and Web services. UDDIalso includes SOAP API details for searchingexisting data and publishing new data.

The UDDI Business Registry (cloud services) isan implementation of the specification, accessi-ble through the different UDDI Business Reg-istry Nodes (UBR Nodes). Businesses can regis-

ter themselves and their services at these nodes.They each offer two interfaces. One is a Webpage, which can be accessed with a regular Webbrowser. The other is UDDI’s publishing APIwhere different save and delete functions can beused by SOAP messages. This can be useful ifyou want to use software that automatically reg-isters new Web services or if, e.g., you need anautomatic method for updating binding accessURLs.

As illustrated in Figure 3, there are other UDDIimplementations in addition to the UBR. Theseimplementations allow you to publish to yourown private registry, which can be shared withina company or among partners.

If you are developing Web services for internaluse they should of course not be published inthe UBR. You should however register your ser-vices somehow, in order to make efficient use ofthem. One possible way is to publish them inyour own, private UDDI registry.

2.2 Developing a Web Service froman Existing Service

Building a Web service from an existing servicemeans that the functionality already exists, butthere is no Web service interface to it. Except forthe first step the process is the same as for build-ing a Web service from scratch:

1 Build interface to the service2 Generate Web service interface3 Deploy service4 Publish service

2.2.1 Build Interface to the ServiceWeb services are most useful when they are usedto expose existing functionality. Whether Webservices are used to tie internal systems togetheror to expose services to external actors, Webservices should provide a fast and easy way toaccomplish this. Using Web services also meansthat once the interface is in place it can beaccessed from applications on any platform,meaning that only one interface is needed. Thebottom line is that existing functionality rela-tively easy can get added value, leveraging priorinvestments.

If the functionality already exists on a platformfrom which one wants to offer Web services,then all that is needed is to generate the Web ser-vice interface in the same way as for building aservice from scratch. If it is not possible or desir-able to generate the Web service interface fromthis platform, the developer must first interfacethe functionality with the desired Web serviceplatform, and then generate the Web serviceinterface on that platform. The resulting archi-tecture is shown in Figure 4.

Figure 3 UDDI specificationand implementations

UDDI TechnicalSpecification

Implementations

UDDI BusinessRegistry

UDDI PrivateRegistries

Specification


There are generally two reasons why one wouldwant to generate the Web service interface onanother platform

• It is not possible to generate a Web serviceinterface directly from the existing solution/platform;

• The current platform lacks desired functionality.

One example of the first case may be providingShort Message Service (SMS) as a Web service.This task first requires that a gateway be builtbetween the SMS centre and the desired Webservice platform (e.g. .NET or a J2EE platform).Next the Web service interface can be generated.Laird (2001) describes a project that developedan SMS Web service and also explains why thiskind of functionality is particularly suitable tooffer as a Web service.

An example of the second case is when onehas an application running in Perl. By usingSOAP::Lite for Perl one can easily offer thedesired functionality as Web services, sinceSOAP::Lite supports SOAP, WSDL and UDDI.However, SOAP::Lite is a very simple tool –aimed at solving the problem from a program-mer’s view point. It might be that more featuresare needed than what is offered by SOAP::Lite,for example if one wants to tie together multipleWeb services – then a more complex implemen-tation, like Apache Axis, might provide a betterplatform. Or let us say one wants to expose theservice with the aim of selling it to potentialusers. Then one needs to do things like keeptrack of who is using one’s service so one cancharge them, and there might be other businessaspects to the Web service initiative. Maybethere is already an e-business server running thattakes care of some business aspects and inte-grates Web services with that – then one wouldprobably want to offer one’s service from that.

When building the bridge between one’s serviceand the chosen Web service platform, there is noformula for how this should be done. It dependson the systems at hand, available tools and skills,and the trade-off between performance versusflexibility and development costs. Depending onall these factors one could either build some pro-prietary interface oneself or use technologieslike COM, CORBA, Java RMI, etc. One couldeven end up using Web services to tie the twoplatforms together!

2.2.2 Generate Web Service Interface,Deploy and Publish the Service

These steps are the same whether starting withan existing service or building the service fromscratch. See the chapter on building Web ser-vices from scratch.

3 How A Web Service Clientis Made: Web ServiceConsumption

This chapter aims to explain the generic processof consuming an existing Web service, regard-less of platforms and other implementationdetails. The process involves four steps:

1 Find service2 Generate client proxy3 Invoke service

3.1.1 Discover the Web ServiceThere are many ways to obtain informationabout a Web service that one wants to use. Typi-cally if using Web services to tie together inter-nal systems or to do e-business with trusted part-ners one would be given descriptions and speci-fications for the specific services to use. How-ever, if looking for some functionality and want-ing to see if there is a Web service for this, theappropriate place to search for it, according toWeb service standards, is a UDDI registry.Some companies may use UDDI implementa-tions to keep private service registries. TheUDDI Business Registry (cloud services) isanother implementation of the specification,accessible through the different UDDI BusinessRegistry Nodes (UBR Nodes). This is the placeto search for public services, enabling anyone tosearch existing UDDI data. These data aredivided into three categories:

• White Pages – general information about com-panies;

• Yellow Pages – general classification data forcompanies and services;

• Green Pages – technical information aboutWeb services (using the term in its broadestsense, including everything from Web pagesand e-mail addresses up to SOAP, CORBA,Java RMI services, etc.).

Although some technical information about aWeb service can be found in the registry, it willmostly also contain a link to a WSDL file and

Figure 4 Web Servicebuilt from existing service

on another platform

ApplicationCode

WebService

ServiceClient


Platform andlanguage agnostic

communication

ExistingService



possibly other service descriptions located at theservice provider.

Searching of the UDDI registry can be done byaccessing a UBR Node. They each offer twointerfaces. One is a Web page, which can beaccessed with a regular Web browser. The otheris UDDI’s inquiry API where different find andget functions can be requested using SOAP mes-sages. Such requests could either be sent directlyor a UDDI tool could be used.

3.1.2 Generate a Client ProxyOnce the desired service and the WSDL file thatbelongs to it have been located, your develop-ment tool should be able to generate a clientproxy based on the WSDL file. When callingWeb service methods in one’s application, it isactually the methods in this proxy that are beingcalled. The proxy then generates suitable SOAPrequests that it uses to invoke the service. Resultsfrom the requests are received by the proxy,which deserialises the XML and returns theanswer to the relevant application on an appro-priate format. Conceptually this is the same asfor the server proxy, and this is shown in Figure 5.

3.1.3 Invoke Service: Sending andReceiving SOAP Messages

To invoke the Web service all that has to bedone is make calls to the proxy class, and thiswill forward the call as a SOAP request to theWeb service. The answer returned will be han-dled by the client proxy, and handed over to theapplication code in native format.

4 SummaryRecalling all that has been mentioned in thischapter, we provided one approach that we con-sider simple, yet effective for developing a Webservice from scratch. To do so, we suggestedgoing by the following process:

1 Create service functionality. This includeswriting the code of the components that willconstitute the application, including the func-tions that will be available through the service.

2 Generate Web service interface. This step isgenerally performed by the developing tools,so one should not worry about carrying outthis step, but just to test whether the tools areactually doing it correctly one can e.g. checkthat a WSDL file has been created for the ser-vice and that the details in the WSDL descrip-tion seem correct.

3 Deploy service. To deploy the service meansto make it available on one’s Web server,where service clients can access it. Dependingon the development tools and the platformused, the deployment will be performedaccording to these. But basically, a proxyclass that speaks SOAP and a WSDL filedescribing the interface of this class must bemade available. This allows clients to refer-ence the service and test if the actual serviceitself is reachable by them.

4 Publish service. Finally we talked about pub-lishing the service at the UDDI business reg-istry. This is the registry for businesses world-wide to list themselves and their services onthe Internet. Of course this is only necessaryif one wants the service to be available world-wide. If the purpose of the project is to createservices for the internal use of the company, itmay not be necessary to register the servicehere. But somehow the network address of theWSDL file has to be provided to the clients, orthe interested developers of your company.One can even have one’s own internal“myUDDI” registry, for benefit of the com-pany’s developers.

We also presented a brief description of whatneeds to be done to create a Web service from anexisting service. This process is very similar tothe previous one, except that on the first step,instead of building the service itself, only theinterface has to be created. That is, generate thenecessary functions or processes that can becalled and that link the entering calls with theimplemented functionality of the service. So, inthis case, the functions themselves will work asan intermediary between the Web interface, and

Figure 5 Web Servicearchitecture – server and client

ApplicationCode

ServiceProxy

ServiceListener

Web application server

ApplicationInvocation

XMLRequest

XMLRequest

ClientProxy

MethodCallWeb Service Provider

Web ServiceClient

ApplicationCode


the existing functionality. Steps two, three, andfour are just the same as when building a servicefrom scratch.

Finally, we explained how to consume an exist-ing Web service. The following steps constitutedthe approach we introduced:

1 Find service. This means finding the desiredservice to complement our application. Wecan search the UDDI registry, or by othermeans find the description of the service func-tionality and the network address of theWSDL file.

2 Generate client proxy. By means of the devel-opment environment, the service found in stepone needs to be referenced. The developmenttool must be able to understand the WSDL filein order to be able to generate the necessaryinvoking method to the developer. This iscalled a proxy class because it is a class thatacts as an intermediary between the clientapplication and the Web service.

3 Invoke service. Finally, it is just a matter ofcalling the service. To do so, call the proxyclass, and it will forward the call as a SOAPrequest to the Web service, and obtain theanswer returned from the service.

5 ResourcesIn the following we list some resources that maybe useful when developing Web services andclients.

5.1 SOAPSOAP 1.1: http://www.w3.org/TR/SOAP/SOAP 1.2: http://www.w3.org/TR/soap12-part1/

ImplementationsOverview: http://www.soapware.org/directory/4/implementations

Apache Axis: http://xml.apache.org/axis/

Microsoft SOAP ToolKit 3.0:http://msdn.microsoft.com/soap

SOAP::Lite for Perl: http://soaplite.com

Glue from the Mind Electric: http://www.themindelectric.com/glue/

5.2 WSDLWSDL 1.1: http://www.w3.org/TR/wsdl

WSDL 1.2: http://www.w3.org/TR/2002/WD-wsdl12-20020709/

WSDL validator: http://pocketsoap.com/wsdl/

Invocation ToolsGlue from the Mind Electric: http://www.themindelectric.com/glue/

SOAP::Lite for Perl: http://soaplite.com

IBM Web Services Invocation Framework/WSIF): http://www.alphaworks.ibm.com/tech/wsif

5.3 UDDIUDDI Business Registry Nodes (Operators)• Microsoft: http://uddi.microsoft.com/• IBM: http://uddi.ibm.com/• SAP: http://uddi.sap.com/

Inquiry and Publish Interfaces• Microsoft

- http://uddi.microsoft.com/inquire- https://uddi.microsoft.com/publish

• IBM- http://uddi.ibm.com/ubr/inquiryapi- https://uddi.ibm.com/ubr/publishapi

• SAP- http://uddi.sap.com/uddi/api/inquiry- https://uddi.sap.com/uddi/api/publish

Tools• UDDI4J (UDDI for Java) – a tool for using

the UDDI APIs: http://oss.software.ibm.com/developerworks/projects/uddi4j/

• jUDDI: http://www.juddi.org/

• SOAP::Lite: http://soaplite.com/

• Microsfot UDDI Software Development Kit:http://uddi.microsoft.com/developer/

Information• The official UDDI site: http://www.uddi.org

• UDDI technical newsgroup:http://groups.yahoo.com/group/uddi-technical/

• UDDI information and news: http://uddicentral.com/

5.4 Other Information and ResourcesW3C Web Services Activity:http://www.w3.org/2002/ws/

The IBM Web Services Browser:http://demo.alphaworks.ibm.com/browser/


6 SourcesThe information in this paper was extracted fromthe following sources:

Cauldwell, P et al. 2001. Professional XML WebServices. Birmingham, UK, Wrox Press Ltd.

Cerami, E. 2002. Web Services Essentials. CA,USA, O’Reilly.

Graham, S et al. 2002. Building Web Serviceswith Java : Making Sense of XML, SOAP,WSDL, and UDDI. Indiana, USA, Sams Publish-ing.

Laird, C. 2001. SMS : Case study of a Web ser-vices deployment. “Instant gratification” pro-gramming results. July 25, 2002 [online] – URL:http://www-106.ibm.com/developerworks/webservices/library/ws-sms.html

Snell, J, Tidwell, D, Kulchenko, P. 2002.Building Web Services with SOAP. CA, USAO’Reilly.

Vasudevan, V. 2001. A Web Services Primer.O’Reilly XML.com. July 22, 2002 [online] –URL: http://www.xml.com/pub/a/2001/04/04/webservices/index.html

37

1 IntroductionThis article presents an investigation of the majorXML Web Services products that are availableon the market and an overview of the Web Ser-vice arena with the dominant players. The articlewill also consider briefly the Telco services rele-vant to be exposed as XML Web Services.

The term Web Services describes a standardizedway of integrating Web-based applications usingthe XML, SOAP, WSDL and UDDI open stan-dards over an Internet protocol backbone. XML isused to tag the data, SOAP is used to transfer thedata, WSDL is used for describing the servicesavailable and UDDI is used for listing what ser-vices are available. Used primarily as a means forbusinesses to communicate with each other andwith clients, Web services allow organizations tocommunicate data without intimate knowledge ofeach other’s IT systems behind the firewall.

When it comes to Web Service products we seethat most of the vendors either base their prod-ucts on Java platforms or Microsoft platforms.Due to the Web Service standardization differentproducts will ideally be able to interoperatewhen needed.

2 PlatformsTo develop and run a commercial Web Service itis convenient to differentiate between four typesof platforms needed:

• Provider platform – the environment that doesthe hosting of a Web Service, for example anapplication server.

• Consumer platform – the environment wherethe consumer or client connects to a Web Ser-vice, for example a user interface that auto-matically accesses the remote Web Service.

• Production platform – the environment whereautomation of developing Web Services isprovided. Support for the Web Services stan-dards must be provided.

• Management platform – the environment thatcoordinates the usage of Web Services, forexample providing QoS, delivery guarantees,security management, trading relationshipsmanagement, etc.

A Web Service product that covers all these plat-forms may be regarded as complete.

The vendors have so far put a lot of emphasisinto the first three platforms, but they have notgot that far in the management platform area.

2.1 Provider/Consumer PlatformA Web Service will always consist of a providerand a consumer platform representing corre-spondingly the server application side and theclient application side of the service. In mostcases those two platforms are based on existingapplication servers of which there are mainlytwo different types, those based on Java 2 Enter-prise Edition (J2EE) or those based on Microsoft.NET.

2.1.1 J2EEThe J2EE platform uses a multi-tiered dis-tributed application model. Application logic isdivided into components according to functions.The various application components that makeup a J2EE application are installed on differentmachines depending on the tier in the multi-tiered J2EE environment to which the applica-tion component belongs. Figure 1 shows twomulti-tiered J2EE applications divided into thetiers described in the following list:

• Client-tier components run on the clientmachine;

• Web-tier components run on the J2EE server;

• Business-tier components run on the J2EEserver;

• Enterprise information system (EIS) tier soft-ware run on the EIS server.

Major Web Service Products and Relationsto Mobile Telco ServicesE R I K L I L L E V O L D A N D D O V A N T H A N H

Do Van Thanh (44) obtained hisMSc in Electronic and ComputerSciences from the NorwegianUniv. of Science and Technology(NTNU) in 1984 and his PhD inInformatics from the Universityof Oslo in 1997. In 1991 hejoined Ericsson R&D Depart-ment in Oslo after 7 years ofR&D at Norsk Data, a minicom-puter manufacturer in Oslo. In2000 he joined Telenor R&D andis now in charge of PANDA (Per-sonal Area Network & DataApplications) research activitieswith a focus on SIP, XML andnext generation mobile applica-tions. He also holds a professorposition at the Department ofTelematics at NTNU in Trond-heim. He is author of numerouspublications and inventer of adozen [email protected]

Erik Lillevold (60) obtained hisMSc in Physics from the Norwe-gian University of Science andTechnology (NTNU) in 1970 andjoined the Norwegian DefenseResearch Institute (NDRE) in1971. He worked there as aresearch scientist until 1986when he joined Telenor R&D.He has most of his time workedin the field of messaging andapplication services, e.g. X.400,Internet Mail, WWW and WAP.In the last few years he hasdevoted his work to Open Ser-vice Platforms (Parlay, OSA,Web Services, etc.).

[email protected]

Data-base

Data-base

EnterpriseBeans

EnterpriseBeans

JSPPages

ApplicationClient

DynamicNTMLPages

ClientTier

WebTier

BusinessTier

EISTier

ClientMachine

J2EEServerMachine

DatabaseServerMachine

J2EEApplication 1

J2EEApplication 2

Figure 1 The J2EE platform

Telektronikk 4.2002


J2EE components are written in the Java pro-gramming language and are compiled in thesame way as any program in the language. Thedifference between J2EE components and “stan-dard” Java classes is that J2EE components areassembled into a J2EE application, verified tobe well formed and in compliance with the J2EEspecification, and deployed to production, wherethey are run and managed by the J2EE server.The J2EE specification defines the followingJ2EE components:

• Application clients and applets (dynamicHTML pages) are components that run on theclient machine.

• Java Servlet and JavaServer Pages (JSP) tech-nology components are Web components thatrun on the J2EE server machine.

• Enterprise JavaBeans (EJB) components(enterprise beans) are business componentsthat run on the J2EE server machine.

A J2EE client can be a Web client or an applica-tion client. A Web client consists of two parts:dynamic Web pages containing various types ofmark-up language (HTML, XML, and so on),which are generated by Web components run-ning in the Web tier, and a Web browser, whichrenders the pages received from the server. AJ2EE application client runs on a client machineand provides a way for users to handle tasks thatrequire a richer user interface than can be pro-vided by a mark-up language.

A Web page received from the Web tier caninclude an embedded applet. An applet is a smallclient application written in the Java program-ming language that executes in the Java virtualmachine installed in the Web browser.

The server and client tiers might also includecomponents based on the JavaBeans componentarchitecture to manage the data flow between anapplication client or applet and components run-ning on the J2EE server or between server com-ponents and a database.

The enterprise information system tier handlesenterprise information system software andincludes enterprise infrastructure systems suchas enterprise resource planning (ERP), main-frame transaction processing, database systems,and other legacy information systems.

2.1.2 The .NET PlatformThe .NET Framework is a new Microsoft com-puting platform that simplifies application devel-opment in the highly distributed environment ofthe Internet.

The .NET Framework has two main compo-nents: the common language runtime and the.NET Framework class library. The commonlanguage runtime is the foundation of the .NETFramework. You can think of the runtime as anagent that manages code at execution time, pro-viding core services that manage memory,threads, remote access, security and robustness.In fact, the concept of code management is afundamental principle of the runtime. Code thattargets the runtime is known as managed code,while code that does not target the runtime isknown as unmanaged code. The class library,the other main component of the .NET Frame-work, is a comprehensive, object-oriented col-lection of reusable types that can be used todevelop applications ranging from traditionalcommand-line or graphical user interface (GUI)applications to applications based on the latestinnovations provided by XML Web services.

Figure 2 shows the relationship of the commonlanguage runtime and the class library to yourapplications and to the overall system. The illus-tration also shows how managed code operateswithin a larger architecture.

For example, ASP.NET hosts the runtime to pro-vide a scalable, server-side environment formanaged code. ASP.NET, including IIS (Inter-net Information Service), is a set of technologiesin the Microsoft .NET Framework for buildingWeb applications and XML Web Services.ASP.NET pages execute on the server and gen-erate mark-up such as HTML, WML or XMLthat is sent to a desktop or mobile browser.

Custom objectlibraries

Unmanaged applications

Managed applications

Classlibrary

Run-time

Operating system/Hardware

Managed Webapplications

ASP.NET(Runtime)

InternetInformation

Services

Unmanagedapplications

Figure 2 The .NETplatform architecture


ASP.NET works directly with the runtime toenable XML Web services for example.

The .NET Framework can be hosted by unman-aged components that load the common lan-guage runtime into their processes and initiatethe execution of managed code, thereby creatinga software environment that can exploit bothmanaged and unmanaged features. The .NETFramework not only provides several runtimehosts, but also supports the development ofthird-party runtime hosts.

Figure 3 shows a basic .NET network with man-aged code running in different server environ-ments. Servers such as IIS and SQL Server canperform standard operations while your applica-tion logic executes through the managed code.

ASP.NET is the hosting environment thatenables developers to use the .NET Frameworkto target Web-based applications. However,ASP.NET is more than just a runtime host; it is acomplete architecture for developing Web sitesand Internet-distributed objects using managedcode. Both Web Forms and XML Web servicesuse IIS and ASP.NET as the publishing mecha-nism for applications, and both have a collectionof supporting classes in the .NET Framework.

2.2 Production PlatformWhen developing a Web Service the developermust start to create the service functionalityfrom scratch or use an existing service on theprovider platform. The application server usuallyhas tools that support service development.These or any other available tools can be used tomake the necessary source code for the serviceto run on the targeted provider platform.

Most of the production platforms seem to con-tain similar functions:

• From source code as input is then the WSDL(Web Service Description Language) fileproduced. At the same time a deploymentdescription is made and used to deploy thecode into the actual runtime platform.

• If the WSDL file is already available, as itoften is when the client side application iscreated, you could start from there instead.An existing WSDL file may also be used tocreate server-side code stubs of the WebService defined by it.

• WSDL is an XML file used to create more orless automatically the Web Service interface(server-side) that exchanges and convertsSOAP messages with XML code to invoke theserver application and respond to the clientapplication.

• The server-side code is deployed on theprovider platform using the deploymentdescription file.

• WSDL is also used to create the client appli-cation code stubs used to exchange SOAPmessages with the server.

• The client-side code is deployed on the con-sumer platform.

It should be noted that the client-side and theservice-side of the Web Service in theory couldbe produced by production platforms from dif-ferent vendors. In practice, however, interoper-ability between Web Service clients and serversfrom different vendors cannot be guaranteed.

3 Major Web Service ProductsSome of the most prestigious Web Service prod-ucts known today have lately been tested andevaluated by Telenor R&D to some extent.These are BEA WebLogic Server 7.0 withWorkshop, Apache Axis beta 3 Web ServiceEngine, Microsoft .NET and IBM WebSphere.The results of the findings are described in thefollowing.

3.1 BEA WebLogic Server 7.0 withWorkshop

In our context is the WebLogic Server 7.0 theprovider platform, while the Workshop is theproduction platform.

3.1.1 OverviewWebLogic Server (WLS) 7.0 is a fully J2EE-compliant application server, regarded as oneof the leaders in the application server spacebecause it has many Java-oriented features andis a reliable server. Even if SOAP and WSDLsupport is included in BEA WebLogic Server6.1, they are not sufficient in this version. Com-pared to WLS 6.1, WLS 7.0 with Workshopextends Web service functionality and fulfils theneed to integrate the developing environmentwith Web services support.

Workshop is the Web service creation and de-ployment tool for BEA’s WLS 7.0. It provides

Client

ASP.NET hostsWeb Forms applications

ASP.NET hostsXML Webservicesapplications

Windows.NETEnterpriseServer hosts theruntime andmanaged code

Figure 3 A basic .NET network


an integrated development framework thatallows developers to build Web services that caneasily be set up to interoperate with the existingresources and applications (EJBs, Java MessageService destinations, Java DataBase Connectiv-ity connections and other Web services).

While WLS 6.1 forced developers to build partof the infrastructure, BEA Workshop providesthis functionality for developers out of the boxas part of the standard Web services infrastruc-ture, encapsulating the complexities of the J2EEarchitecture. Workshop handles all the JavaNaming and Directory Interface (JNDI) code,API calls, resource management, and exceptionhandling, leaving the client with a simple inter-face for business logic calls. This allows applica-tion developers who are more business orientedthan programming oriented to take advantageof Web services technology. BEA WebLogicWorkshop includes two major components:

• A visual development environment that letsdevelopers design and implement Web ser-vices. It graphically illustrates the interfacewith other components.

• A runtime framework that provides the Webservices infrastructure, as well as testing,debugging and deployment environment forWeb services applications. It creates theXML, SOAP and WSDL interface togetherwith necessary components to implement theservice under the J2EE WebLogic platform,

which are EJBs, JDBC connections, etc, whilethe developer only worries about writing thestandard Java code

Figure 4 shows what Web services look like inBEA’s perspective.

3.1.2 ResultsWebLogic Server 7.0 with Workshop supportslarge-scale development and deployment ofXML Web services. The solution is totally inte-grated, which means that setting up and usingthe platform is relatively problem free.

WLS 7.0 and Workshop support SOAP 1.2,WSDL 1.1 and UDDI 2.0, and when it comes toSOAP messaging styles it supports both the RPCand document/literal styles. BEA claims Work-shop Web services to be fully interoperable with.NET Web services, both when using .NET as aresource and when serving .NET clients. Ourtests indicate that Workshop indeed offers trueinteroperability with both .NET and other J2EEservices.

WLS 7.0 and Workshop constitutes a reliable,integrated platform with full support for everyJ2EE standard and all Web service standards.Combined with BEA’s heavy attention to Webservices and a nice visual development environ-ment it is certainly a platform that should betaken into consideration when a reliable infra-structure for Web services is needed.

Figure 4 Web ServiceArchitecture in BEA WLS 7.0

UDDIregistry

Publish WebService (WSDL)

DownloadClient Jar

GenerateClient Jar

GenerateWSDL

WebLogic services implementation(SOAP, UDDI, WSDL)

Business layer

Client

Client JarWSDL

BEA WebLogic Server

Lookup Web Service

Invoke webservice (SOAP)


3.2 Apache Axis beta 3 Web Service Engine

Axis will together with a J2EE compatible appli-cation server support a provider platform, aclient platform and a production platform.

3.2.1 OverviewThe open-source, freeware Web services con-tainer offered by the Apache project is calledAxis (a complete re-architecture of ApacheSOAP), and stands for Apache Extensible Inter-action System. The first (alpha) version wasreleased less than a year ago, and the currentversion is 1.0 RC1 (candidate for 1.0 release).

Axis is a SOAP engine that acts as a client andserver of SOAP messages with primary focus onHTTP. It can be viewed as a thin layer sittingbetween the business logic and the networktransport. It runs as a Web application on topof an application server. It comes with a stand-alone server, but is most commonly used as aWeb application on top of Tomcat. In our evalu-ation, however, we use WLS 6.1 as the underly-ing platform.

Axis provides extensive support for WSDL, andwith Axis’ utilities one can generate WSDLfrom Java classes implementing the actual ser-vice. Starting with a WSDL an entire package ofclient-side proxy and server side skeleton classescan be built. Axis also includes a Java applica-tion called “tcp-mon” that allows you to monitorthe SOAP messages that are being sent to andfrom an Axis engine.

The Axis engine’s main job is to pass SOAPmessages through a set of handlers that examineand/or modify a SOAP message in order to com-plete its job. Figure 5 shows how the Axis en-gine works on the server-side, i.e. in the providerplatform, and Figure 6 illustrates how it workson the consumer platform when Axis is used torun a Web service client.

3.2.2 ResultsAlthough Axis is constantly evolving, at the timeof writing some limitations exist. First of all,with Axis one cannot consume or generate ser-vices that use unsigned XML schema types,something which might raise interoperability

Figure 5 Axis EngineServer Architecture

Request

MessageContent

Request

ResponseResponse

Axis Engine

Transport Global Service

SOAP Service

Request

Response

ProviderTarget

Service

TransportListener

Returncontrol tolistener

RequestRequest

ResponseResponse

Axis Engine


SOAP Service

Request

Response

ProviderTarget

Service

Transportmedium

MessageContent

Clie

nt A

pplic

atio

n

Responsemessage(optional)

Requestmessage

Figure 6 Axis EngineClient Architecture


problems, especially when consuming .NETWeb services. The reason is the lack of unsigneddata types in Java. The next release of Axis willcertainly include support of this.

Another thing is that you cannot send arbitraryJava objects over the wire and expect them tobe understood at the remote end. Axis will onlysend objects for which there is a registered Axisserializer. To serve up objects in general youmust build the serialization support into Axisyourself.

Because Axis developers find the SOAP specifi-cation to be unclear, Axis neither supports RPCcalls in SOAP headers nor multiple RPC calls ina single SOAP message.

Axis supports WSDL 1.1, but does not supportUDDI at all.

Axis supports SOAP headers, but only with lim-ited information so that e.g. .NET interoperabil-ity may be compromised.

It also has preliminary support for the SOAPwith attachments specification.

Axis did well on our interoperability tests,except that

• When publishing WSDL files which specifyport numbers (e.g. 7001), the port number isfor some reason not recognised when theWSDL file is imported in .NET, thus the.NET client must be edited manually to addthe correct port number.

• Axis does not support unsigned data types,and it is thus difficult to make clients for ser-vices that does use unsigned data types in theirservices (e.g. .NET). A solution to this prob-lem is already possible to download, and inversion 1.0 it will certainly be fixed.

Our evaluation shows that Axis is a Web serviceengine with great potential because of its focuson specifications and its development team notbelonging to one single commercial company.However, Axis users must still reconcile them-selves to the fact that a lot of useful functionalityis still not implemented, and that bugs will exist.Combined with poor and erroneous documenta-tion and no professional support organisation itis not recommendable for anyone to use Axis forproduction of Web services.

However, skilled J2EE developers may findAxis a perfectly OK implementation that can beused for experimenting with Web services devel-opment on any J2EE platform, and for that pur-pose its a powerful tool.

3.3 Microsoft .NET.NET is a product that does support all aspects ofWeb Services, i.e. provider, consumer and pro-duction platforms as well as management.

3.3.1 Overview.NET is Microsoft’s newest platform for devel-oping and running applications, competing withthe J2EE standard. It contains Web servicesfunctionality as an integrated part. Visual Studiois a development environment for developingapplications.

.Net integrates technologies that have beenevolving during the last years, such as COM+,ASP, XML and Web services, based on proto-cols like SOAP, WSDL, UDDI and HTTP.

.Net’s architecture is structured as follows:

• Development Tools- A set of languages, including C#, VB.NET,

C++.NET- A RAD developing environment: Visual

Studio 7.0

• Specialized servers- SQLServer 2000, Exchange Server 2000,

BizTalk Server, Commerce Server 2000,ISA Server.

• Web Services- Integration with internal or external services

that can be bound together through theInternet.

• Devices- PCs, handhelds, mobile phones, gaming

consoles.

The main limitations of .NET are the proprietaryformat, which makes application portability dif-ficult and gives interoperability problems whencommunicating with non-.NET services orclients.

The main advantage of .NET is that it promisesto provide a simple and quick service and appli-cation development, especially web based, byexploiting all of the experience with the previoustools. By the “Plug&Play” deployment of theapplications, the installation and distribution willbe highly simplified. At the same time, by meansof the reusability paradigm, the productivity ofprogrammers will be raised.

Microsoft’s solution for implementing Web ser-vices is a complete approach for programmerswho do not have much experience, or who arealready familiar with languages like C++, Visu-alBasic, or any other language supported by theplatform. Introducing Microsoft’s new program-


ming language C# (or c sharp), Microsoft is try-ing to compete in the inter-platform marketagainst Sun Microsystems’ Java. Microsoft pre-sumes its new language is as powerful as Java,but it is still very early to even consider it true,although it does seem to have a large potentialfor gaining some terrain on the programminglanguages competition.

Using the .Net platform provides a big aid fordeveloping Web services, but it is a release thatis still in its early stages, so many bugs, or prob-lems such as interoperability issues, should beexpected to be discovered soon.

An additional advantage that .Net provides is athorough on-line documentation, which can beused for everything from understanding thearchitecture of the platform to finding class defi-nitions and class descriptions for referencingthem. At last, .NET also includes an interfacethat tries to reduce, as much as possible, thenecessity of writing low-level code.

3.4 IBM WebSphereTo facilitate building, deploying and enhancinge-business applications IBM has made Web-Sphere, which includes three product familiesthat all together support the provider, consumer,production and management platforms for WebServices:

• WebSphere Application Server that is a scal-able platform to deploy dynamic e-businessapplications.

• WebSphere Studio that is a set of develop-ment tools for e-business and Web Service

applications based on one common work-bench technology (Eclipse).

• WebSphere Host Integration that offers toolsfor application and data access to legacy sys-tems.

3.4.1 OverviewThere exist different editions of the ApplicationServer that are adjusted to fit the right size of acompany:

• Small companies – WebSphere ApplicationServer, Version 4, Advanced Single ServerEdition;

• Mid-size companies – WebSphere ApplicationServer, Version 4, Advanced Edition;

• Large companies – WebSphere ApplicationServer, Version 4, Enterprise Edition.

The more advanced the edition is, the morefunctions and facilities are included. However,the functionalities mentioned below do count forall editions. The main components are shown inFigure 7.

IBM WebSphere Application Server is a compre-hensive Java technology-based Web applicationserver providing integrated support for J2EE andWeb services. The J2EE compatibility meansthat the full range of Java technology-basedAPIs and protocols are supported, e.g. EnterpriseJava Beans (EJB) that is regarded as probablythe most significant contribution.

Figure 7 Components in IBMWebSphere Application Server

OtherApplication

systems

ERPsystems

Legacysystems

Relationaldata-bases

Connectionservices

Java, JCA, EJB,transactional APIs

Connectionservices

Security, directory,Transactions, Management

AccessServices

(HTTP, IIOP)

Dynamic contentservices USPs,Web Services, HTML

Web Server

ORB

PCs Browsers Mobile/hand-held devices

E-businessapplications

Others(LDAP directories

ORBs, customapplication)

J2EE Web servicesJava Servlet, EJB

WebSphereApplication server


Due to the Web service support it is easy tobuild, customize and publish services based onthe XML, SOAP, UDDI and WSDL standards.The extensible and open programming modeland architecture of the WebSphere ApplicationServer can enable J2EE applications to swiftlyinteroperate with Web service applications.

The WebSphere Application Server contains theJ2EE Connector Architecture (JCA) that may beused to create resource connectors or adaptersfor accessing external enterprise systems. Inaddition, the Application Server does supportJava Database Connectivity (JDBC) that enablesaccess to a range of database servers, such asMicrosoft SQL Server, Oracle and Sybase.

WebSphere Studio provides an industry-leadingintegrated development and runtime environ-ment for the Application Server. In addition theStudio has a workbench based on open standardsthat provide plug-and-play capability for third-party application development tools.

IBM WebSphere Host Integration Solution cantake legacy application to the Web quite quickly.It extends host applications to the Web and pro-vides software for creation and deployment ofnew host access e-business applications, withoutrequiring any changes to the existing applica-tions themselves. Whether one needs a simpleWeb page delivery, putting a new face on alegacy application, or creating sophisticated Javasolutions, the Host Integration Solution allowsone quickly and flexibly to integrate criticalenterprise data with the Web.

Administrators are offered a so-called Web-Sphere Administrative Console used to configureand control a WebSphere domain. A WebSpheredomain is made up of one or more physicalmachines sharing a single WebSphere adminis-trative database, which holds information oneach of the components running on thosemachines. To effectively manage a WebSphereenvironment, the administrator should be famil-iar with the concepts underlying the J2EE run-time environment, e.g. containers, J2EE enter-prise applications, Web modules, EJB modules,XML deployment descriptors, etc.

3.4.2 ResultsIBM provides one of the foremost platforms fordeveloping Web services today. With its stronginvolvement in open projects such as Apache,IBM has ensured that it uses state-of-the arttechnology and follows standards strongly. Web-Sphere has long been one of the most popularapplication servers on the market, and compa-nies that want to take advantage of Web servicestechnology should not be afraid to develop theirservices on this platform.

4 Web Services in MobileTelecom Business

UMTS is the next generation of mobile systems,including networks, terminals and services. WithUMTS the basic Internet protocol, IP, will befully integrated in the mobile networks. This willopen up for Internet Services in the mobile envi-ronment that technology-wise is almost the sameas in the fixed environment, e.g. WAP andi-Mode used by small mobile terminals. At thesame time a great interest is also foreseen in hav-ing access to pure Telco services, such as callcontrol and terminal location, from Web applica-tion to make new powerful integrated services.

4.1 Web Service Access to MobileTelco Services

The standardization of how third parties mayaccess telco services in UMTS is done mainlywithin the Parlay group and 3GPP standardiza-tion body. See http://www.parlay.org/ andhttp://www.3gpp.org/. Currently APIs for thefollowing UMTS services are specified byParlay/OSA (see reference 3GPP TS 22.127V5.2.0 (2001-12)):

• The Framework services managing the accessto the available Telco services; i.e. Trust andSecurity Management (Authentication, Autho-rization), Service Registration, Service De-Registration, Service Discovery and IntegrityManagement;

• Network services; i.e. Call Control functions(Circuit Switched, Packet Switched), IM Ses-sion Control, Information Transfer andCharging;

• User data related services; i.e. User Status,User Location, User Profile Management,User Profile access Authentication/Authoriza-tion, Terminal Capabilities and Functions andRetrieval of Network Capabilities;

• Information Services;

• Presence related services.

All APIs so far have on a high level been speci-fied in UML and mapped on Corba IDL formore detailed specification.

The Parlay Group has recently released version 3of the Parlay specifications, which is completelyconsistent with the 3GPP OSA standard, and thework on Parlay 4 has started. In the work pro-gram a working group is identified, termed Par-layX, which aims to integrate XML and Webservices in future versions of Parlay. Their cur-rent picture of how this may be done is shownin Figure 8.


The Parlay X group intends to integrate XMLin the interface towards the telecom servicecapabilities in two different ways:

• A UML to XML mapping for the Parlay 3specification. This means that the third partyWeb Service application sees the same com-plex APIs as the Corba applications do, andrequires some telecom skills by applicationdevelopers. The XML transport may be quitecomplex.

• A new Parlay X Gateway is introduced at ahigher abstraction level with a simpler set ofAPIs. Usage of those APIs does not requireany telecom skills from the application devel-oper at all. The XML transport is kept simple.

4.2 Mobile Terminals and Web Services

Both Microsoft and other Web Service vendorsare very eager to develop applications on mobiledevices.

4.2.1 MicrosoftPocket PCs (P/PCs) and Handheld PCs (H/PCs)are Microsoft’s own classification of mobiledevices and powered with variants of Windows(CE), respectively Handheld PC 2000 OS ver-sion 3.0 and Pocket PC 2002 edition. The differ-ence between these two is a bit diffuse, but wemay say that P/PCs are quite comparable withPDAs while H/PCs are more like small laptopsor notebooks. Typically, H/PCs are equippedwith keyboards while P/PCs are not.

The developing frameworks and toolkits forH/PC and P/PC are based on Microsoft .NET,

but compressed with respect to functionalityand size so they fit the smaller end tinny mobiledevices. Microsoft has powerful graphical tool-kits that seem to reduce the developing time ofmobile applications quite dramatically. Whenstarting with a new or existing Web Services(.NET) based application as input to the mobiletoolkits, the same application could be modifiedto run on H/PCs or P/PCs with minimal effort.Powerful terminal emulators show immediatelywhat the applications would look like whendeployed in the real environments.

The toolkits are available for free trial to every-body. The Mobile Solutions Developer Toolkitmay be requisitioned from http://www.msdn.microsoft.com/vstudio/productinfo/trial.asp for60 days free trial. Other tools are Microsoft.NET Framework SDK and Visual Studio.NETSmart Device Extensions.

Microsoft also seems quite eager to cooperatein the context of mobile services with telecomoperators all over the world.

4.2.2 The Other VendorsMicrosoft’s competitors seem to base theirmobile terminals on the Java 2, Micro Edition(J2ME) framework, which is the client-sidecounterpart of the J2EE server-side applications,or other dedicated platforms for mobile devices,e.g. WAP or i-Mode.

J2EE platform emphasizes reusable componentsthrough the use of enterprise beans. Applicationsmay leverage these components to support mul-tiple types of clients with little, if any, impact onthe core business logic of the application. Figure

Figure 8 XML Realizationsof Parlay APIs and

Parlay X APIs

Parlay XMLApp Scripte.g. SCML

XMLScript

Java VB

Parlay X AppXML

ScriptJava VB

“Web Services” App

XML Transport:Complex XML sequences

over SOAP, CORBA,HTTP, …

XML Transport:Simple XML sequencesover SOAP, CORBA,

HTTP, …

createCall ()routeReq (A)routeReq (B)...

routeRes (A)routeRes (B)...

“Connect (A, B)” “OK”

Parlay X APIs

ParlayAPIs

SIPServer

A/INElement

MobileSwitch

CORBAIDL, Java,XML, …

CORBAIDL, Java,XML, …

XML

Parlay Gateway

Parlay X Gateway

www.parlay.org

The Parlay Group


9 shows the architecture of an application with aJ2ME client and a browser client, e.g. a WAPclient.

The MIDlet is an application that runs on aJ2ME platform and conforms to the MIDP(Mobile Information Device Profile) standard.

5 ConclusionWeb Service products from vendors who areregarded as leading actors, are investigated inthe previous chapters. However, there are sev-eral other products from not so prestigious ven-dors we have not looked into. So our conclu-sions are based on a rather limited selection ofproducts.

In a quite early stage of the development of WebServices technology our conclusion is that thereare several products mature enough for commer-cial utilization. The .NET, WebSphere andWorkshop are all integrated platforms that pro-vide nice graphical user interfaces and fully

automate most operations involved in the Webservice development. However, Apache AxisWeb service engine is ready to be used, at leastfor testing and experimenting projects. Webelieve this platform will mature more in thecoming months, and skilled J2EE developersmay find it to be an excellent tool. Using Axistoday is far from as simple as using one of theaforementioned integrated platforms.

Even if our investigation does not point out awinner, it shows that a developer has to choosebetween two types of Web Service products, i.e.those based on Java platforms (J2EE/J2ME) orthose based on Microsoft platforms. The tradi-tional competition between the Java world andthe Microsoft world seems to continue in thefield of Web Services as it has in many otherfields of technology. Which type of Web Serviceproduct a developer chooses, will probablydepend on his business policy. What is mostfavourable – being compliant with the Java plat-form or the Microsoft platform?

Figure 9 High-Levelarchitecture of a J2EEapplication supporting a J2ME client and a browser client

WebContainer

LCDUI(User

Interface)MIDIet

Java/J2ME Client

RMS (Local Storage)

Non-Java ClientJSP

Java/J2EE Application Server

EJB

EJB

EJB

EJB

EJB

Servlet

ServletBrowser

GCF(Networking)

EJBContainer

JDBC

JavaConnectors

Java WebServices

JMS

JavaMail

JNDI

COBRA

(Secure)HTTP

(Secure)HTTP

47

BackgroundWeb Services is a new set of technologies withthe ambitious and important goal of tyingtogether logic from distributed components andapplications on the World Wide Web (WWW).Web Services, as the name indicates, are sup-posed to run on the WWW and its well-estab-lished protocol HTTP. The Internet has beenaround for some time, and its basic technologiesare mature. Although the term Web Services hasa new ring to it, the mechanisms for ensuringWeb Service security are based upon well-estab-lished and tested technologies.

At the core of WWW security are the mecha-nisms to secure communications in the client-server model. Web Servers have the possibilityof implementing authentication and encryptionmechanisms like HTTPS to keep certain partsof client-server message exchange confidential.The client browser usually stores all the user’scredentials in the form of digital certificates,which are used to access secure Web servers.

So what is actually the difference between evalu-ating WWW and Web Services security? Firstof all, WWW security is doubtlessly the mostimportant part of Web Services security. Mecha-nisms and know-how with WWW security willbe applicable and reused in Web Services secu-rity. Particularly important are the well-estab-lished authentication and encryption mechanismsused by Web servers. However, the way we see ita few additional points should be taken intoaccount when evaluating Web Services security:

• Web Services security must address theeffects of exposing systems that earlier wereisolated;

• Web Service security must take into accountthat most hackers are likely to be familiar withweaknesses in Internet security technologies.At least, CORBA had the advantage of stayingout of the typical hacker’s electronic back yard;

• Web Services security must set requirementsfor SOAP security;

• Web Services security must define ways tosecure private intra- and inter-company ser-vices in addition to public WWW services;

• Web Service Security must address standardi-sation issues to promote interoperability.

IntroductionThe goal of this article is to give an overviewof Web Services security, both the part that isbased on established WWW/HTTP technologiesand also the new components and protocols suchas UDDI and SOAP. Web Services represent anew way of doing and organising business, andwe will try to identify security requirements insome typical business scenarios. In the subse-quent section, we identify and evaluate currentWeb Service technologies, and look at theirprospects of fulfilling the identified securityrequirements.

In the Standards section, we will take a look atcurrent Web Service standardisation efforts.

To see how the Web Service security require-ments are met in practice, we will close our dis-cussion by giving an overview of security mech-anisms on the current state-of-the-art Web Ser-vices platforms.

We conclude with identifying important successcriteria and pit-falls to avoid in order for WebServices to evolve harmoniously, fulfil securityneeds and build trust vis-à-vis end users.

Basic Web Services Glossary• XML – eXtensible Markup Language; Univer-

sal language for defining data schemes. XMLseparates content from data format. Tags areused to separate data.

• SOAP – Simple Object Access Protocol;SOAP is essentially a one-way messaging pro-tocol, which defines a uniform way of passingXML encoded data. The SOAP specificationdescribes how SOAP over HTTP can be usedfor remote procedure calls. SOAP implementsa client-server model over a transport proto-col, most typically HTTP but also FTP, SMTPetc.

• UDDI – Universal Discovery Description andIntegration; A set of specifications for creatingXML-based directories of Web services offer-ings. The UDDI is separated in white, yellowand green pages. You can either publish() orinquire() in the UDDI directory. When nestedin a global net, UDDI is the Web servicesequivalent to the CORBA naming service.

• WSDL – Web Service Description Language;A common framework for describing tasks

Security in Web ServicesE R I K P A R R , E R I K B E R G A N D S U N E J A K O B S S O N

Erik Parr (26) received hisSiv.Ing. degree (IngénieurDiplômé) in Mathematical Mod-eling from the Technical Univer-sity INSA Toulouse in 2000,including internships at SintefECY and Elf Center for Petrol-eum Research. Following hismilitary service, he has workedin Telenor R&D in Trondheimsince October 2001. His currentresearch interests are in com-puter security, middleware andservice platforms.

[email protected]

Erik Berg (27) received hisSiv.Ing. degree (~MSc) inTelematics from the NorwegianUniversity of Science and Tech-nology (NTNU) in January 1999.He has worked in Telenor R&Das Research Scientist sinceFebruary 2000 in the fields ofmiddleware, e-commerce anddependable distributed sys-tems.

[email protected]

Telektronikk 4.2002


performed by a Web service. A WSDL fileis used to generate the client proxy and thusmake a Web service programmatically acces-sible to other applications.

• HTTP – HyperText Transfer Protocol; Theprotocol used to transport data on the WWW.

• UUP – Universal User Profile; although notyet standardized, UUP is a set of user-specificdata and preferences stored on the WWW toperform tasks such as authentication and per-sonalisation.

Web Services SecurityRequirements

Security Policy and Web ServicesRequirementsSimply put, one could say that securing WebServices is securing the interaction between itscomponents according to certain criteria. Thesecriteria are set down in a security policy, wherethe perceived threat of compromise or fraud andthe eventual cost of bad publicity are weighedagainst the cost of implementing a technicalsafeguard.

A good security policy can help make the WebService stable internally and predictable exter-nally through the API. Therefore, a key elementto secure Web Services is to implement a simpleand consistent security policy. The policy shouldaddress basic issues such as identification andauthentication, authorization, auditing, the needfor data integrity and confidentiality, non-repu-diation and privacy (see Figure 2).

The content of the security policy also dependson the business environment and the type ofWeb Service we consider. As a result, therequirements might be quite different for a fullypublic and a private Web Service. In addition,information about the end users such as the scaleof the end user group and the character of theaverage end user should be taken into accountwhen setting security requirements.

As an example of setting requirements for WebServices, let us consider the fully public WebService myService.com. In this context, publicmeans that everybody with a WWW connectioncan subscribe to the service. The components ofa public Web Service are given in Figure 3.

Before myService.com provided by myCompanycan go ‘on the air’, three basic steps have to be

carried out. For each of them a set of securityrequirements has to be met:

Step 1 – Publish():We suppose that the Web Service providermyCompany already has bundled the businesslogic into an application and made a WSDL fileto describe the service interfaces. In order tomake its service attainable through the WWW,it then deploys the application on a Web appli-cation server like the one given in Figure 3.

Now, to use myService.com, the client applica-tion has to know of its whereabouts. Publishinga Web Service is about registering the servicewith a UDDI service broker, which is the equiv-alent of a yellow pages registry. A client (appli-cation) can browse through this registry lookingfor a service that exactly suits it needs andobtain a reference or an address to that service1).

Now that we have described what we mean bypublishing a Web Service, we will try to identifythe security requirements for the publishing pro-cess:

• There is a need for Identification, Authentica-tion and Authorization. We need to make surethat nobody but the legitimate owner – my-Company – creates or modifies myCompany’sUDDI record. Otherwise, an opportunisticbusiness opponent – myWorstOpponent –might wilfully change the information inthe registry.

• Depending on the security level desired, onecould add mechanisms to ensure integrity, i.e.a guarantee that the correct information aboutthe service is not altered between the applica-tion server and the UDDI registry. Appropri-ate integrity mechanisms would have a pre-ventive effect of sophisticated man-in-the-middle attacks, but would also have the effectof preventing simple denial of service attacks:If, for example, the information about wherethe WSDL file is kept is altered en route, thereis no way for a client application to access theservice.

Step 2 – Find():Find() is the process in which a client (applica-tion) browses through the UDDI yellow pageslooking for a service that suits its needs. Whenthe application finds a suitable service – forexample myService.com – it obtains a referenceto the service’s WSDL file.

Sune Jakobsson (42) is Re-search Scientist at Telenor R&DGeneric Service Platform Group.The group is active in researchof tomorrow’s computing plat-forms for telecom operators.Currently he is an active partici-pant in the EURESCOM P1209and P1242 projects, with focusin the area of Web Serviceusage for telecom operators.He received his Siv.Ing. degreefrom the Norwegian Universityof Science and Technology(NTNU), Faculty of ElectricalEngineering and Computer Sci-ence in 1994. He joined Telenorin 1998 from Stentofon ASA,where he worked as HW de-signer at designing intercomswitches.

[email protected]

1) This process is in many ways similar to looking for a suitable repair facility for your car, except for the fact thatthere are no geographical limitations to Web Services whereas the repairman has to be situated somewhere inyour geographical neighbourhood.


Since the integrity of the information in theregistry is part of the publishing procedure, noparticular requirements are tied to the find proce-dure, except:

• To obtain a high security level there might bea need for the Web Server hosting the registryto authenticate to the client application. Thisavoids a possible cloning of a UDDI registryby a potential perpetrator. Server authentica-tion is a standard part of the HTTP protocol,and is often conducted transparently.

Step 3 – Bind():Bind() is the process in which a client applica-tion looks up a service’s WSDL file in order tocreate a local interface to the service. The pro-cess of making the remote procedure call thenis handled by ‘invisible’ Web Services middle-ware. The interface – or stub classes2) – acts asa proxy for remote object on the local machine,encapsulating and hiding the communicationprotocol(s) from the programmer. This way, theprogrammer only sees the remote interface, notthe actual SOAP and HTTP messages. The con-version of data and values is often referred to asmarshalling and demarshalling.

Creating stub classes from a service’s WSDLfile can be done automatically using an appropri-ate tool, or manually.

For the public Web Service we consider in thisexample, we have not identified any compulsorysecurity requirements for the Bind() process. For

Figure 1 XML Web Services

Figure 2 Security policy forthe public Web Service

‘myService.com’

2) In object oriented languages such an interface or proxy is most commonly implemented by so-called stub classes. A stub class is the local representativeof a remote object. When the client application wants to invoke a remote object, it does this through its stub classes.

This means theimplementation

of the function isnever seen from

the outside.

They are looselycoupled: A change

in the implementationof one function doesnot require change

to the invokingfunction.

There are publiclyavailable descriptions

of the function,its behaviour input/output parameters

(XML) and howto bind to it.

Standardprotocols are

freely availablefor anyone toimplement.

WEB SERVICE

XML Interface

ProgramCode

Interface

SOAP Wrapping

Service Negotiation - Trading Partner Agreements

Discovery, Taxonomies, Registries - UDDI ebXML

Routing, Reliability & Transactions - ????

Service Description Languages - WSDL WSCL

Messaging - SOAP/XML

Transport - HTTP, FTP, SMTP

Internet - TCP/IP

The Web Services Stack

Security Policy for myService.com

1. Anyone with an Internet account maysubscribe to myService

2. Only subscribing subjects may accessmyService

3. Every subject will be assigned a passwordto prove his identity to the system

4. myService must be organised so that nopersonal information about the customersis leaked out to third parties

5. The system manager of myCompany mustknow of all failed login attempts

6. The system manager of myCompany isresponsible for carrying out this policy

Graceland, May 2002John Doe


high-level security, one could consider somekind of integrity mechanism to avoid that thecontent of the WSDL file is changed when it isdownloaded to the Client machine.

Step 4 – Invoke():With the three previous steps the myService.comclient-server battery is finally fully operational.The final step naturally involves the actual in-vocation of a Web service. The service can beinvoked on the local proxy, which handles allthe necessary communications with the mySer-vice.com Web server.

Security requirements for the invoke() operationcorrespond to what we could call runtime secu-rity requirements for myService.com. In thesecurity policy given in Figure 2, the followingrequirements can be identified:

• Identification and authentication: #3 statesthat all users will receive a password to accessmyService.com. So a password-based authen-tication scheme must be implemented.

• Authorization: According to their security policy(#2), myCompany needs to make sure that onlysubscribed users can access myService.com.

• Auditing: As a minimum, to meet #5, rejectedlogin attempts have to be logged.

• Privacy: #4 – No personal subscription infor-mation must leak out. This could introduce aneed to keep certain parts of the messageexchange confidential.

• Confidentiality (#4 – see above).

Remark: Although integrity and non-repudiationare not explicitly addressed in the myService.com

security policy, they should probably – as a gen-eral rule – be considered in connection with‘real’ public Web Services.

Web Services SecurityMechanismsNow that we have identified Web Services secu-rity requirements in a public environment, weneed to identify which technical protectionmechanisms we possess to deal with theserequirements. For a given security policy and alist of requirements, an appropriate subset of ‘allpossible’ security mechanisms should be chosenand deployed.

Securing Databases and RegistriesProtecting databases and registries by means ofencryption and access control mechanisms isfairly straightforward. Technologies for securingdatabases can be considered well established andmature.

However, in the introduction to this article, wesuggested that Web Services security shouldaddress the effect of exposing systems that wereearlier isolated. Many databases and registrieseither have been or at least have the basic char-acteristics of such isolated or standalone sys-tems. So clearly some care should be taken, inparticular with the interfaces exposing the data.

Securing CommunicationsHowever, the protection of data locally onlysolves a minor part of the problem. Like wepointed out in the previous section, the majorchallenge that is introduced by the Web Servicesecurity requirements is to secure data transportbetween the different components. Combiningmechanisms at different levels of the Web Ser-vices protocol stack can help secure data trans-port (see Figure 4).

In the following discussion, we will take a closerlook at the two main Web Service transport pro-tocols HTTP(S) and SOAP and see what re-quirements can be met by a) either one, or b) bytheir combination.

HTTP Security (HTTPS)There have been several attempts at securing theHTTP protocol to ensure secure access to theWorld Wide Web. The Secure Socket Layer(SSL) protocol is situated between HTTP andTCP/IP in the protocol stack and was a popularsolution for transport layer security in the mid90’s. In 1996, the Transport Layer Security(TLS) Working Group was established by theInternet Engineering Task Force (IETF) in anattempt to standardize a ‘transport layer’ securityprotocol. This Working Group is responsible fordeveloping the TLS protocol, which is intendedto replace SSL.

UDDI

registry

ClientApplication

`myService.com`Web Application

server

WSDL

file

2 - Find()

1 - Publish()4 - Invoke()

3 - Bind()

Figure 3 Components in apossible deployment scenariofor myService.com


The combined protocol HTTP/TLS or SSL isoften referred to as HTTPS (see Figure 4). In thefollowing discussion we will mainly focus onTLS, knowing that the evaluation of SSL wouldgive quite similar results.

TLS consists of two main parts: A handshakeprotocol and a record protocol. The goal of the‘handshake’ is to authenticate the server and tonegotiate the cryptographic protocols to use fordata transfer. User authentication is optional.The ‘record’ part assures the transfer of en-crypted data between the server and the browserusing the negotiated cryptographic techniquescombined with a shared session key to ensurethe integrity and the privacy of the message. Useof Public Key Infrastructure (PKI) for sessionkey exchange during the handshake phase hasbeen quite successful in enabling Web com-merce in recent years.

TLS also has some known vulnerabilities. Forinstance, the Handshake protocol is open to so-called man-in-the-middle attacks because para-meter negotiations tend to be in the open. An-other attack exploits the fact that TCP is a reli-able protocol: By discarding packages it is possi-ble to jam the TCP reliability mechanisms andconduct a simple DOS attack.

Running HTTPS-based applications or servicesrequires that both the Web Server and WebBrowser support TLS (see Table 1).

To summarize, the main goal of HTTPS is toprovide privacy, integrity and authenticationmechanisms to secure web navigation and mes-saging. It is a well-established and thoroughlytested technology. On the downside, despite thepossibility of TCP session resumption, HTTPSis significantly slower than HTTP run alone.

A non-exhaustive list of alternatives to HTTPSincludes IPsec, S-HTTP, SET and SASL.

SOAP securitySOAP is an XML-based protocol for sendingmessages and making remote procedure calls ina distributed environment. Besides XML, SOAPis the cornerstone of the Web Services infra-structure. In principle, SOAP can be used withany kind of transport protocol including FTPand SMTP, but at the moment the only commer-cially available mapping is on HTTP.

The SOAP specification does not address secu-rity issues directly, but allows for them to beimplemented as extensions. For example, theextension SOAP-DSIG, which has been submit-ted to the World Wide Web Consortium (W3C),defines the syntax and processing rules for digi-tally signing SOAP messages and validating sig-natures. Digital signatures in SOAP messagesprovides integrity and non-repudiation mecha-nisms. This and other extensions may turn out tobe a useful supplement to the security providedby HTTPS – see standardisation section below.

SOAP is designed to pass through firewalls asHTTP. This is disquieting from a security pointof view. Today, the only way we can recognizea SOAP message is by inspecting HTTP contentand parsing XML at the firewall. But sinceSOAP calls are so diverse with no uniformaddressing model or reliable internal structureeven that does not solve the problem of whichcalls to trust. According to [1] SOAP and WSDL

Web Servers supporting HTTPS Web Browsers supporting HTTPS

Apache-SSL (open SSL libraries) Internet explorer

Apache mod_ssl (open SSL libraries) Netscape

Stronghold Opera

Roxen Cryptozilla

INetStore

Tomcat

Table 1 A (non exhaustive)list of Web Servers and Web

Browsers that support HTTPS

Figure 4 Web Servicesprotocol stack and the basicsecurity issues addressed by

each layer. In the pre-WS era,HTTPS over TCP/IP was the

main mechanism to enableWorld Wide Web security

Provided security features

Integrity

Non-repudiation

Privacy

Authentication

Reliability

SOAP Extensions

HTTP

SOAP

TCP/IP

SMTP FTP HTTPS

Messaging/Wire

Transport Protocols


make no distinction between reads and writes ona method level, making it impossible to filteraway potentially dangerous writes. This meansthat a method either needs to be fully trusted ornot trusted at all. SOAP messages are designedto be free form, which makes log files hard tounderstand and analyse in a consistent manner.

SOAP is fairly new and untested. This meansthat the likelihood of problems showing upalong the way are much greater than with forinstance HTTP(S), which is well establishedand tested for shortcomings.

To summarize, SOAP is a simple and com-pletely platform- and programming language-independent protocol. Unfortunately, simplicitycomes with a cost. SOAP deliberately dodgesfirewall filtering by tunnelling over HTTP, andsince SOAP calls are so diverse, they are unprac-tical to filter and audit. So uncritical use ofSOAP will represent a security risk, at least untilappropriate security tools have been deployedand the information community has had achance to properly test the protocol.

Public Key Infrastructure (PKI) – a Key Enabling TechnologyPKI key management provides a sophisticatedframework for securely exchanging and manag-ing keys. The two main technological featuresthat a PKI can provide to Web Services are:

• Encryption of messages: by using the publickey of the recipient;

• Digital signatures: by encrypting a messagewith your own private key so that anyone withyour public key can decrypt it and furthermoreknow for certain that you wrote it. Non-repu-diation mechanisms provided by PKI anddefined in SOAP standards may provide WebService applications with legal protectionmechanisms.

Note that the features provided by PKI addressthe same basic needs as those that are recognizedby the standardisation organisations as being im-portant in a Web Services context.

In Web Services, PKI mainly intervenes at twolevels:

• At the SOAP level (non-repudiation, integrity);

• At the HTTPS level (TLS session negotiation,eventually assuring authentication, integrityand privacy).

PKI is a proven concept and already widelyadopted in browser-server interaction on theWWW. PKI can thus facilitate and enable trans-

port level security in Web Services. Further-more, because of its propitious scaling proper-ties, PKI seems to be an indispensable com-ponent if Web Services multiply and gainmomentum.

Web Service SecurityStandardsA key element to obtaining widespread WebService interoperability is that implementershave good and universally adopted standards forWeb Service security. Standardisation work isbeing conducted by a number of organisationsand industry actors. In addition, there are organi-sations like WS-I whose dedicated focus is oninteroperability issues. This seems to indicatethat there is a strong momentum in the industryto develop Web Service standards.

Attempts to standardise WS security come inmany forms. Since SOAP security measures arelikely to play an increasingly prominant role inongoing development toward meeting the fullrange of requirements for Web services, manystandardisation efforts revolve around definingSOAP security headers and formats.

World Wide Web Consortium (W3C)XML securityWork on the following key XML specificationswithin the World Wide Web Consortium (W3C)is setting the stage for SOAP security considera-tions. These standards are seen as effectivelylaying the groundwork for SOAP or other XMLbased messaging security over the Web:

• XML Digital Signature (XML-SIG) specifiesthe syntax and processing rules for applyingdigital signatures to any XML data.

• XML Encryption group is developing a pro-cess for encrypting/decrypting digital content(including all or parts of XML documents)and is creating an XML syntax to representencrypted content and the information fordecrypting it.

• XML Key Management Services (XKMS)specifies protocols for distributing and regis-tering public keys so these can be used in con-junction with XML digital signatures andencryption.

• SOAP Security Submissions to the W3C. TheSOAP-DSIG submission to the W3C is anindustry effort to get XML digital-signatureextensions incorporated directly into theSOAP specification. SOAP-DSIG specifiesthe syntax and processing rules for a SOAPheader entry, called the SOAP-SEC element,to carry digital-signature information as partof the SOAP message envelope.


e-business XML (ebXML) MessagingService• ebXML messaging is based on the SOAP 1.1

specification but defines some additionalSOAP headers to handle ebXML specificfunctions such as message routing.

• The initial ebXML messaging specificationrecommended XML-SIG and supportedS/MIME for attachments.

• As the SOAP specification versions movethrough the standardization process, theebXML messaging group is likely to continueaddressing both forward and backward com-patibility with SOAP

Organization for the Advancementof Structured Information Standards(OASIS)OASIS is promoting other standards work rele-vant to XML-based messaging security throughtwo current efforts:

• Extensible Access Control Markup Language(XACML), which is standardizing securityaccess control using XML by defining anXML specification (core schema and namespace) for expressing authorization rules overthe Internet.

• Security Assertion Markup Language(SAML), which is defining a standard XMLsyntax for specifying authentication andauthorization credentials that can be sentalong with SOAP messages. SAML will spec-ify additional SOAP headers to carry asser-tions, among many other requirements.

WS-SecurityWS-Security is a joint effort by IBM, Microsoftand VeriSign to standardise Web Service Secu-rity. According to [2],WS-Security describesenhancements to SOAP messaging to providequality of protection through message integrity,message confidentiality, and single messageauthentication. These mechanisms can be usedto accommodate a wide variety of security mod-els and encryption technologies.

WS-Security also provides a general-purposemechanism for associating security tokens withmessages. No specific type of security token isrequired by WS-Security. It is designed to beextensible (e.g. support multiple security tokenformats). For example, a client might provideproof of identity and proof that they have a par-ticular business certification.

Additionally, WS-Security describes how toencode binary security tokens. Specifically, thespecification describes how to encode X.509 cer-

tificates and Kerberos tickets as well as how toinclude opaque encrypted keys. It also includesextensibility mechanisms that can be used to fur-ther describe the characteristics of the creden-tials that are included with a message.

Web Services InteroperabilityOrganization (WS-I)The Web Services Interoperability Organizationis an open industry effort chartered to promoteWeb Services interoperability across platforms,applications, and programming languages. Themain purpose of WS-I is to respond to customerneeds by providing guidance, recommendedpractices, and supporting resources for develop-ing interoperable Web services.

The organisation’s deliverables are targeted atproving resources for any Web Services devel-oper to create interoperable Web services, andverify that their results are compliant with bothindustry standards and WS-I recommendedguidelines.

WS-I addresses these issues through the conceptof ‘profiles’. Profiles are named groups of WebService specifications at specific version levels,along with conventions on how they worktogether. WS-I has so far defined only one pro-file, ‘WS-I Basic Web Services’. This profiledoes not include any specific security aspects.WS-I will hopefully provide profiles addressingdifferent security issues in the near future.

Existing PlatformsBy studying state-of-the-art Web Services plat-forms, we have evaluated how the Web Servicesecurity requirements currently are met in prac-tice.

Microsoft .NET.NET is Microsoft’s newest platform for devel-oping and running applications, competing withthe J2EE standard. It contains Web servicesfunctionality as an integrated part. Visual Studiois a development environment for developingapplications. .NET integrates technologies thathave been evolving during the last years, such asCOM+, ASP, XML and Web services, based onprotocols like SOAP, WSDL, UDDI andHTTP(S).

The .NET architecture handles security throughMicrosoft Internet Information Services (IIS)and is leveraged by ASP.NET. ASP.NET cantake the identity information provided by IIS anduse that to know who accesses the service or tomake use of code access security for specificoperations on the Web Service. HTTP-levelsecurity is the most common approach in mak-ing message transmissions secure. IIS provides


SSL-support, which also includes the use of dig-ital certificates.

To restrict access to the Web Services, clientauthentication is needed. IIS provides some suchmechanisms, such as authentication by usernameand password, certificates and windows logons.

The .NET Framework provides several mecha-nisms for protecting resources and code fromunauthorized code and users:

• ASP.NET Web Application Security providesa way to control access to a site by comparingauthenticated credentials to Microsoft Win-dows NT file system permissions or to anXML file that lists authorized users, autho-rized roles, or authorized HTTP verbs.

• Code access security uses permissions to con-trol the access code to protected resources andoperations.

Role-based security provides information neededto make decisions about what a user is allowedto do.

Microsoft is currently involved in WS-Security,which is a joint effort by IBM, Microsoft andVeriSign to standardise Web Service Security(see Web Service Security Standards). A pre-view of the WS-Security development toolkitis available at [3].

BEA WebLogic Server 7.0 withWorkshopWebLogic Server (WLS) 7.0 is a fully J2EE-compliant application server, regarded as oneof the leaders in the application server spacebecause it has many Java-oriented features andis a reliable server. According to the document-ation, it supports SOAP 1.2, WSDL 1.1 andUDDI 2.0 and integrates the developing environ-ment with web service support.

WebLogic uses its own declarative and program-matic security models.

The declarative security model is an implemen-tation of the J2EE servlet security model, whichenables access restriction to any resource de-ployed on the server (i.e. a Web application, aWeb service or a Web service method). Usersare assigned to groups, and different groups aregranted access to different Web resources.

The servlet security model also allows offeringthe Web Services within a given application onHTTP- or HTTPS-enabled ports as needed.HTTPS should be used whenever web servicecommunication involves the transmission ofsensitive data.

The programmatic security model allows mak-ing security decisions in the Web Service codeitself to change how Web services behave basedon the permissions of the user. Using this model

Figure 5 The WebLogicServer

UDDIregistry

Publish WebService (WSDL)

DownloadClient Jar

GenerateClient Jar

WebLogic services implementation(SOAP, UDDI, WSDL)

Client

Client Jar

BEA WebLogic Server

Lookup Web Service

Invoke webservice (SOAP)

GenerateWSDL

WSDL

Business layer


it is possible to authorise clients within the Webservice code and also send credentials with out-going messages.

Apache Axis Web Service EngineAxis is the open-source, freeware Web servicescontainer offered by the Apache project. Theacronym stands for Apache Extensible Interac-tion System. It is a complete reimplementationof the architecture of the Apache SOAP project.

Axis is mainly a SOAP engine that acts as aclient and server of SOAP messages with pri-mary focus on HTTP. It can be viewed as a thinlayer sitting between the business logic and thenetwork transport. It includes a stand-aloneserver, but is most commonly used as a Webapplication on top of a Tomcat Web Server (alsoan open source, freeware implementation of theApache project), or it can run as a Web applica-tion on top of an application server (like BEA).

Apache Axis has support for WDSL 1.1, limitedsupport for SOAP 1.1, but no documented sup-port for UDDI. Axis is only the Web Servicesengine, and as such has no need of explicitlysupporting HTTPS, which is the responsibilityof the Web server it is deployed on. When com-bined with a Web server that supports TLS(most typically Tomcat), one could say thatAxis has ‘implicit’ support for HTTPS.

The XML Security package is made availableunder the Apache Software License and can bedownloaded from Apache. It supports the XML-Signature Syntax and Processing recommenda-tion. But except for this enabling of signaturesand HTTP basic authentication, there are no spe-cific security features in Axis. SOAP messagescan be sent over HTTPS, but other than thatthere are no explicit transport security mecha-nisms. Developers have to implement the largerpart of the security on the application level ifsuch is desired.

Axis has defined some preliminary security ex-tensions, which can integrate with the Servlet2.2 security and role specification.

ConclusionIt is reassuring that Web Service security tech-nologies are based upon well-established andthoroughly tested WWW technologies. Webservers can be enhanced with authentication andencryption mechanisms like HTTPS to keep cer-tain parts of client-server message exchangeconfidential. HTTPS has been important forenabling e-business on the WWW, and can becounted on to provide a certain level of runtimesecurity. Web Services span across firewalls andnetwork boundaries and unlike CORBA has theadvantage of avoiding practical problems withfirewall configuration and deployment.

A Web Service security policy should addressbasic issues such as identification and authenti-cation, authorization, auditing, the need for dataintegrity and confidentiality, non-repudiationand privacy.

To meet the security requirements set out in thesecurity policy, a range of technologies andproducts are available. It is fairly simple to pro-tect databases and registries. Protecting commu-nications is somewhat more challenging, and amajor industry effort is currently under way toprovide the messaging protocol SOAP withsecurity mechanisms to complement HTTPS.For the time being however, SOAP is a fairlynew and untested technology that should be han-dled with care until it features universal securitystandards.

PKI is a proven concept and already widelyadopted in browser-server interaction on theWWW. Integration of a PKI key managementsystem in Web Services may provide the WebService Providers and users with a backboneupon which technical security mechanisms canbe built.

Request

MessageContent

Request

ResponseResponse

Axis Engine


SOAP Service

Request

Response

ProviderTarget

Service

TransportListener

Returncontrol tolistener

Figure 6 The Apache AxisWeb Service Engine


Many standardisation efforts are currently underway, but at this time no major and universalstandard is available. The main question is: Willstandardisation organisations and industry beable to agree on one single standard for WebServices security? In our opinion the success ofWeb Services depends on such a universal stan-dard. It is worth stressing that Web Services,secured or not, should be able to interoperate.Without interoperability, the success of thisemerging technology is doubtful. Thus it isimperative that organisations such as WS-Idefine guidelines and standards for interoper-ability that also entail security.

Current Web Services platforms support somebasic security standards (HTTPS), but unfortu-nately the lack of universal standards has pre-vented platforms vendors from implementingstandardised security solutions. This tendencytoward using proprietary solutions may jeopar-dize the very important criterion of Web Serviceinteroperability.

For the time being, the lack of standardisationmakes it hard to unconditionally endorse WebServices security. Interoperability is the keyissue and an important success criterion for thisstill emerging technology. Interoperable solu-tions may lead the Web Services concept towardwide acceptance in the business community. Onthe other hand, the lack of interoperability maylead Web Services toward its eventual demise.

References1 Prescod, P. Some thoughts about SOAP ver-

sus REST on Security. November 15, 2002[online] – URL: http://www.prescod.net/rest/security.html

2 Houston, L. Best practices : Web security.SOAP Security Issues. November 15, 2002[online] – URL: http://dcb.sun.com/practices/websecurity/overviews/soap_security.jsp

3 Using WS-Security with the Web ServicesDevelopment Kit Technology Preview.November 15, 2002 [online] – URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/wssecwithwsdk.asp

Further ReadingVan Do, T et al. XML Web Services : The ser-vices of the future? Fornebu, Telenor workshop,June 2002.

Van Do, T et al. Telenor Mobile XML WebServices. Fornebu, Telenor R&D, 2002. R&DScientific Document N 29/2002.

Jakobsson, S et al. PIR 2.1 – State-of-the-artXML Web Service Technologies and Standards.Project Internal Result, EURESCOM Project1209, 2002.

Peterson, L L, Davie, B S. Computer networks –a systems approach. San Francisco, 2000. (ISBN1-55860-577-0)

Hartman, B et al. Enterprise Security with EJBand CORBA. OMG Press, USA, 2001. (ISBN0-471-4031-5)

McKinsey Quarterly report. Risk and resilience.Special Edition, 2002.

Kaler, C (ed.). IBM Web Services Security(WS-Security), Version 1.0 05 April 2002.November 15, 2002 [online] – URL:http://www-106.ibm.com/developerworks/library/ws-secure/

Security in a Web Services World : A ProposedArchitecture and Roadmap. (IBM white paper.)November 15, 2002 [online] – URL:http://www-106.ibm.com/ developerworks/webservices/library/ ws-secmap/?l=af

Web Services Interoperability Organization(WS-I). November 15, 2002 [online] – URL:http://www.ws-i.org/

Microsoft Web Services. November 15, 2002[online] – URL: http://msdn.microsoft.com/webservices/default.asp

Apache Axis. November 15, 2002 [online] –URL: http://xml.apache.org/axis/index.html

WebLogic Workshop Documentation. November15, 2002 [online] – URL: http://edocs.bea.com/workshop/docs70/index.html


AcronymsAPI Application Programming InterfaceASP Active Server PagesBEA Basic programming Environment for

interactive-graphical Applications,from Siemens-Nixdorf

COM Component Object ModelCORBA Common Object Request Broker

ArchitectureebXML electronic business XMLFTP File Transport ProtocolHTTP HyperText Transfer ProtocolHTTPS HyperText Transfer Protocol

SecurityIETF Internet Engineering Task ForceIIS (Microsoft) Internet Information

ServicesIP Internet ProtocolIPsec Internet Protocol securityJ2EE Java 2 Enterprise EditionOASIS Organization for the Advancement

of Structured Information StandardsPKI Public Key InfrastructureSAML Security Assertion Markup

Language

SASL Simple Authentication and SecurityLayer

SET Secure Electronic TransactionS-HTTP Secure HyperText Transfer ProtocolSMTP Simple Mail Transport ProtocolSOAP Simple Object Access ProtocolSSL Secure Socket LayerTCP Transmission Control ProtocolTLS Transport Layer SecurityUDDI Universal Discovery Description and

IntegrationUUP Universal User ProfileW3C World Wide Web ConsortiumWLS Web Logic ServerWSDL Web Service Description LanguageWS-I Web Services Interoperability

OrganizationWWW World Wide WebXACML eXtensible Access XKMS XML Key Management ServiceXML eXtensible Markup Language

Control Markup LanguageXML-SIG XML Digital Signature

Telektronikk 4.2002

1 IntroductionIn present day communications networks, con-nectivity and high quality voice have becomecommodities. The supplementary services andA/IN based applications are increasingly becom-ing commonplace. We have come to realize thatit is the value added services and applicationsthat are the moneymakers, providing the greatestrevenue-generating potential. In the struggle tosecure a piece of application market share, allthe players have embarked on a quest for thekiller application. If history has taught us any-thing, however, it is that one simply cannot pre-dict what the killer application will be. Time tomarket is yet another key factor in the multi-faceted equation. Killer applications are not tan-gible, sometimes subject to a disquieting amountof hype or fashion. Furthermore, the days oftechnology push have gone. Large serviceproviders and telecommunication equipmentvendors can no longer expect to introduce androllout expensive dedicated network equipmentand service platforms, supporting applicationsthat are then forced upon the consumer commu-nity. Users of communications networks and ser-vices are educated and mature; there is no roomfor complacency. Hence, focus has shifted tofinding and defining the killer environment, orthe killer enabler, rather than the killer applica-tion. The killer environment will allow the net-work operator or service provider to quickly,easily, and without much disruption to ongoingnetwork operations, introduce the killer applica-tion, or killer applications, once it is found.

It has generally been noticed in the industry thatthe killer enabler is provided by open access to,and programmability of, network service capa-bilities. There are two aspects to this killer envi-ronment. First, there is service mediation, i.e.

providing application developers with a unifiedapproach and consolidated architecture for openbut secure, easy but regulated, flexible but scal-able, access to core network service capabilities.Second, to increase the likelihood that a killerapplication will emerge, one needs to provide afertile greenhouse for as large a developer com-munity as possible. This greenhouse should notbe limited to the traditional R&D labs; the largerdeveloper community, including the enterpriseapplication developers and web developers, needto be engaged and inspired to partake in the pro-cess of devising the successful value added ser-vices and applications of tomorrow. This isenvisaged to be achieved by abstracting from thesheer complexity of the application developmentprocess, and the technologies and protocolsinvolved. The killer environment needs to appealto the large crowd of application developers, bydefining the open interfaces using technologiesand methodologies that are close and familiar tothem.

Figure 1 shows a layered architecture designedfor open access to service capabilities [3]. It con-sists of a resources layer, a services layer andapplication servers. The SCFs (Service Capabil-ity Features) are implemented in the serviceslayer and provide their capabilities to the appli-cation servers. In general, application serversand the programmable gateway are physicallyseparated entities. Therefore, a distribution tech-nology between the SCFs in the gateway and theapplication server is needed. Figure 1 also indi-cates an interface between the resources layerand the services layer.

Several papers have addressed the issue of openaccess, service programmability using third gen-eration programming languages and its service

Evolving Service Creation; NewDevelopments in Network Intelligence*)

J O H N - L U C B A K K E R , D A V I D T W E E D I E A N D M U S A R . U N M E H O P A

The application and deployment concept of programmable network capabilities have been well under-

stood and embraced in the industry. To date, Parlay and JAIN have focused on unlocking existing (e.g.

IN-like) network capabilities to a Java and web-enabled developer community. More recently, additional

efforts to further appeal to both application developers and service providers have emerged. The

advanced abstraction and simplification in the programming interfaces (Parlay X), the interest in alterna-

tive transport and middleware technologies (Parlay Web Services), and the emerging field of telecom-

oriented, XML-based scripting languages are clear indications of this development. Furthermore, we see

an attempt to unify the Parlay concepts with another service mediation technology, SIP, to combine pro-

grammatic objects and data types with session control capabilities, as witnessed in the IETF SPIRITS

initiative. In this paper, the authors will give a compendious overview of these new developments in the

area of programmability, and the applicability thereof within today’s and the next generation of networks.

David Tweedie (30) has beenworking as software designerfor Nortel Networks in Ottawa,Canada since 1998. He joinedNortel after receiving a Bachelorof Computer Science with amajor in Information Systemsfrom the University of NewBrunswick in Fredericton,Canada. While at Nortel, Davidhas primarily been working onservice enabling technologies.He started out as a member ofan Advanced Intelligent Net-works development team. Afterthat, he progressed to next gen-eration third-party programma-bility solutions which eventuallyled to investigations into theParlay/OSA APIs.

[email protected]

John-Luc Bakker (30) holds anM.S. degree in programmingaspects of distributed and par-allel computing from the DelftUniversity of Technology, TheNetherlands, since 1996. Priorto his current position he workedwith Lucent Technologies oncomponent based service cre-ation environments, advancedcommunication architectures,multimedia, and recent changecode generation. He has pub-lished several papers in theseareas. Bakker joined Telcordiain 2000 as research scientistand project manager in the Mid-dleware and Mobile Applica-tions Research Group. He iscurrently active in several re-search projects including partic-ipation in standardization forasuch as JAIN, 3GPP and Parlay.

[email protected]

58

*) © The contents of this paper is under the copyright rules of Telcordia.

59

mediation aspect (see e.g. [16] and [23]). Thefocal point of this paper however, is the secondaspect of a successful killer environment, i.e. theappeal to the application developer crowd. Thisis achieved by simple access, using the technolo-gies they like, such as scripting technologies, ata higher level of abstraction. The most promis-ing technology to fulfill these requirements, cur-rently under development in the industry, is thatof Web Services. A Web Service is a capabilitythat can be invoked via standard Internet proto-cols. As such, the prospect of an SCF (ServiceCapability Features), accessible via SOAP/XML([25] and [24]), would perfectly fit the Web Ser-vices paradigm.

This paper will specifically address the aspectof engaging and involving the larger developercommunity. It is important to note that the workon service creation in next generation networksis in full progress. The approach that the authorsadhere to, for the purpose of this paper, is toclassify application programmability and nextgeneration service creation into three main cate-gories. These categories are generic ApplicationProgramming Interfaces (APIs), using many dis-tribution technology realizations, comprehensiveaccess to network capabilities using scripting,and simple and network specific interfacesdeployed as Web Services (Parlay X). It is notthe intention to provide an exhaustive survey;rather the authors will provide a concise synop-sis by presenting one or more compelling andpromising representative technologies out ofeach category. In addition, the paper will addressthe relation of Parlay with another service medi-ation technology proving to be of immense inter-est to the industry, i.e. the Session Initiation Pro-tocol (SIP) [15]. The paper will conclude with a

correlation of all these technologies and initia-tives in a comprehensive overview, identifyinghow they link up into the global service archi-tecture.

2 Programmability ThroughProgramming LanguagesAPIs

One of the first methodologies or designparadigms adopted by the telecommunicationsworld from the information technology domainis the use of APIs. An API is a programmaticinterface providing access to or programmabilityof software resources, such as database applica-tions or telecommunication protocol stacks. AnAPI provides application developers with pro-grammability of software resources, by definingthese resources in terms of objects and methods,data types and parameters that operate on thoseobjects. Examples of resource layer APIs in-clude the JAIN protocol APIs, such as JAIN SIP[17] or JAIN INAP [18]. At a higher abstractionlayer we find the service layer or network capa-bilities APIs, for example the Parlay APIs [12]or JAIN JCC (Java Call Control) [20] and JCAT(JAIN Coordination and Transactions) [21]. Theservice layer APIs do not focus on individualresources, but rather provide application devel-opers with access to service capabilities residingin a core telecommunications network. In theremaining we will focus on the Parlay APIs, theirUML representation and the Parlay realizations.

Parlay APIs are independent of the actualresources; however, protocol mapping recom-mendations exist. Actual resources may resideeither in the A/IN network, in Mobile networks,Managed IP networks, or in Next GenerationNetworks. Parlay Application is thus abstractedfrom resource implementation. As a conse-quence, the Parlay APIs expose only commonaspects and generic functionality of communica-tion networks.

The Parlay APIs are defined using UML (Uni-fied Modeling Language) [12]. The UML mod-eling technology is realization technology inde-pendent. However, as the Parlay UML wasreengineered from earlier Parlay OMG (ObjectManagement Group) IDL (Interface DefinitionLanguage) [7] definitions, the Parlay UML is notfully technology independent. Distribution tech-nologies other than OMG’s CORBA may realizeparticular distribution aspects differently. Thisleads to mismatches when mapping the UML toother realization technologies. Also, the ParlayAPIs specify supports for distribution aspects,such as authentication, on the application leveleven while they are essentially orthogonal to theproblem domain of telecommunications. A fulldiscussion of the Parlay UML and its deficien-cies is not the scope of this paper.

Figure 1 General Programmable GatewayArchitecture

Musa R. Unmehopa (31) re-ceived his M.Sc. in computerscience in 1996 from the Univer-sity of Twente, The Netherlands,after which he joined LucentTechnologies, Bell Laboratories.He is currently a senior stan-dards consultant engineer in theWireless Advanced Technolo-gies Lab within Lucent Tech-nologies, The Netherlands. Heis actively involved in the stan-dardization of open networkApplication Programming Inter-faces within 3GPP, 3GPP2,ETSI, the Parlay consortium, andmore recently, the Open MobileAlliance (OMA). Currently, Mr.Unmehopa holds the position ofvice-chairman of 3GPP Techni-cal Specification Group (TSG)Core Network Group 5 (OpenService Access).

[email protected]

Programmable Gateway(Services Layer)

Application Server

Resources Layer

Telektronikk 4.2002


Still, with some effort, a number of technologyspecific realizations can be generated from theParlay UML model. Initially OMG IDL wasthe only generated and published realization.Recently, a W3C WSDL [27] realization hasbeen generated and published along with therules that were established to enable automaticgeneration of future versions of the Parlay speci-fication. In the immediate future a rulebook thatspecifies the mapping between the Parlay UMLand the JAIN SPA (Service Provider APIs) willbe made available. Figure 2 shows the relationbetween the Parlay UML, OMG’s IDL, W3CWSDL, and JAIN SPA. The realization technol-ogies will be further discussed in the remainder.

2.1 OMG IDLThe technology realization which was initiallyused with Parlay APIs was the OMG IDL. OMGIDL is used to specify the interfaces of remoteobjects. OMG IDL interface implementations(so-called remote objects) typically executewithin a different process on a different hostwith respect to the implementation’s client. Assuch, OMG IDL is well suited for defining theinterface of the Parlay APIs. Additionally, OMG

IDL is the definition language used to define aset of interfaces for use with the CommonObject Request Broker Architecture (CORBA)[13]. CORBA is a standard, defined by theOMG, that supports distributed objects. CORBAprovides a complete set of services to remoteobjects, including concurrency control, licens-ing, life-cycle management, security manage-ment, and persistence. Finally, another benefit ofusing OMG IDL as a specification language isthat it is programming language independent; theOMG has provided standard mappings to manyprogramming languages, including Java and C++.

2.2 JavaIt is recognized that Java is a firmly establishedprogramming language in the enterprise applica-tion market, and emerging in other fields. Forthat reason, many middleware systems supportlanguage mappings to Java. The Java softwaredevelopment packages come with a vast numberof libraries that implement telecom-related (i.e.JAIN) and other standards. The JAIN SPAworking group felt that the Java communitiesexperience in implementing as well as certifyingconformance to standards could be beneficial tothe Parlay community. Note, however, that theJava community does not focus on the distribu-tion technique, but more on ease of use of theAPIs and whether they follow the patterns andparadigms expected of good citizens of the pop-ulation of Java API. It was felt that the OMGIDL mapping to Java inadequately conformed tothese goals. Additionally, some CORBA ORBvendors inadequately implemented the (latest)OMG standards that map Java to IDL, therebyinhibiting the portability of Java applications.

To circumvent these hurdles and increase accep-tance of the Parlay APIs within the large com-munity of Java developers the Parlay group isproducing a rulebook which specifies the map-pings between the Parlay UML model and Java.The Java realization activities underway withinthe Parlay group are part of SUN’s JAIN SPAinitiative.

As indicated in Figure 3, the JAIN SPA APIs areslightly different from the other technology real-izations in that they specify a local API asopposed to a distribution technology API (suchas IDL or WSDL). These JAIN SPA APIs canreside on either the Parlay application server oron the Parlay gateway. The JAIN SPA APIs areindependent of the distribution technology used.It is up to the actual implementation of the JAINSPA APIs to determine which type of distribu-tion mechanism it wishes to use (i.e. IIOP,SOAP, RMI, etc). Figure 3 illustrates how theJAIN SPA APIs can be used to provide a layeredapproach to Parlay application and gatewayservers.

Figure 2 Parlay TechnologyRealizations

Figure 3 Realizationarchitecture

OMG IDL W3C WSDL JAIN SPA

Parlay UML


Application Server

Resources Layer

JAIN SPA APIs

SPA-RMIadaptor

SPA-WSDLadaptor

SPA-OMGIDL adaptor

OMGIDL

WSDL

JAIN SPAApplication

RMI-SPAadaptor

WSDL-SPAadaptor

OMG IDL-SPA

JAIN SPA APIs

JAIN protocols APIs

OMGIDL

WSDL


2.3 WSDLThe XML-based Web Services paradigm trans-forms the Web into an anthology of independentapplication components, each with a well-defined and published interface, which allowother Web applications to find them and usethem. Web Services are built on top of existing,inexpensive and easy-to-encrypt Web protocolssuch as HTTP and based on open XML stan-dards for data encoding. Web Services merelydraw upon the omnipresent Internet infrastruc-ture to discover and compile services into com-pelling value added applications.

The Parlay APIs are realized in WSDL (WebServices Description Language) [27]; WSDL isan XML format definition language which isused to describe the programmable interface fora service. This usage is similar to the OMG IDLuse discussed earlier. WSDL is specified by theW3C organization and is defined with XMLand XML Schemas [28]. The first transport sup-ported by WSDL is SOAP [25] over HTTP.Note that other transport bindings may be sup-ported while retaining the WSDL interface defi-nitions. A WSDL document is defined by aseries of XML Schema elements.

Within Parlay, a set of mapping rules from theParlay UML model to WSDL has been written.These mapping rules provide a mapping fromUML constructs into WSDL elements. Thedetailed mapping from UML to WSDL can befound in the Parlay Overview specification [14].The strength of this approach lies in the strongassociation with web protocols and associatedservice creation and deployment technologies.Hence, the WSDL mapping is done to furtherappeal to the developer community.

Figure 3 shows the possible interplay of all Par-lay realization technologies. The figure illus-trates how the various Parlay realization tech-nologies could be utilized within a Parlay solu-tion. As illustrated, CORBA, SOAP, or evenRMI plays a similar role as a distribution mecha-nism within a Parlay solution. The JAIN SPAAPIs can provide a further abstraction from thedistribution layer both on the Parlay ApplicationServer and on the Parlay Gateway. This sectionhas introduced the objective of the Parlay APIsto expose only common aspects and genericfunctionality of communication networks, inorder to allow for application portability acrossnetwork technologies. To be able to deploy theseapplications using this common and generic APIin the various network technologies, Parlaydefines several distribution technology realiza-tions.

3 Simplified ProgrammabilityThrough Web Services

The Parlay APIs expose capabilities of thetelecommunications network in a network tech-nology and programming language neutral way.In fact, the contributors to the APIs go to greatlengths to ensure that the common aspects of(converged) mobile, fixed, and managed packetnetworks are made programmable for a largeaudience of developers of carrier grade systems.Yet, some more specific but highly valuablecapabilities remain unsupported. As an example,the support for SMS (Short Messaging Service)is inadequate. Additionally, the developer whowishes to program simple applications, such assetting up a third party call (a.k.a. click to dial),using the Parlay APIs, needs to go through elab-orate interactions with different components andinterfaces.

These observations motivated the need for APIsthat are predominantly simple and, consequent-ly, restricted in their capabilities; developers thatneed access to advanced means of control wouldnot be users of these simple APIs, but rather usethe existing Parlay APIs. Additionally, the rigiddogma that favors exposure of common networkcapabilities over specific capabilities needed tobe relaxed. Finally, the resulting APIs wouldpredominantly be used in a multi portal or a webenvironment. The Parlay community proved tobe open to these views and approved the estab-lishment of a group, the Parlay X group, in late2001, which was chartered to create APIs thatincorporated the above views. It was felt thatnew markets are made available through WebServices with Parlay X application definitions.Given a set of high level interfaces that areoriented towards the skill levels and telecomknowledge levels of web developers, the ParlayX APIs open the accessibility of the networkcapabilities to a much wider audience.

Figure 4 shows where the Parlay X applicationsare situated with respect to the Parlay X gate-way. Note that many of the Parlay X capabilitieswill be mediated by the Parlay Gateway. Some,however, are not supported because of Parlay’sfocus on common capabilities as opposed to net-work specific capabilities. Such capabilities can-not be mediated through the Parlay Gateway,rather they need to be made available throughthe resources layer.

Consider a web server that allows end users tocharge for services they consume to their pre-paid accounts, or a customer support page thatcreates, by the press of a button, a voice callbetween an end user and a customer servicerepresentative. Developers in this environmentoften use web services technology to communi-cate with different capability servers, i.e. they


use SOAP and WSDL. Web services provide aset of capabilities and technologies that result ina very compelling foundation for supportingconverged telecom/IT applications.

As with the Parlay APIs discussed in the previ-ous section, authorization, discovery, extensibil-ity and activation are very important featuresthat need to be adequately addressed. The ParlayAPIs introduce the set of Framework APIs toaddress these issues on an application level.The web services environment is different sinceseveral mature technologies exist today or arethe industry norm and can be leveraged toachieve the same. For example, UDDI (Univer-sal Description, Discovery and Integration) orWSIL (Web Services Inspection Language,a.k.a. WS-Inspection) can be used to discover orretrieve references to specific services. WSILfiles describe web services, possibly in a hierar-chical manner, while UDDI serves a centralizedregistration and service publication solution.UDDI or WSIL allow for Parlay X applicationsto discover published services. The UDDI orWSIL-driven registry, finally, contains informa-tion using which the Parlay X application canbind and activate the Parlay X service. Note thatauthorized personnel can extend the registrywith more Parlay X services.

Authentication required prior to accessing theprivate registry can be achieved through acquir-ing access using a VPN or through applyingHTTPS. Many VPN solutions exist, supportinga variety of authentication methods. Based onthe authentication information (e.g. user handleand password in the case of HTTPS) access toonly the subscribed services can be enforced

through dynamically generated WSIL files;effectively authenticating access to subscribedservices only. Finally, various accountingschemes can be employed based on the invokedservice, time of authentication, service agree-ment established a priori, etc.

Today, Parlay X participating companies havesubmitted contributions that target Parlay Xcompatible definitions of web services for UI(User Interaction), 3PCC (Third Party Call Con-trol), Payment, TopUp, UserStatus/Presence/Location, and Messaging (i.e. SMS). 3PCC andUI web services are motivated by the observa-tion that applications that interface with telecom-munications resources often initiate and receivevoice calls. 3PCC supports initiation of voicecalls (e.g. click to dial) and recognizes user input(i.e. voice or DTMF). The TopUp API allowsconsumers to increase the value of their prepaidaccounts and the payment API allows contentproviders to charge for certain types of contentsuch that the billing is handled by the operator.Examples of content that can be charged for aredownloadable ring tones or downloadable voicemail announcements. Next, the UserStatus/Pres-ence/Location contribution focuses on present-ing User Status or Presence (such as online,offline, or engaged) and Location (fine grainedas longitude and latitude or as coarse as withinor not within an area). Finally, the MessagingAPI is intended for sending messages (mostnotably, SMSes) from web pages to devicesthat can accept such messages.

It is hard to measure simplicity. Parlay Xfocuses on exposing capabilities throughaccepted and largely applied technologies by theIT industry. Furthermore, the IT industry is cur-rently furthering the Web Services architecture;emerging standards for transactions and inte-grated security will make the use of Web Ser-vices as a middleware solution even more attrac-tive and will further reduce the complexity ofcreating telecommunications applications.Already, Parlay X is exploring the applicabilityof Web Services middleware in constructing aprogrammable gateway. As outlined above, anumber of contributions have been suggestedand are currently being consolidated and pro-cessed for inclusion in the first release of theParlay X APIs.

4 Programmability ThroughScripting

Scripting languages are lightweight, highly cus-tomizable, and typically interpreted languages,appropriate in the area of rapid applicationdevelopment, acting as glue to provide connec-tions among existing components. These charac-teristics allow them to be used to code or modifyapplications at runtime, and interact with run-

Figure 4 Parlay X Gatewayaccessing specific networkcapabilities directly

Parlay X Gateway


Resources Layer

Parlay X Client


ning programs. Such qualities and features makescripting languages suitable application enablerabstractions and highly applicable to the field ofapplication programmability next to APIs.

XML is commonly seen as the preferred vehicleto create service creation languages. Aside fromits standardization and readability by bothmachines and humans, XML offers several addi-tional benefits. XML supports restrictions to itsexpressiveness. Such a restriction enables easyvalidation and determinability. In general, XMLschemas allow the design of languages that canbe non-expressively complete, thereby guaran-teeing that the XML interpreter, while using alimited amount of time and resources, can easilyexecute the script. Finally, many tools andlibraries are available to create, interpret andvalidate XML documents.

The next generation of scripting languages forcreating value-added services in converged net-works will be based upon XML. Industry foralike Parlay and JAIN have developed open stan-dard APIs to enable service creation in today’sand tomorrow’s networks. While services can bedeveloped in traditional (third generation) pro-gramming languages (e.g. Java or C++) usingthese APIs, the XML-based scripting languagesoffer some attractive advantages. While not asflexible or powerful as a programming language,scripting languages are typically easier to learn,and are platform independent.

Several XML-based call control markup lan-guages have been previously proposed, includ-ing CPML, TML, XTML, CallXML [11], CPL([9] and [10]), the Call Control XML (CCXML)[20], and Service Creation Markup Languages(SCML) [17]. A comprehensive survey of thesecall control markup languages proposals is notthe purpose or within the scope of this section.Instead, we observe the SCML developed by theService Creation Environment Expert Group ofthe JAIN industry forum, and developed accord-ing to open processes by a number of activelyparticipating companies. The rigorous processand the openness, along with SCML’s close rela-tion to Parlay and JAIN will contribute to anincreased industry acceptance and thereforewarrant a closer look.

Languages such as SCML, CCXML and CPLare used to create applications that make use ofthe functions provided by the services layer (asopposed to the resources layer), see Figure 5.The figure shows a scripting interpreter eitherat the application side of the programmabilityarchitecture or at the gateway side. This meansthat both the third party and the operator cansupport programmability through scripting.Scripts can be stored such that they can be

retrieved from storage indicated by a URL orin subscriber databases like HLRs.

The remainder of this section will further discussSCML and its features. Note that a comparisonbetween CPL, CCXML and SCML was pre-sented in [1]. Note also that CPL, CCXML andSCML are all in the work in progress state andcould change in the course of further standard-ization. However, we expect that the overall con-cepts will continue to apply. Finally, the exam-ples given in this section are for illustrative pur-poses only.

4.1 SCMLThe Service Creation Markup Language(SCML) is a scripting language that connectsexisting components such as JAIN SPA or Par-lay APIs, enabling rapid prototyping, rapidapplication development, or easy end-user cus-tomization. We briefly discuss SCML here andcompare it to CCXML.

SCML scripts are created, edited, and validatedusing regular editors or as a result of applyingtransformation techniques. Next, the scripts aredeployed in a retrievable location (e.g. identifiedby a URL). SCML scripts follow a pattern ofregistering the static events and criteria that canbe matched by events (e.g. those emitted bySCFs), followed by declaration of business logicto be executed in response to such an event.Therefore, activation initially encompassesprovisioning the events and criteria and, sub-sequently, executing the business logic uponoccurrence of the provisioned event. A script isdeactivated through removing the provisionedcriteria. The SCML specification only specifiesthe scripting language; no APIs are specified foractivation, deactivation, and other service life-cycle events.

Figure 5 Script interpreterseither integrated with the SCFor with the application server


Application Server

Resources Layer

Scriptinterpreter


SCML is intentionally extendible. It consists of acommon core, defined in the scml-core packagethat should be extended per JAIN SPA or Parlaycomponent. Currently, the core is extended withthe jccml package (JAIN Java Call ControlMarkup (JCC) Language); the jccml packageassumes a JCC 1.1 API [20] implementation.The jccml package is defined using an XMLSchema that is derived from JAIN’s JCC API.JCC provides an API to pure call control relatedcapabilities and can support traditional A/IN ser-vices as well as NGN services such as Click-to-Dial. Finally, JCC can be mapped on top of SIP[8], MGCP, and H.323 [8]. No public documentsshowing an informative mapping from JCC toISUP, INAP and CAP may be available, but theJCC call model was designed to be protocolagnostic.

An example script in SCML is shown in Figure6 for Call Forwarding on Busy. In this script theactivation criteria (indicated by the <discon-nected>-element) are registered with the gate-way. The criteria specified by the registrationelement are the condition that call setup fails dueto a busy callee, that callee’s address, the factthat it concerns the terminating portion of thecall, and an indication that the call processingmust be suspended while the script executes. Ifthese criteria apply, the scripts will be executedand the call will be redirected through specifyingan alternative target address in the <routeCall>element. In this case, after forwarding the call,processing, which was suspended, will automati-cally be resumed.

Note that SCML is not limited to support for theJCC 1.1 API only. Further extensions (e.g.

adding Short Message Service (SMS) compo-nents) are intended. In fact, Figure 7 shows ascript that exemplifies support for and usage ofthe <sendSMS> element. The <sendSMS> ele-ment causes an SMS to be sent to the RFC2806compliant URI tel:2125556767 only if destina-tion tel:2125551212 is busy. The differenceswith Figure 6 are subtle; the example in Figure 7validates the document against a Schema thatextends the Schema used in Figure 6 such that itaccepts the element <sendSMS>. Additionally,processing of the call processing machinery isnot blocked (as the attribute block of the <dis-connected> is set to false); since handling ofbusy connection and sending the SMS are paral-lel activities.

Concluding this section we state that there aremany XML-based scripting languages. We havefurther discussed SCML and found that SCMLis promising as an application enabled abstrac-tion as it makes use of the capabilities providedby the various SCFs. SCML is from the groundup designed to be protocol agnostic andextendible to other sources of events.

5 Service Mediation ThroughSIP

JAIN and Parlay have introduced the concept ofthird party access to service capabilities residingin the core network. Apart from Parlay, asdescribed in detail above, there is another popu-lar service mediation technology that is receiv-ing a lot of interest in the industry, i.e. SIP. Thissection discusses two recent standardizationactivities that incorporate the synergy of Parlayand SIP. The two activities are SPIRITS/PINT,taking place in the IETF, and OSA-to-ISC1),

Figure 6 Example SCMLScript: Call Forwardingon Busy

Figure 7 Example SCMLScripts: SMS on BusySubscriber

</scml>

<register>

<disconnected causeCode ="CAUSE_BUSY" destination ="sip:[email protected]"

connection="terminating" block="true">

<routeCall targetAddress ="tel:2125552121"

redirectingAddress ="sip:[email protected]"/>

</disconnected>

</register>

</scml>

<scml>

<register>

<disconnected causeCode="CAUSE_BUSY" destination="tel:2125551212"

connection="terminating" block="false">

<getOriginatingAddress address="orig"/>

<sendSMS to="tel:2125556767"

content="'Call attempt by '+%orig;+' on 2125551212'"/>

</disconnected>

</register>

</scml>


taking place in 3GPP. In a nutshell, SPIRITS/PINT take conventional A/IN/CAMEL triggers/events from PSTN/ISDN networks and makethose available in the Internet domain. OSA-to-ISC allows application developers to access theemerging 3G IP Multimedia Subsystem. Henceboth activities target different underlying corenetwork technologies, i.e. PSTN/ISDN, and 3GIP Multimedia. In the remainder we will elabo-rate on these two examples.

5.1 SPIRITS and PINTWithin the Internet Engineering Task Force(IETF) efforts have been ongoing for a while todefine interworking between the traditional tele-phony networks and the Internet. PINT (PSTN/Internet Interworking Protocol) [5] addresses therequirement to invoke telephony services fromthe Internet, whereas SPIRITS [6] focuses oncarrying A/IN triggers and events from the tele-phony network to the Internet. Combined, PINTand SPIRITS allow for A/IN-type service logicto be executed on IP hosts and to be delivered totraditional telephony subscribers. The remainderof this section will focus on SPIRITS.

The approach in SPIRITS has been to selectthose A/IN parameters of specific interest toapplication developers. The selection of relevantA/IN parameters has been based on the Parlayspecifications. Various considerations on auto-matically generating these XML parameters andthe use of XML Schema can be found on [6].Summarized, a process collocated on the A/INSCP (called the SPIRITS Client) monitors forA/IN triggers and events of interest from thetelephony network. Once received, the SPIRITSClient extracts the relevant A/IN parameters,according to the Parlay definitions, and parsesthem into XML. The XML-encoded parametersand data types are then placed in the payload ofa SIP message. This message is transported tothe SPIRITS Gateway in the Internet domain.The SPIRITS Gateway either passes this mes-sage on to the SPIRITS Server, located on an IPhost, which terminates the telephony request andis responsible for executing the A/IN-type ser-vice logic. Or, as depicted in Figure 8, the SPIR-ITS Gateway parses the XML-encoded parame-ters and hands them to the appropriate SCF. TheSCF would then use one of the Parlay realizationtechnologies to contact the application server.For a more detailed description of the SPIRITSarchitecture the reader is also referred to [6].This architecture and protocol definition allowsthe SPIRITS Server to execute a Parlay applica-

tion, based on the XML encoded Parlay repre-sentation of the relevant A/IN parameters.

The SPIRITS protocol, between the SPIRITSClient and the SPIRITS Gateway, uses the SIPSUBSCRIBE and NOTIFY messages, as theseare specifically suited for trigger and eventreporting type functionality. The work on theSPIRITS protocol is currently in progress.Figure 9 depicts an example where the A/IN“Answer” event is represented in terms of Parlayparameters, and carried as an XML encodedbody inside a SIP NOTIFY message. The SIPheader portion of this message is simplified forthe sake of brevity; again, the reader is referredto [6] for more detail.

5.2 OSA to ISC mappingSIP has been adopted by 3GPP [1] as the controlprotocol for the wireless next generation corenetwork. This core network is referred to as theIP Multimedia Core Network Subsystem (IMCN). In a nutshell, session setup, control, andteardown functionality are performed by SIPservers, referred to as CSCF (Call Session Con-trol Functions). The CSCFs do not perform anyservice logic execution. Instead, these tasks areperformed by application servers. One suchapplication server, acting as a SIP applicationserver, is the Parlay Gateway. The protocoldefined between the CSCF and the applicationservers is the IM CN Service Control protocol(ISC). With the CSCF and application serversbeing SIP servers, the ISC protocol is in fact theSIP protocol. The IM CN and its functional enti-

1) In this paper, OSA (Open Services Access) and Parlay are used interchangeably. Technically this is not correct, as the set of Parlay APIs is slightlylarger than the set of OSA APIs. However, for the purpose of this paper this distinction is not essential.


Application Server

Resources Layer

SPIRITSServer

SPIRITSGateway

SPIRITSClient

Figure 8 SPIRITSarchitecture in conjunction

with programmabilityarchitecture


ties, as well as the ISC protocol, are being speci-fied by 3GPP [4].

As part of their specification set, 3GPP publishesAPI to protocol mapping recommendations forvarious underlying network protocols. For OSAto be deployable in IM CN networks, the 3GPPspecification in [1] recommends mappings ofOSA to the ISC protocol. The OSA-to-ISC map-pings cover the entire scope of the SIP protocol(i.e. beyond just SUBSCRIBE/NOTIFY) and itssupported headers in order to provide support forthe full breadth and depth of the Parlay CallControl APIs.

Figure 10 and Figure 11 show an example ofhow an OSA API method maps to an ISC inter-face operation. The first part of the figure showsthe IDL definition of the createAndRouteCall-Leg method, which is used by an application torequest the creation and routing of a new callleg. The second part of the figure shows the SIPINVITE message onto which the createAnd-RouteCallLeg method is mapped. In bold fontit is indicated how the individual OSA methodparameters and data types map onto the SIPheaders and their contents. The appInfo OSAparameter is defined as a union data type(TpCallAppInfoSet) of which the alertingmechanism (CallAppAlertingMechanism) isone of the possible fields. In this example, thealerting mechanism is mapped onto the Alert-Info header. For the benefit of simplicity, in thisexample the application does not request for thearming of triggers with the routing of this callleg.

The bold font indicates how the OSA parametersare mapped onto their counterparts in the ISCoperation.

When comparing SPIRITS with OSA to ISC, thedifferent approaches are quite apparent. In theSPIRITS approach the Parlay data is carried asan XML body inside a SIP message, whereas inthe OSA-to-ISC approach the Parlay data ismapped onto the SIP equivalent data (headers).

Concluding, SIP is an Internet protocol thatoperates well with Internet related technologieslike HTTP and MIME. So the combination ofParlay with SIP allows third party telecom appli-cation development at Internet speed, tappinginto Internet creativity.

6 ConclusionIn this paper the authors emphasize the thesisthat the key success factor of a thriving killerenvironment consists of the potency to appeal toa large application developer communitythrough the flexible programmability of servicecapabilities. The authors present an extensivesurvey of established and emerging service pro-grammability technologies. Three main cate-gories are put forward, i.e. programmabilitythrough the use of Application ProgrammingInterfaces, programmability through Web Ser-vices, and programmability through scripting.Subsequently, the authors impart their view onthe relationship of Parlay with another servicemediation technology, SIP, by showing they arecomplementary, and synergy can be achieved.A recurring element throughout all these discus-sions is the use of XML. The authors then makean effort to compile and amass all the conceptsand discussions and provide an all-encompass-

Figure 10 OSA API method

Figure 11 Corresponding ISCinterface operation

TpCallLegIdentifier createAndRouteCallLegReq (

in TpSessionID callSessionID,

in TpCallEventRequestSet eventsRequested,

in TpAddress targetAddress,

in TpAddress originatingAddress,

in TpCallAppInfoSet appInfo,

in IpAppCallLeg appLegInterface

)

INVITE sip:targetAddress SIP/2.0

To: Bob <sip:targetAddress>

From: Alice <sip:originatingAddress>

Call-ID: callSessionID

CSeq: . . .

Alert-Info: <http://www.example.com/appInfo.CallAppAlerting-

Mechanism.wav>

Figure 9 Example SPIRITS NOTIFY message for the Answer event

NOTIFY sip:[email protected] SIP/2.0

From: <sip:[email protected]>;tag=SPIRITS-ER_RES-direc-

tory_nr

To: <sip:[email protected]>

Via: SIP/2.0/UDP gateway.ptt.com

...

<spirits-event>

<DP Parlay=ER_RES/>

<EVENT_REPORT_RESULT ver=1.0>

<CALL_EVENT_TYPE>

<P_CALL_EVENT_ANSWER />

</CALL_EVENT_TYPE>

<CALL_MONITOR_MODE>

<P_CALL_MONITOR_MODE_NOTIFY />

</CALL_MONITOR_MODE>

<CALL_EVENT_TIME>

1998-12-04 10:30

</CALL_EVENT_TIME>

</spirits-event>


ing helicopter view of all concepts and technolo-gies and hence show the correlations and associ-ations.

Figure 12 shows all initiatives aimed at the fur-ther evolution of service creation in next genera-tion networks together. In the figure referencesto the original figures are made. The overall pro-grammable architecture discussed in Figure 1 isat the center of Figure 12. The referenced Figure3 discusses the Parlay APIs and their technologyspecific realization: WSDL, OMG IDL, andJAIN SPA. These realizations concern theservices layer and application server. Figure 4shows the Parlay X architecture in which func-tionality is mainly delegated to the Parlay APIsdiscussed in Figure 3. However, as Parlay Xexposes specific network capabilities as opposedto the common capabilities exposed by theParlay APIs, some Parlay X APIs can onlybe implemented through interaction with theresources layer. Therefore, the magnifying glassconcerns the services layer, application server,and the resources layer. Figure 5 focuses on analternative programming means: scripting lan-guages. Scripting interpreters can be found inthe services layer as well as in the applicationserver. Finally, Figure 8 shows that program-mability of network intelligence can also beachieved through designing protocols that inter-act with the resources layer.

References1 3rd Generation Partnership Project; Techni-

cal Specification Group Core Network;Open Service Access (OSA); ApplicationProgramming Interface (API) Mapping forOpen Service Access; Part 4: Call ControlService Mapping; Subpart 4: MultipartyCall Control ISC (Release 5). 3G TR29.998-04-4 v5.0.0. December 3, 2002[online] – URL:http://www.3gpp.org/ftp/Specs/latest/Rel-5/29_series/29998-04-4-500.zip

2 Bakker, J-L, Jain, R. Next Generation Ser-vice Creation Using XML Scripting Lan-guages. ICC 2002, New York, NY (USA),April 28 – May 2, 2002.

3 Bakker, J-L et al. Rapid Development andDelivery of Converged Services Using APIs.Bell Labs Technical Journal, 5 (3), 12–29,2000.

4 Grech, M, Torabi, M, Unmehopa, M R. Ser-vice Control Architecture in the UMTS IPMultimedia Core Network Subsystem. IEE3G2002 Mobile Communications Technolo-gies, London, UK, 8–10 May 2002.

5 IETF. PSTN and Internet Internetworking(pint) Charter. October 18, 2000 [online] –

Figure 12 Overview ofprogrammability efforts


Application Server

Resources


URL: http://www.ietf.org/html.charters/pint-charter.html

6 IETF. Service in the PSTN/IN RequestingInTernet Service (spirits) Charter. October18, 2000 [online] – URL: http://www.ietf.org/html.charters/spirits-charter.html

7 ISO. Interface Definition Language (IDL).March 1999. (ISO 14750)

8 Jain, R, Bakker, J-L, Anjum, F. Java CallControl (JCC) and Session Initiation Proto-col (SIP). Invited Paper. IEICE Trans. Com-munications, E84-B (12), 3096–3103, 2001.

9 Lennox, J, Schulzrinne, H. Call ProcessingLanguage Framework and Requirements.May 2000. (URL: http://www.ietf.org/rfc/rfc2824.txt)

10 Lennox, J, Schulzrinne, H. CPL: A Lan-guage for User Control of Internet Tele-phony Services. (Work in progress.) January2002. (URL: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-06.txt)

11 OASIS (Organization for the Advancementof Structured Information Standards). TheXML cover pages. October 18, 2002 [online]– URL: http://www.oasis-open.org/cover

12 OMG. Unified Modeling Language (UML).Version 1.4, September 2001. October 18,2002 [online] – URL: http://www.omg.org/technology/documents/formal/uml.htm

13 OMG. Common Object Request BrokerArchitecture (CORBA). Version 2.6, Dec 1,2001. October 18, 2002 [online] – URL:http://www.omg.org/technology/documents/formal/corba_iiop.htm

14 Parlay Group. Parlay APIs Overview. Octo-ber 18, 2002 [online] – URL:http://www.parlay.org/docs/Spec3_es_20191501v010101m.pdf

15 Rosenberg, J et al. SIP: Session InitiationProtocol. June 2002. October 18, 2002[online] – URL: http://www.ietf.org/rfc/rfc3261.txt

16 Stretch, R M. The OSA API and otherrelated issues. BT Technical Journal, 19 (1),80–87, 2001.

17 Sun Microsystems. JAIN SIP Specification1.0, Java Specification Request (JSR) 32.October 18, 2002 [online] – URL:http://jcp.org/aboutJava/communityprocess/final/jsr032/

18 Sun Microsystems. JAIN INAP API Specifi-cation 1.0, Java Specification Request (JSR)35. October 18, 2002 [online] – URL:http://jcp.org/aboutJava/communityprocess/final/jsr035/

19 Sun Microsystems. JAIN Service CreationEnvironment (SCE) API Java SpecificationRequest (JSR) 100. October 18, 2002[online] – URL: http://jcp.org/jsr/detail/100.jsp

20 Sun Microsystems. JAIN Java Call Control(JCC) API Java Specification Request (JSR)21. October 18, 2002 [online] – URL:http://www.jcp.org/jsr/detail/21.jsp

21 Sun Microsystems. JAIN Coordination andTransactions (JCAT) API Java SpecificationRequest (JSR) 122. October 18, 2002[online] – URL: http://jcp.org/jsr/detail/122.jsp

22 Sun Microsystems. The JAIN APIs. October18, 2002 [online] – URL:http://java.sun.com/products/jain/

23 Unmehopa, M R et al. The Support ofMobile Internet Applications in UMTS Net-works Through the Open Service Access.Bell Labs Tech. Journal, 6 (2), 47–64, 2002.

24 W3C. Extensible Markup Language (XML).October 18, 2002 [online] – URL:http://www.w3.org/XML/

25 W3C. Simple Object Access Protocol SOAP1.1. W3C NOTE, 8 May 2002. October 18,2002 [online] – URL: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

26 W3C. Voice Browser Call Control: CCXMLVersion 1.0. W3C Working Draft, 21 Febru-ary 2002. October 18, 2002 [online] – URL:http://www.w3.org/TR/ccxml/

27 W3C. Web Services Description Language(WSDL) 1.1. W3C Note 15 March 2001.October 18, 2002 [online] – URL:http://www.w3.org/TR/2001/NOTE-wsdl-20010315

28 W3C. XML Schema. October 18, 2002[online] – URL: http://www.w3.org/XML/Schema


1 IntroductionAs XML Web Services are rapidly becomingwidespread and straightforwardly used by moreand more actors in the global marketplace, it isimportant from a Telco’s point of view to iden-tify the possible areas where it can benefit fromthese emerging technologies. In what kind ofscenarios can a Telco play an important role andhow can they best exploit the new opportunitiesthat arise with this new approach to service pro-vision?

This article tries to identify various real worldscenarios that are relevant to Telcos with theemergence of XML Web Services. First, in sec-tion 2, a general overview with some differentvisions about what XML Web Services can be isgiven. The rest of the article considers differentscenarios where Telcos can benefit from XMLWeb Services. Most of the scenarios are realis-able as of today, but also some visions aboutfuture Web Services scenarios are mentioned.Finally, a conclusion sums up the article.

2 Overview“Web Services” is the buzzword of today in thesoftware industry. A lot of hype is made aboutthem and this is not very surprising. From a cer-tain perspective Web Services can be considered“as being for applications, what the WWW is forhumans”. The same way HTML links insert doc-uments into a huge hypertext, the SOAP calls ofWeb Services can be perceived as interconnect-ing applications and eventually forming hugeapplications out of discrete distributed func-tionality. From this interpretation it is easy todevelop the vision that Web Services can repeatthe success the WWW has had for humans oncemore, this time for applications.

On the other hand, there are critical voices thatsay that there is nothing new in Web Services,since the underlying concepts already exist (ine.g. CORBA, DCOM, RPC) and since some ofthe underlying standards are relatively old andmature (e.g. HTTP, XML). This argument goeseven further: Web Services do not introduce newfunctionality, thus they will not introduce newbusiness opportunities.

Real World XML Web Service Scenarios for TelcosE R I K V A N E M , G E O R G E B I L C H E V , E D W A R D B U C K L E YA N D T H O M A S H O P P E

Erik Vanem (30) received hisMSc in Physics from the Univer-sity of Oslo in 1996. Before join-ing Telenor R&D in 2000 heworked as a geophysicist atPGS Reservoir, as a researchassistant at the NorwegianDefense Research Establish-ment and as a physics teacherat the Oslo University College.Since 2000 he has worked withuser centric services, mobileapplications and services, Voiceover IP and mobility manage-ment in next generation wirelessnetworks. Recently he has beenworking with distributed com-puting and XML Web Servicesin the PANDA group (PersonalArea Networks and Data Appli-cations) at Telenor R&D.

[email protected]

Dr. George Bilchev (32) joinedBT in 1996. He holds a Ph.D. inengineering design from theUniversity of Plymouth and anMSc in Artificial Intelligencefrom New Bulgarian University.While in BT, George has beenworking on m-commerce appli-cations, personalisation, ser-vice-oriented architectures andcomplex systems research.

[email protected]

EURESCOM Project P1209

The P1209 project is run by EURESCOM with partners from Telenor, British Telecom and DeutscheTelekom. It started up in May 2002 and will run until March 2003. Regarding Telenor’s contribution,this is a joint effort from different research programmes at Fornebu and Trondheim – Future Wire-less World, Internet Network Architecture and Service Platforms are all participating in this project.

The focus of P1209 is on XML Web Services and its opportunities for Telcos, which are in a greatposition to benefit from the development of this progressive technology. The development of XMLWeb Services will alow them to become an application service provider and will allow third partycontent and application providers to rapidly deploy applications that will utilise Telcos’ networks.Telcos are thus in a pole position to either offer an infrastructure for Web services or to supply Webservices on their own. However, Web services require different standards that are still evolving.These standards are implemented by competing companies and are based on different implementa-tion technologies. It can therefore be expected that the development of an interoperable solution isnot as straightforward as one would like to believe.

The main objectives of the P1209 project are the following:

• Evaluate key XML Web Services technologies

• Produce a technology overview

• Investigate relevant standards bodies’ activities

• Understand key XML Web Services standards and future trends

• Analyse XML Web Services pertinent to the Telco environment

• Investigate new XML Web Services business models

• Experiment in a multi-party, multi-technology environment on issues such as interoperability,scalability, robustness, etc.

• Gain hands-on experience on available XML Web Services technologies

• Build a body of knowledge related to the design of XML Web Services

Telektronikk 4.2002

However, the vision is a reasonable one due tothe combination of these concepts and standardsand because of an implicit commitment of nearlythe entire software industry to support the stan-dardization efforts around Web Services. Fur-thermore Web Services are designed havingapplication on the Internet in mind. The visionthat there will be introduced a secure, stable,interoperable, standardized and platform-inde-pendent interface to function calls over the Inter-net in some future is thus realistic. This, in con-junction with the joint effort of the industry(which surely sees some business opportunitiesin their effort), gives reason to develop differentvisions about Web Services. Web Services canbe perceived as:

• Interoperable Internet middleware. Eventhough currently available middleware likeCORBA, DCOM, RMI etc. has found its mar-ket in intranets, utilisation of this technologyover the Internet between partners from differ-ent domains that operate different infrastruc-tures is limited and thus poses a great chal-lenge for the integration of different partners’systems. Web Services can be considered asmiddleware, which establishes interoperabilitybetween different infrastructure platformsover the Internet.

• Extensions of applications onto the Internet.This vision refers to Web Services as themeans for applications to obtain remote func-tionality from services running somewhere onthe Internet. For Example, some spreadsheetprogram could contain some generic func-tions, which receive information about up-to-date currency conversion rates directly fromproviders on the Internet.

• Means for the commercial exploitation of dataand services on a “pay-per-use” basis. Thisvision refers to Web Services as a means thatcould be used to sell data (like the above up-to-date currency conversion rates) or services(such as the transformation of different XML-based business formats) over the Internet.

• Enabler for an open service market on theInternet. Under this vision Web Services areregarded as the means for advertising, broker-ing and accessing of data and services on adynamic basis. Service providers can an-nounce their services in a UDDI registry. Ser-vice requesters can then find services appro-priate for fulfilling their needs in these reg-istries and Web Service technology providesthe means for accessing these functions.

• Means for automatic, dynamic e-business. Asan extension to the previous vision, this can beidentified as the ultimate goal of web services.

In this vision, e-business via Web services isrealised as some kind of highly dynamic, peer-to-peer like business transactions, which arebased on on-the-fly negotiated contacts to andcontracts with Web Service providers. Obvi-ously, this vision is still far from being ful-filled.

Whatever vision one has in mind, the purposeof the entire development is of course the real-ization of business. The goal would be eitherto make future developments less expensiveor more effective, or to develop new businessopportunities. This quest for the business casesof Web Services is currently ongoing.

Even if there is little new with Web Services, thethings that are new will have some impact oncurrent businesses, and it will also allow theestablishment of some new businesses. First ofall the software industry will profit (either bydeveloping and selling software platforms, toolsand servers, or by realising integration projects).Secondly, providers of information and servicesmight profit (the first examples to be mentionedhere are Google [1] and Amazon [2]). Suppliersof infrastructure services might profit (examplesof such companies are Primordial [3], GrandCentral [4], Flamenco [5] or TalkingBlocks [6]),which provide the infrastructure for Web ServiceNetworks) and finally the operators of registriesmight profit from the development of Web Ser-vices.

For Telcos, important questions arise: Will theyfind some business opportunities in Web Ser-vices or not? What will those business opportu-nities look like and which business opportunitiesshould they pursue? As a starting point for suchan investigation, this article describes somegeneric scenarios that on the one hand can havesome business impact for Telcos and on theother hand could be of direct interest to Telcos’business units.

3 Enterprise ApplicationIntegration

EAI (enterprise application integration) is a busi-ness computing term for the plans, methods, andtools aimed at modernising, consolidating, andcoordinating the computer applications within anenterprise. Typically, an enterprise has existinglegacy applications and databases and wants tocontinue to use them while adding or migratingto a new set of applications that exploit the Inter-net, e-commerce, extranet, and other new tech-nologies. EAI may involve developing a newtotal view of an enterprise’s business and itsapplications, seeing how existing applicationsfit into the new view, and then devising waysto efficiently reuse what already exists whileadding new applications and data.

After receiving a BSc inComputer Science from theUniversity of Bradford, EdwardBuckley (23) has worked forBTexact Technologies since2001. He has worked on design-ing mobile commerce servicesand website design and imple-mentation. Currently he is work-ing in the area of XML WebServices, and technology tosupport the use of the SemanticWeb in eBusiness and Knowl-edge Management.

[email protected]

Thomas Hoppe (42) completedhis study of computer scienceat the Technical University (TU)Berlin in 1986. After workingwith a German automative com-pany and a stay abroad he wentback to TU Berlin and workedon two knowledge representa-tion projects. He received hisdoctor’s degree in logic pro-gramming in 1995 from the Uni.of Dortmund and joined DeutscheTelecom Berkom GmbH in 1996.Since then he has worked in thefield of search engines, wherehe holds two patents, and morerecently business models in thearea of B2B e-commerce. He iscurrently Project Manager in theT-Systems Nova GmbH, a busi-ness unit of Deutsche Telecom AG.

[email protected]

70


EAI encompasses methodologies such as object-oriented programming, distributed, cross-plat-form program communication using messagebrokers with Common Object Request BrokerArchitecture and COM+, the modification ofenterprise resource planning (ERP) to fit newobjectives, enterprise-wide content and data dis-tribution using common databases and data stan-dards implemented with the Extensible MarkupLanguage (XML), middleware, message queu-ing, and other approaches.

EAI exploiting Web Services technologies canbe beneficial to Telcos in the same way it wouldbe to any other types of enterprises in integratingtheir own different internal legacy systems.Apart from that, business units in Telcos withexpertise in EAI can find a business opportunityin acting as integrator for other enterprises thatneed help from external experts in order to runinternal projects on EAI within their systems.

4 B2B IntegrationB2B integration is another area where WebServices technologies can be exploited. The fol-lowing describes a scenario of B2B integrationrelevant to Telcos.

In the outlined scenario a wholesaler wants toestablish business relationship with a retailer.The main steps in such scenarios are:

• Preoperational B2B- Establishment of B2B Capabilities- Establishment of B2B Contract

• Operational B2B- Running of B2B collaborations

We assume that the wholesaler does not haveB2B implemented, but that the retailer has com-plete B2B:

The wholesaler needs to establish CollaborationProtocol Profile (CPP) and search for CPP fora possible Retailer in a Repository. The whole-saler needs to work with two different third par-ties, a System Integrator to establish CPP capa-bilities and a Registrar to be registered in theRepository.

The UML use case diagram in Figure 1 providesan overview of such a generic scenario.

The relationships between actors and theirrespective roles are shown in Table 1. It shouldbe noted that a Telco could take all of these rolesin different B2B scenarios. It can be the Whole-saler that wants to establish contact with Retail-ers to sell its services to the end customers. Itcould also be a Retailer that resells services onbehalf of others and integrate other’s services in

their products. Finally it could act as the ServiceIntegrator that help its customers to implementsB2B capabilities.

The first step for the wholesaler is to establishB2B capabilities, and this is illustrated in Figure 2.

The Wholesaler would first browse a repository(ebXML/UDDI) manually to find a suitable Sys-tem Integrator. The Wholesaler would then runmanual negotiations with the System Integratorbefore signing a TPA (Trading Partner Agree-ment). These transactions are not based on B2Bstandards other than knowledge about B2Bissues by at least one of the business partners.The B2B issues should be stated in the contract.

The next step is for the System Integrator toimplement the TPA requirements for the Whole-saler. This step does not include any specificB2B transactions and the implementation iscontrolled by the contract.

Figure 1 Actors in a generic B2B integration scenario

Figure 2 Implementationof B2B for Wholesaler

Actor Name Role Description Role Type

Wholesaler Wants to establish contacts with retailers to sell its products to the market (Requestor) Organisation

Retailer Sells products on behalf of wholesaler Organisation

Service Integrator Implements technical B2B capabilities Organisation

Registrar Defines and register CPP/CPA in Repository Functional

Table 1 Actors and roles ina B2B scenario

System integrator

Responder Registrar

RetailerWholesale

Respon

der

ResponderRequestorB2B Integration

SystemIntegrator

Wholesale

ResponderRequestor EstablishContact

ImplementB2B

ResponderRequestor


Then, the Wholesaler should use a Registrar toestablish a CPP (Collaboration Protocol Profile)and put it into a Repository as illustrated in Fig-ure 3. Regarding the transactions, the Whole-saler will have B2B capabilities installed, but thecommunication with the Registrar can also be byother means. The Registrar can be a softwarepackage installed at the Wholesaler site, but itmust interface the B2B Repository and satisfycertain requirements.

Having completed these steps, the Wholesaleris now ready to negotiate a CPA (CollaborationProtocol Agreement) with the Retailer as illus-trated in Figure 4.

The Wholesaler does a B2B search in a Reposi-tory for a Retailer Partner, starts negotiatingCPA with a desired Retailer before they bothsign the CPA agreed upon. The transactionsinvolved in this job will depend on the toolinstalled at the Wholesaler site, which mustcomply with the specifications.

With a CPA signed, one is now ready to runB2B operational collaboration in accordancewith the CPA (Figure 5).

The transactions to be run will depend on theBusiness, but they will all have to be stated inthe CPA. For certain businesses it will be possi-ble to use already developed transactions, whichwill be visible in the B2B Repository. It will alsobe possible to use existing payloads like EDI

(Electronic Data Interchange) if required. Fornew transactions, they must comply with rele-vant standards.

5 Web Service ProvisionThere are different instances of scenarios thatcan be summarised under the scenario class“Web Service Provision”. In general, Web Ser-vice Provision means to offer Web Services tocustomers, either in order to distribute contentor to make content services available.

5.1 Telco as a Web Service ProviderIn this scenario class a Telco takes on the role ofa Web Service Provider. It provides informationor services commercially via Web Service inter-faces for applications belonging to its customers.

The information and services which could beprovided by a Telco range from information italready owns (like e.g. phone numbers, addressinformation, yellow pages, telephone bills, per-sonalisation and localisation information), andtheir corresponding services (e.g. phonebooklookup, configuration of telephones and Internetaccounts, product search and comparison, bonusprograms), to information which they redis-tribute or resell (e.g. stock quotes, news, audio,videos, multimedia presentations), and serviceswhich they offer for third parties (e.g. access tolegacy systems, shopping carts).

The customers could be private consumers (e.g.if the Web Service allows customised access tostreaming content), or they could be businessusers (e.g. if functionality of remote office pack-ets is made available via Web Services). Addi-tionally the customers could be applicationdevelopment companies, which either hard-codecalls to Telco Web Services (like the afore men-tioned phone book lookup) or pre-configurethem into their applications.

Usually the access to these Telco Web Serviceswill be via some application, either by a webpage or integrated into some desktop or serverapplication.

Web Services provided by a Telco in this waycould either be free (for example during the mar-ket entry, as a marketing instrument or foradvertisement purposes) or they could be avail-able for a fee, either as a subscription fee, inpre- or post-paid mode. Different accountingschemes could be used here either pay-per-use(-per-volume, -per-time), monthly with limit, etc.

5.2 Players and their Roles

TelcoAs mentioned already the Telco plays the role ofa Web Service provider, which makes informa-

Figure 5 Running B2Bcollaboration

Figure 3 Collaboration negotiation and CPP registration

Figure 4 CPA negotiation

RegistrarWholesale

ResponderRequestor Negotiate andRegister CPP

RetailerWholesale

ResponderRequestorNegotiate CPA

RegistrarWholesale

Run B2BCollaboration


tion and services via Web Services available inthis scenario. Provision in this context meansthat the Telco owns and operates the systemswhich deliver functionality and which are madeaccessible via Web Services.

The information and services might be free (inthat case they function only as a marketing orservice instrument) or they are commerciallyavailable at some fee.

Especially in the case of commercially availableWeb Services, it is reasonable, that the Web Ser-vice provider makes use of some infrastructureservices, e.g. for secure messaging, billing,authentication, authorisation etc. These servicescan either be provided by the Web Serviceprovider itself or they can be obtained fromsome external provider of Web Service Infra-structure Services.

The Web Service Provider can own the informa-tion and services provided or this informationcan be obtained from some external provider.Thus different constellations can be identified:

• In the case of a Telco acting as Web Serviceprovider, which provides its own informationand services, it is clear that this informationand services will originate from the telecom-munication domain, i.e. that they are eitherrelated to phone, mobile, Internet or networks(Figure 6).

• In the case of a Telco acting as a Web Serviceprovider, which provides external informationand services, the Telco may either redistributeor resell the information, or it augments itwith own functionality. In both cases theTelco may get some margin (Figure 7).

• In the case where a Telco combines or aggre-gates different information or services, it actu-ally combines them to some value addedinformation that could be charged on its own(Figure 8).

External ProviderExternal Providers in this scenario are all partiesfrom which a Telco obtains external informa-tion, external services or infrastructure services.

CustomerCustomers in this scenario are those parties thatmake use of the Web Services provided by theTelco. More precisely customers are thoseinstances whose applications make use of theprovided Web Services. They include privateend users, business users and application devel-opers, but also other Web Service providers.

5.3 RelationshipsThe primary relationship between these differentroles is of course the usual customer-supplierrelationship. The Telco takes on either the roleof a customer or the role of a supplier. However,the Web Service itself introduces a major depen-dency, whether it is a commercial or a free ser-vice. While trading partner agreements suffice inthe latter case, the former case needs to go fur-ther by establishing a solid contractual basis forthe relationships.

Telco – External ProviderUsually the relationship between the Telco andsome external provider will be of some commer-cial nature. In this relationship the Telco takeson the role of a customer, while the externalprovider takes on the role of a supplier.

Even so it is conceivable that in some nearfuture, relationships to suppliers will be estab-lished dynamically and automatically, requiringof course that all issues of trust and automaticcontracting are solved. In most cases it will be inthe interest of the customer to establish a longerlasting relationship to its suppliers. Otherwise hecould hardly warrant an operational Web Serviceto his own customers.

Figure 6 WS providing its own information or services

Figure 7 WS provider providingexternal information or services

Figure 8 WS providercombining external

information or services

WS Customer

TelcoWS

WS Customer

TelcoWS

WS Provider

WS Customer

TelcoWS

WS Provider I

WS Provider II


The information and services a Telco uses fromsome external provider are the prime relation-ship between them. However a solid businessrelationship needs to be established in order toagree on technical details of the usage and onthe business issues. Trading partner agreementsalone are not sufficient here, and contracts needto be established.

Caused by the establishment of contracts be-tween both partners it becomes obvious that theTelco and the external provider need to speakthe same language. This means that they mustagree on the interpretation and on the under-standing of the terms they use in their contractsand in their communication.

Telco – CustomerThe relationship between a Telco and its cus-tomer resembles the previous relationship, butwith opposite roles. Now the Telco plays therole of the supplier.

The relationships to the different customers needto be differentiated depending on the type of thecustomer, i.e. whether it is some private end user,some business user or an application developer:

• In the case of a private end user the relation-ship is not guaranteed to be long lasting.

• A business user as a customer is probablymore interested in some longer lasting rela-tionship, but there exists no guarantee for alonger lasting relationship in this case either.

• Application developers, however, who inte-grate the usage of the Telco’s services intotheir own applications establish a long lastingrelationship.

All other aspects – trading partner agreements,contracts and usage of the same vocabularybetween the Telco and its customers – will bethe same as described in the previous section.

6 Web Services BrokerTechnically speaking, a Web services broker isan intermediary positioned anywhere within aWeb Service message path that performs avalue-added function. This very broad definitionincludes entities ranging from all sorts of soft-ware components and network appliances thatfunction as part of the messaging infrastructurethrough third party Web Services networks andcarriers. However, in this section we will focuson the role of a third party intermediary organi-sation that hosts Web Service interfaces and bro-kers communications between requesters andproviders (as depicted in the “Discovery” layerof Figure 9).

Web Services brokering provides the opportu-nity of an organisation to become an indirectsupplier channel. The main role of the Web Ser-vices broker is to connect (for a fee) users withservice providers. It is believed that suppliersof commodity Web Services (like reservations,shipping and content) will deliver more than 70percent of them through a Web Services brokerwithin a few years.

This section presents a scenario where Telcosplay the role of a broker who gets requests fromWeb Service developers or applications and whodirects them to selected/found destination WebService provider. To better understand how thisscenario fits the Web Services architecture stackand ecosystem, the reader is referred to Figure 9.

Figure 9 describes a generic Web Services stackwhere layers are grouped into three groups: theWeb Services platform, the Web Services brokerand the Web Services network. The role of theWeb Services broker is to provide as a minimuma registry for publication of Web Services andmeans of searching for Web Services. However,a broker might also provide categorisation,mediation and validation of Web Services. Bro-kers do not create services, nor do they manageor host services. Their main focus is to build alarge supplier network and to exploit that net-work to generate incremental revenue. Toachieve that, Web Services brokers will have toadd value to the minimum requirements of reg-istry provisioning and searching. Value-addedbroker services might include aggregating anappropriate set of services and cataloguing thoseservices as a portfolio of offering, building verti-cal catalogues of Web Service components,exploiting their brand name to offer those ser-vices through the registry, etc.Figure 9 Web Services

Architecture Stack

WebServicesNetwork

WebServicesBroker

WebServicesPlatform

• PartnerEnablement

• Manageability• Reliability• Trust

• RegistryProvision (UDDI)

• Matchmaking

• WSDL Generation• SOAP Generation

Agreements

Orchestration

QoS

Security

Routing

Discovery

Service

Packaging

Transport


Figure 10 describes the place of the Web Ser-vices broker in the Web Services ecosystem. Thebroker is linked to the Web Services network,and it is quite often the case that a Web Servicesnetwork will provide a broker as part of theirsolution. Also recalling the broader definitionof a Web Services broker, the tighter couplingbetween the Web Services network and thebroker would allow brokerage to occur at otherlevels of the Web Services stack. For example,solutions exist (mainly from Web Services net-work vendors/providers) where horizontal value-added brokerage occurs to provide encryption,authorisation, access control, monitoring, meter-ing, logging, auditing, provisioning, billing,non-repudiation, etc. It is worth noting that theabove-mentioned horizontal brokerage serviceswill become commoditised (especially when thestandards mature and the big vendors incorpo-rate them in their platforms). Ultimately, suchcommoditisation will drive prices down and trimprofit margins. Therefore, the selected scenarioin this section will focus on providing verticallyoriented brokerage services on behalf of an in-dustry specific community (the Telecom sector).

6.1 Example ScenarioConsider the following scenario for a Telco as aWeb Services Broker: A large Telco is lookingfor new opportunities to leverage its expertise inthe Communications market and its network ofsuppliers, so a decision is made to become a ver-tical Web Services broker for the Communica-tions sector. The broker will run a UDDI registrywhere suppliers will be able to register Web Ser-vices. A taxonomy/categorisation will be pro-vided to facilitate search. As an added value tothat, the broker will provide packaged offerswhere one supplier is used for more than oneWeb Service or discounts where the Telco hasalready agreed volume deals with given suppli-ers (thus aggregating volume and leveragingexisting relationship with suppliers).

To leverage its knowledge of the supplier net-work, the broker will provide ratings of the par-ticipating suppliers and it can further provideratings for individual web services based oneither a testing programme or customer feedbackor popularity. Other value-added services suchas payment brokerage, availability and QoScould be offered if the broker is part of a Webservices network solution.

The Telco plans to use its established brand toattract customers to search for solutions throughits registry. To aid that, the broker is providingvalue-added solutions consultancy and integra-tion services. The solution consultancy willaddress the problem of solution composition andworkflow at least until the Web Service orches-tration standards mature. The integration will

mainly involve those missing components of theoverall solution, which are not yet Web Servicesenabled.

Another value-added service the broker will pro-vide is translation of Web Services calls. Thetranslation (or mapping) will be required in reallife because two different suppliers of say anSMS Web Service could provide two differentSOAP interfaces for sending SMS. All SMSsuppliers will be listed at the same level of thetaxonomy, but without real time translation/map-ping a customer’s application will not be able todynamically select a provider. The translationcould happen at design time at the customer’send, but the value of a translation service run bythe broker is that when new providers are addedonly the broker would implement the translationand not all the customers.

The Telco is charging customers either per useof the registry or a subscription to use the reg-istry. Any consultancy and integration serviceswill be charged extra at current consultancy orintegration rates.

7 Web Services InfrastructureServices

As with all distributed applications, some mainconcerns related to Web Services are:

• Trust. This is intertwined with security, due tothe validation of origin being an authentica-tion issue.

• Security, such as Data confidentiality, authen-tication and validation of data origin, dataintegrity and non-repudiation, and authorisa-tion of user access.

• Reliability and failover. As well as being reli-able, distributed services need to be “aware”of their environment and handle failures (andtimeouts) gracefully.

WebServices

Requester

WebServicesBroker

WebServicesNetwork

InternetPlumbing

WebServicesProvider

Figure 10 Web Services Ecosystem


• Scalability. Can a service handle many con-current requests without major degradation ofperformance and reliability?

Even though Web Services in themselves aresimple to create, an infrastructure needs to beapplied as with any other business application,and Web Services can be used as the actual inte-gration infrastructure.

Infrastructure Services will allow applicationdevelopers to design and develop without need-ing to worry a great deal about how the serviceswill be managed. Essentially this is a combina-tion of value-added network services.

The Web Services Infrastructure Services sce-nario takes the Telco as a provider of basic infra-structure services offered to Web ServicesProviders, such as:

• Secure messaging – the ability to communi-cate reliably and securely over an insecuremedium (e.g. the Internet).

• Authentication – being able to identify whois being communicated with (trust betweenpartners).

• Authorisation – only allowing certain users(who have been authenticated) access to cer-tain parts of a system; this includes e.g. con-figurable usage policies.

• Billing – a standard method for payment tooccur.

• Payment – including factors such as non-repu-diation (being able to confirm that correctbilling has occurred).

The rationale behind this is that Providers cannotimplement the infrastructure needed for businesscollaborations in Web Services on their own, forexample due to lack of resources and the ex-pense involved. The Web Service Providerswould be charged for this instead of the EndUsers and players will be able to communicatewith each other in a more easy and trustworthymanner.

Additional infrastructure services can be summa-rized here, e.g.

• Auditing & logging – monitoring the accessand usage of Web Services.

• Metering & accounting – metering Web Ser-vice resource consumption in terms of numberof calls, required time or transported data vol-ume and condensing these figures.

• Monitoring & filtering – ensuring the healthi-ness of Web Services by alarming theirproviders about problem situations or byensuring system availability in the case ofdenial-of-service attacks.

These infrastructure services can therefore bedescribed as a management platform. The actualWeb Services implemented will make use of the“basic” infrastructure services in order toremove all the complexity of management.Within the Web services ecosystem, the Infra-structure Services provider fits into the WebServices Network paradigm, allowing requestersand brokers to communicate with the Providers.

7.1 Players and their Roles

TelcoIn the described scenario, a Telco could take therole of an infrastructure provider, allowing WebService Providers to make use of managementservices. These services will be generic – notspecific to an actual Web Service – such as mes-saging. Implementation issues, however, meanthat minor customisations may be required whencommunicating with specific Web ServiceProviders. The Telco will handle the basicinfrastructure services as described above.

Web Services ProvidersThese are the providers of the actual Web Ser-vices that are accessible to other providers, users(which in this model are mainly other Web Ser-vice Providers), etc. In effect, they will “sit ontop” of the Telco, since their services will makeuse of the infrastructure provided by the Telco.Once Services begin using the infrastructure,they will be dependent on the Telco. Thereforea comprehensive trading agreement is requiredbetween the Telco and the Web ServiceProviders.

Certificate AuthorityFor the authentication and authorisation services,two solutions can be applied:

• The Telco acts as its own CertificateAuthority.

• A separate Certificate Authority, a third party,is used. This is the recommended solution, asthe trust will be greater – the Telco will notcontrol the certificates and instead pass thecontrol to an independent organisation.

This also applies to the secure messaging pro-vided by the Telco, where certificates will beapplied to messages sent between Players.


7.2 RelationshipsSun proposes an overview of the relationships in[7] where smart = context aware. The majorityof the relationships in this model will requireTPAs (Trading Partner Agreements) between thePlayers involved in a relationship or interaction.It would be beneficial to be able to define thesein a pragmatic and consistent way, and ebXMLis ideally suited for this.

Telco – Web Services ProviderThe communication between Telco and WebService Providers will depend on the architec-ture model used, of which there are two mainones, centralised and de-centralised.

In the centralised approach, the Telco acts asa Hub for connecting Web Service Providersand Web Service Consumers (Figure 11). Thismeans that all communication passes through theTelco. For ease of management and coordinationthis is a good solution, however the scalabilityof this model is questionable – the reliabilityand performance of the hub will depend on theamount of traffic passing through the hub, whichwould cause increasing investments into theoperational infrastructure. In addition, complex-ity is added to RPC (Remote Procedure Call)or synchronous style Web Services, where theServices communicate directly with each other;overheads and potential failure points are addedto the development and deployment.

The other model is a de-centralised approach,where there is centralised management but withthe communication being de-centralised as illus-trated in Figure 12.

The idea is that the communication betweenWeb Service Providers is peer-to-peer. The mainadvantages to this model are that the Providersare not as tied into the Telco as with the cen-tralised model, and that the bottlenecks associ-ated with the Hub approach will not exist.

For the Telco to be able to manage the servicesprovided by the Web Service Providers, a proxyis required at all ends of a Web Service-basedcommunication at each Web Service Provider.This is a remote piece of software associatedwith the Infrastructure Management, which allWeb Services traffic from the relevant Providerpasses through. Because the proxy exists at bothends, the communication can be securely sentand other infrastructure services can be hookedinto the proxy. The communication betweenTelco and Web Service Provider in this modelwill not be constant, but sent only when needed(e.g. authentication), for reporting purposes orfor upgrades of the proxy.

This model is more in line with the distributedloosely coupled concept of Web Services, but itdoes have its disadvantages:

• More complicated coordination. The WebServices are not in direct communication withthe Infrastructure Provider, but communicatethrough the proxies. The complicated task ofmanaging numerous, exposed proxies couldcause deployment and usage problems.

• Due to the proxies being de-centralised andexposed, they will be much more susceptibleto attack, which in turn puts the centralisedmanagement at risk.

There is also the possibility that the de-cen-tralised approach can be taken, but without thecentral management. In this case the Infrastruc-ture Provider provides the management servicesas a packaged solution to Web Service Pro-viders. This would mean the Telco renouncecontrol over the infrastructure. They wouldtherefore only benefit from licensing, and thereal task lies in finding licensing models thatwill turn every use of the packaged solution intoprofit. Other benefits such as secure messagingand reporting are also much harder to providewith this approach.

Figure 11 Centralised model of a WS Infrastructure Provider

Figure 12 De-centralisedmodel of a WS

Infrastructure Provider

WS Provider/Customer I

TelcoWS

WS Provider/Customer II

WS Provider/Customer III

WS Provider

Telco

WS Provider

WS Provider


The communication between Telco and WebService Provider will not just be for the runningand usage of provided Services; other factorssuch as Service development and integration intothe infrastructure services will be part of theagreement between the two Players.

The architectural model chosen depends on whatparticular Web Service Providers require, i.e. thetypes of services being offered and what type ofmanagement is required. Generally, if perform-ance were important then the de-centralizedapproach would apply, and if security were ahigh priority then the centralized hub approachwould be the preferable of the two.

Web Services Provider – Web ServicesProviderAs Telcos have two alternative architectures, thecommunication between Web Service Providerscan be in two different ways. Either they com-municate “directly” (peer-to-peer, but communi-cating through each other’s proxy), or indirectlythrough an infrastructure hub.

Telco – Certificate AuthorityThis communication will be relatively simple,since each Player knows which Services at eitherend will be used. Security is an obvious require-ment, which is an integral part of the infrastruc-ture anyway, due to the level of trust that will beplaced on the certificates by every Player. Theagreement between Telco and CA is probablythe most important trust link in the infrastruc-ture.

8 Telcos as Provider forMobile Web Services

Concerning the general characteristics this sce-nario class follows the scenario class above.However in the mobile case, it has to accountfor the characteristics of the mobile context, i.e.mobile users, mobile devices and applications ina mobile environment.

In the scenarios covered by this class it is morereasonable that the Web Services are providedand hosted on some server system, while themobile devices just issue the calls to them. Thisgives reason to conclude that the prime cus-tomers covered by this scenario class are privateend users or business users.

Mobile users might range from users usinglaptops connected via some wireless network(WLAN, Bluetooth) to an Intra- or Internet, tousers of PDAs and cell phones (utilising GSM,GPRS, UMTS) and combinations thereof.

Depending on the used mobile devices the usedWeb Services need to account for small memory

footprints. Additionally the exchanged amountsof information and SOAP messages cannot betoo large, because of limited communicationspeeds.

As a further consequence of the limited memoryfootprints, it is conceivable that applications onthe mobile devices will be pre-determined inadvance and not via some UDDI registry dy-namically, since the latter would require dynam-ical binding and hence additional applicationcode on the mobile device.

Further dependencies originate from the mobilecontext, such as connections that are temporarilylost due to “radio holes”, situations where themobile net is too crowded (at “hot spots” suchas airports, etc.) or where no access network isaccessible.

9 Other ScenariosIn this article several general scenarios havebeen described, which can be of interest toTelcos in general. These scenarios are eitheralready realisable today or will be in the nearfuture. In addition to these, there are also a num-ber of other possible scenarios, which will onlybe mentioned briefly in this section.

Web Services HubA Web Services Hub can be considered as akind of “Web Services marketplace”, whereWeb Service Providers offer their Web Servicesvia a marketplace model. More precisely theWeb Services Hub could be a combination ofWeb Services Broker and Web Services Infra-structure Services for closed customer/suppliergroups, forming an important intermediate stepon the road to “dynamic business webs”. A WebServices Hub will most likely evolve from usualmarketplaces, by extending them with Web Ser-vice functionality. An important factor for suchan evolution will be the customer and supplierbase of existing marketplaces.

Web Services Trust CenterOn the road to establishing automatic e-Businessvia Web Services several major obstacles needto be overcome. While the technical obstaclescan be overcome quite easily, the discussion ofsolutions to other obstacles (e.g. automatic con-tracting and establishing trust) has not yetstarted. An interesting scenario might arise ifthe Web Services Broker extends its registry byvalue added services, which are used to “moni-tor”, “measure” and “judge” the QoS of WebServices. This information is an important stepon the way to the establishment of trust in theform of service level certificates between two(as yet) unknown business partners, which canbe sold and used for marketing purposes as well.


DBW (Dynamic Business Webs)Infrastructure ProviderEven though the ultimate vision for Web Ser-vices, i.e. Dynamic Business Webs, has not yetbecome a reality, it contains the scenario of a“DBW Infrastructure Provider”. This will pro-vide the required infrastructure for DBWs,where brokerage and infrastructure services areavailable for anybody and any application toperform dynamic business. Appropriate WebServices are searched for in a registry whenneeded and new business contacts are formeddynamically. Contracts are negotiated com-pletely automatically, and Web Services areused to handle business transactions on a “pay-per-use” basis. Although this scenario is stillquite unattainable, it seems to comprise the sce-narios of Web Services Provider, Web ServicesBroker, Web Services Infrastructure Services,Web Services Hub and Web Services TrustCenter, where a Telco would act as a full serviceprovider or “one stop shop” for the DBW envi-ronment.

10 ConclusionAs has been shown in this article, a number ofWeb Services scenarios will be relevant toTelcos in the near future. They can use thesetechnologies in order to integrate enterprisesolutions and legacy systems internally or theycan take on various roles in a B2B context. Theycan also get involved in Web Services provisioneither as a Web Service Wholesaler, Retailer orBroker or offer added value services to otherWeb Services actors, for example by offeringWeb Services Infrastructure Services. Eitherway, there are great opportunities related to theemergence of Web Services, and Telcos shouldconsider carefully how to best take advantage ofthese opportunities.

References1 Google. November 13, 2002 [online] – URL:

http://www.google.com

2 Amazon.com. November 13, 2002 [online]– URL: http://www.amazon.com

3 Primordial – WSBANG. November 13, 2002[online] – URL: http://www.primordial.com

4 Grand Central Communications. November13, 2002 [online] – URL: http://www.grandcentral.com

5 Flamenco Networks. November 13, 2002[online] – URL:http://flamenconetworks.com

6 Talking Blocks. November 13, 2002 [online]– URL: http://www.talkingblocks.com

7 A Reference Architecture for smart Web Ser-vices. November 13, 2002 [online] – URL:http://dcb.sun.com/practices/devnotebook/webserv_refarch.jsp

Telektronikk 4.2002

1 Introduction

1.1 Business to Business (B2B) andBusiness to Consumer (B2C)

Electronic Business has existed for some timewhere the best known standard is the UN/EDI-FACT standard, which today is used by manybig businesses. The UN/EDIFACT standard hasnot been a great success, mostly due to the highcost related to implementation and the limitedreach for interoperability. The introduction ofthe Internet has opened for world-wide inter-operability at a low cost, and has therefore againput the focus on electronic business and elec-tronic commerce.

In B2B the market has been dominated by costlyproprietary technology, and in B2C the view hasbeen that electronic commerce is just buyingfrom a catalogue over a web interface.

The trend today is that B2B is being standard-ised and that the content is coded into XMLmessages that can be interpreted by both humansand machines.

If this turns out to be a success all kinds of busi-nesses (big or small) can do electronic com-merce world-wide over the Internet at low cost.The Internet and XML are therefore key factorsto make this happen.

For electronic commerce we usually talk aboutB2C and B2B where B2C means commercebetween an end consumer and an enterprise whileB2B means commerce between different enter-prises. Both B2C and B2B are therefore part ofwhat we call Electronic Commerce, and enter-prises that want to do B2C or B2B must satisfycertain requirements for Electronic Business. Theenterprises operate in different business areas,where the telecom business is one area.

The information to be exchanged between enter-prises can be very special to one business area(vertical) or common to many business areas(horizontal).

For enterprises to be able to do B2C and B2Bthey must turn into electronic businesses. Enter-prises today are run with a combination of man-ual and automated processes seen as processesinside an enterprise, between different enter-prises, and between an enterprise and an end-consumer. A trend in electronic commerce is tomake the business more cost effective and suitedfor electronic commerce by automating many ofthe required processes, both internally in anenterprise (EAI) and between different enter-prises (B2B), ref. Figure 1. This procedure hastoday started in many big businesse areas, alsoamong telecom operators like Telenor.

1.2 B2BThird Parties are companies specialized in func-tions required by the seller or buyer to completethe trades, e.g. Security or Financial services,ref. Figure 2. In a B2B context both Buyer, Sellerand Third Party are companies using internalprocesses to run the trade. In a telco context onesuch internal process can be the Billing System.

This again means that the B2B collaboration hasto be integrated with the companies’ internalprocesses. It is a very big issue in electronicbusiness how to integrate B2B collaborationwith back-end processes (internal systems).

Today the focus is as follows:1 B2B Standards

Forums like RosettaNet, ebXML and OASISare making common standards for B2B col-laboration.

2 Modeling Internal ProcessesThe internal processes should be modeledsuch that they can be connected to B2B inter-faces.

Forums like TeleManagementForum is doing abig job with their eTOM/ngOSS approach, andthere exist different kinds of vendors deliveringEAI technologies.

Web Services will be an excellent technologyfor EAI, but also in a B2B context.

XML in Electronic Commerce andElectronic BusinessS V E I N T O R E J O H N S E N A N D B E R N A R D Q U A R R E

Svein Tore Johnsen (60) gradu-ated from NKI Technical Collegewith Electronics and Cybernet-ics in 1969 and from HerriotWatt University, Edinburgh withComputer Science in 1975, andis currently Senior ResearchEngineer at Telenor R&D. Heworked as consultant and pro-ject manager in different indus-try segments and joined Telenorin 1984 where he has beenworking with TMN for manyyears both in internal projectsand in EU and EURESCOM pro-jects. He has been Telenor pro-ject responsible for EURESCOMproject P1106 and is at presentworking in EURESCOM projectP1209 (XML Web Services).

[email protected]

Figure 1 From automated processes to electronic commerce

Bernard Quarre (61) graduatedfrom Paris Technical College in1965 with aeronautical engi-neering and obtained his M.Sc.from the University of Sher-brokke, Canada in 1966 inautomation theory, and is cur-rently Senior Research Engineerat Telenor R&D. Quarre hasworked as chartered engineerin Peugeot, Paris and in Com-putas Simulation tools. Hestarted working with Telenor in1984, where he has been work-ing on management aspectsrelated to ATM-based broad-band networks. He has beeninvolved in several Europeanprojects and his research inter-ests include both lower andupper level of the TMN (NEM-BM) [email protected]

AutomatedProcesses

RunsElectronicBusiness

RunsElectronicCommerce

80


1.3 Structure of the DocumentAfter having listed out the different initiativesfor enabling B2B Integration, the most completeof them, ebXML will be described.

2 eCommerce StandardizationInitiatives

For organizations that conduct electronic busi-nesses with partner organizations, it is importantto see how Web Services would blend into pro-viding support for XML vocabularies likeebXML, RosettaNet, cXML, etc. For Web Ser-vices to be used effectively for enabling B2BIntegration, the Web Services platforms needto address common XML dialects, translatebetween dialects via XSL, security, complianceto contracts, etc.

2.1 ebXMLebXML is an open e-business initiative startedby UN/CEFACT and OASIS. Its aim is to makeit easier for companies of all sizes and locationsto conduct business on the Internet. The group iscurrently focusing on the specific needs of busi-ness-to-business (B2B) and Internet security asit relates to XML.

The specifications include a way to register anddiscover companies, business processes andrelated messages and content (registry andrepository), a way to form trading partner agree-ments (collaborative partner agreement), and amessaging specification (ebXML MessagingService).

ebXML may seem as an alternative to Web ser-vices, but it is more accurate to say that ebXMLprovides a necessary context or frameworkwithin which Web service technologies can beapplied.

After the intellectual property rights to theSOAP specification were released in May 2001,ebXML Messaging Service was merged withSOAP to create a messaging protocol that usesthe SOAP envelope but also adds ebXML speci-fications that cover areas left out in the SOAP

specification. The CPP provides the same infor-mation as WSDL and more, such as the role ofan organization in the context of a particular ser-vice, error-handling and failure scenarios. Like-wise, information published on the ebXML Reg-istry Service covers the same as that publishedon the UDDI registry, but more. Both systemscan be used complementary, with the UDDIentry referring to Web services in the ebXMLRegistry.

The ebXML framework is designed in such away that it is possible to exchange non-ebXMLpayloads within the framework. This because inthe real world today there are different kinds ofpayloads in use. As part of the ebXML standardsdevelopment process, a parallel stream known asthe Proof of Concept team was established toimplement ebXML specifications as they wereemerging. It is therefore not only legitimate to ex-change non-ebXML payloads within the ebXMLframework, it is encouraged, ref. Figure 3.

The ebXML framework will incorporate theSOAP and SOAP Messaging with Attachmentspecifications into its upcoming releases. Build-ing the messaging infrastructure of ebXML ontop of SOAP will give SOAP another sign ofindustry-wide acceptance.

2.2 RosettaNetRosettaNet is a vertical e-business frameworkfor IT hardware and software vendors. The orga-nization is set up by leading IT companies todefine and implement a common set of standardsfor e-business. RosettaNet defines a commonparts dictionary so that different companies candefine the same product the same way. It alsodefines up to 100 e-business transaction pro-cesses and standardizes them. Because Rosetta-Net is supported by all or most of the majorcompanies in the IT industry, its standards areexpected to be widely adopted.

RosettaNet has developed a structured four-partapproach for creating what it calls Partner Inter-face Processes (PIPs).

Figure 2 A simple figure showing B2B and B2C in a commerce context

ActorWholeseller

NetworkProvider

B2Bcollaboration

Actor3.part

B2Bcollaboration

ActorEnd-client

Broker

Actorretailer

NetworkProvider

Organisation A

Organisation C

Organisation BOrganisation A

Seller Seller Seller +Buyer

+interm ediary


1 Business Process Modeling examines com-mon business procedures and defines the com-ponents of the processes.

2 Business Process Analysis analyzes the pro-cesses and defines a target list of desirablechanges to the processes.

3 PIP Development establishes guidelines anddocumentation for the changes.

Dictionaries consist of two data dictionaries: atechnical properties dictionary and a businessproperties dictionary. Along with the RosettaNetImplementation Framework (which defines anexchange protocol for PIP implementation), thedictionaries form the basis for PIP development.

RosettaNet’s more than 40 members includeMicrosoft, Netscape, 3Com, Toshiba America,Compaq, CompUSA, Hewlett-Packard, IBM,and Intel. Its name refers to the Rosetta Stone, astone on which Egyptian hieroglyphics were alsowritten in other languages, making it possible todecipher the hieroglyphics. Rosetta stone has themore general meaning of “something that pro-vides a key to understanding”. The organiza-tion’s slogan is “lingua franca for eBusiness”.A lingua franca is a common second language,such as English for countries in the industrial-ized world whose first language is not English.

2.3 cXMLcXML is an open, versatile language designedfor B2B e-commerce, to be used in e-businessapplications.

cXML transactions consist of documents whichare simple text files containing values enclosedby predefined tags. Most types of cXML docu-ments are analogous to hardcopy documents tra-ditionally used in business. The most commonlyused types of cXML documents are catalogs,punch outs and purchase orders.

From the start in February 1999, the cXML stan-dard has been available for all to use. It lever-ages XML, and is supposedly extendable initself. It is not yet compatible with the SOAPprotocol.

2.4 xCBL and UBLThe XML Common Business Library is an XMLcomponent library for business-to-businesse-commerce. It contains a collection of schemasdefining common business processes such as:purchase orders, invoices, product descriptions,and shipping schedules.

xCBL, previously CBL, began as a research pro-ject at Veo Systems in 1997. CBL was devel-

oped to test the limits of XML for e-commerceand to identify requirements for XML design,development, and transaction tools and plat-forms. The first object-oriented XML schemalanguage – SOX, the Schema for Object-Ori-ented XML – was a result of the lessons learnedin the first version of CBL.

On October 17, 2001, OASIS announced theforming of the UBL technical committee. It wasalso stated that xCBL would be the starting pointfor the work. Specifically the UBL Charter statesthat the UBL Technical Committee will ...“Begin with xCBL 3.0 as the starting point ... todevelop the standard UBL library by mutuallyagreed-upon changes to xCBL 3.0 based onindustry experience with other XML businesslibraries and with similar technologies such asElectronic Data Interchange”. In many ways,the results of UBL are likely to be similar toxCBL but based on the input of many more indi-viduals.

As UBL is starting with xCBL, it is likely tohave many similarities with xCBL. This meansthat mappings from xCBL to UBL will probablybe easier than from any other document stan-dard.

3 The ebXML FrameworkThe ebXML initiative was an 18-month project,concluded in May 2001, to develop a set of spec-ifications for electronic business interoperability.It is one of the most ambitious and importantspecification development efforts in its field inrecent times.

Several hundreds of people have been activelyinvolved in ebXML as contributors to the dis-tributed multinational development teams thatworked on the specifications, and several thou-sands of people were subscribed to one or moreof the mailing lists through which the teamscommunicated and obtained feedback on theirdrafts.

Further work on ebXML is now taken over byOASIS and UN/CEFACT where OASIS is a notfor profit member based organisation that identi-fies, builds and maintains industry-standardspecifications for interoperability and UN/CEFACT is the United Nations Center for TradeFacilitations and Electronic Business.

The ebXML framework can be considered asevolutionary rather than revolutionary. It repre-sents the state-of-art in e-business architecture,addresses the issue of integration at a high level,namely the level of public process interface, andsupports the public process management appli-cation pattern.


The ebXML specifications are not a functionaldescription of en e-business integration product.They are specifications that enable interoperabil-ity of software products (especially at the mes-saging level) and provide high-level systemsconfiguration information (especially the proto-col agreement and business process layer). Thismeans that developers can use a variety of mid-dleware products to implement an ebXML-com-pliant system.

3.1 ebXML Main Requirements.The most important requirements ebXMLframework tries to satisfy are:

• Globalisation; facilitating international trade,towards a single “global electronic market”;

• Interoperability;

• Security; confidentiality, authenticity,integrity, non-repudiation.

For interoperability purposes, the introduction ofthe ebXML framework can be done gradually,because it makes possible the coexistence withother standards. It is of special importance tokeep the payload interchanged between compa-nies independent of the way the information iscontrolled. In other words, the ebXML frame-work does not mandate the use of ebXML mes-saging service for its payloads. The use of a flex-ible enveloping technique allows ebXML com-pliant messages to contain payload specified bylegacy e-business systems employing traditionalsyntaxes like EDI FACT and SWIFT [1].

The sequence diagram in Figure 3 shows a sce-nario where several trading partners are engagedin a procurement process. All partners supportan ebXML compliant infrastructure, but for bi-lateral collaboration, two partners use differenttypes of message content.

Figure 3 Partners involvedin an ebXML compliant

infrastructure exchangingnon ebXML payload

Seller : Seller Net Market :Net Market

Buyer : Buyer Payment Authority :Payment Authority

Buyer Bank :Buyer Bank

Seller Bank :Seller Bank

OAG

Web form

Purchase Order

PO Ack

Invoice

ASN

Invoice Response

X12

PaymentAuthorization

Bill

Financial Settlement

Place Order

Catalog Download

Catalog Update

SWIFT



ebXML

AIAG XML XML

RosettaNet


3.2 ebXML Overall ArchitectureThe ebXML framework consists of seven maincomponents:

1 ArchitectureThe ebXML archtecture can be used also for nonebXML payload.

2 Business Process specification Schema (BPSS)BPSS is an XML based specification languagethat formally defines “public” business pro-cesses. The BPSS is strongly influenced byUMM, a modelling methodology developedby UN/CEFACT [2].

3 Core ComponentsProvides business information encoded in busi-ness documents that are exchanged betweentrading partners [4].

4 Registry/RepositorySpecifies a general-purpose registry/repositoryfor registration/storing company Business Pro-files, and collaboration details to be used in elec-tronic contracts and business transactions [5].

5 Collaboration Protocol Profiles and AgreementXML documents that encode a party’s e-busi-ness capabilities (CPP) or two partners’ e-busi-ness agreements (CPA). They are closely relatedto BPSS [7].

6 Messaging Services (ebMS)Provides an elegant general-purpose messagemechanism using SOAP with attachment [8].

7 SecurityTopic that is pervasive to all components and iscritical for a production e-business system.

Figure 4 illustrates a scenario showing schemati-cally how the ebXML architecture enables e-business between two parties: Company B issupposed to have already implemented thee-business according to ebXML architecture.Company A wants to do such kind of implemen-tation to be able to conduct e-business with othercompanies like Company B.

3.3 Relationship Between theDifferent Components

The different components listed above are rele-vant in the different steps. Figure 5 shows therelationship between them.

• Step 1: Global information: Definition, speci-fication, design, registration of the commonmodel for business process and the commonsemantic for the data to be exchanged.

• Step 2: Each party: design, specification,registration of own business.

• Step 3: Agreement between two partners:discover each other, make agreement, preparecollaboration, configuration of e-businesssystem.

• Step 4: Engage bilateral collaboration betweenpartners.

Figure 4 High level overviewof the interaction of twocompanies conductinge-business using ebXML

Agree on Business Arrangement

Download Scenarios and Profiles

5

Business ProfilesBusiness Scenarios

ebXMLRegistry

COMPANY BDO BUSINESS TRANSACTIONS

ebXML compliantsystem

6

Query about COMPANY A Profile

4

Register Implementation DetailsRegister COMPANY A Profile

3

Request Business Details

1XML

COMPANY A

Build Local SystemImplementation

2


3.4 The ebXML Business ProcessSpecification Schema (BPSS)

The BPSS is one of the most innovative sectionsof ebXML Specifications [2]. At a high level, aBPSS instance specifies all the business mes-sages that are exchanged between two businesspartner roles, their content, and their precisesequence and timing. As such it is the direct linkbetween the business analysts or subject matterexperts that define the business processes, andthe implementers that use these specificationseither to configure their ebXML infrastructure,or write the appropriate code to enforce allaspects of the business process.

The relationship between the UMM metamodeland the ebXML BusinessProcess SpecificationSchema is shown in Figure 6.

Using the UMM methodology, and drawing oncontent from the UMM Business Library a usermay create complete Business Process and Infor-mation Model conforming to the UMM meta-model. Since the ebXML Business ProcessSpecification Schema is a semantic subset of theUMM metamodel, the user may then in an auto-

mated fashion extract from the Business Processand Information Model the required set of ele-ments and relationships, and transform them intoan ebXML Business Process Specification con-forming to the ebXML Business Process Specifi-cation Schema.

The architecture of the ebXML Business ProcessSpecification Schema consists of the followingfunctional components:

• UML version of the Business Process Specifi-cation Schema;

• XML version of the Business Process Specifi-cation Schema;

• Production Rules defining the mapping fromthe UML version of the Business ProcessSpecification Schema to the XML version;

• Business Signal Definitions.

Together these components allow you to fullyspecify all the run time aspects of a businessprocess model.

Figure 5 The different ebXMLcomponents involved in the

different steps

Business ProcessSpecification

(BPSS)

CoreComponent

Registry Repository

registerretrieval

registerretrieval

Business and information modelDescribed according to metamodel

retrieval and modeland profiles

Business ServiceInterface

Interm BusinessApplication

Messagingservice

PackagingRouting

Transport

Business ServiceInterface

Interm BusinessApplication

Messagingservice

PackagingRouting

Transport

Payload

configure configure

Transactions

RegistryInterface

RegistryInterface

Implementers

CollaborationProtocol Profile

CPP

CollaborationProtocol Profile

CPP

govern

Global

Party A Party B

Step 1:Define/register/findsuitable businessprocesses

Step 2:Each partyimplements & registersits own properties

Step 3:Both parties negotiateagreement, ready to beengaged in a collaboration

Step 4:Conduct ebXML business

CollaborationProtocol Agreement

CPA

SOAP Envelope


The BPSS metamodel allows the description ofbusiness processes as distributed processingbetween loosely coupled systems. Figure 7 illus-trates the relationship between the different com-ponents of the metamodel as a solution to inte-grate business partners. The BPSS allows thedescription of the collaboration between twopartners in a generic way: the binary collabora-tion consists of:

• Activities involved include:- Transaction activity (T activity): conducting

a Business Transaction (BT)

- Collaboration activity (C activity) (re-usingof activities: recursive property)

• Business Transactions (BT) between rolesdefining the exchange of document (doc)

• Roles: initiating role, responder role

• Collaboration activity: choreography of activ-itities. It defines a “public” business processwhich has to be mapped with private pro-cesses of the corresponding partners.

It should be noted that the concept of multipartycollaboration is covered by ebXML, but it isdefined as a synthesis of binary collaborations.

The ebXML Business Process SpecificationSchema provides a standard framework for busi-ness process specification. As such, it workswith the ebXML Collaboration Protocol Profile(CPP) and Collaboration Protocol Agreement(CPA) specifications to bridge the gap betweenBusiness Process Modeling and the configura-tion of ebXML compliant e-commerce software,e.g. an ebXML Business Service Interface, asdepicted in Figure 5.

3.5 Core ComponentsebXML defines a core component as a “buildingblock that contains pieces of business informa-tion, which go together because they are abouta single concept” [4]. Core components arereusable pieces of business information, hori-zontal to many business processes. Examples ofcore components could be things like “BusinessParty Details” or “Data of Purchase Order”.

The reusability is achieve by taking in accounttwo main issues:

Figure 6 Relationship betweenUMM Metamodel and ebXMLBusiness Processes/Core Components

UMM

Business Process &Information Model

Methodology Business Process& Information

Modeling

Metamodel

ebXML

Business Signal Definitions

W3C

Specification Schema(XML)

Business Process (BP) Specification metamodel

BPspecification

Documentspecification

CPACPP

Business Process Information

DTDSpecification Schema

(UML)Production

Rules

Core Component (CC)DocumentMetamodel

CoreComponents

BusinessDocumentDefinitions


• The context: CC is context free: A core com-ponent can be used across several businesssectors.

• The domain: CC is domain related: a corecomponent can be re-used by another industryarea if it is found to be appropriate for theiruse.

The context gives the relationship between CoreComponents (CC) and Business InformationEntities (BIE). The context is related to / derivedfrom the Business Process.

Figure 8 illustrates schematically how core com-ponents can be built into business documents.

A Core Component (CC) is a building block forthe creation of a semantically correct and mean-ingful business information exchange ‘parcel’,containing the information pieces needed todescribe a specific concept. There are three cate-gories of Core Components:

• Basic Core Component• Core Component Type • Aggregate Core Component

A Business Information Entity (BIE) is a pieceof business data or a group of pieces of businessdata with a unique business semantic definition.A Business Information Entity can be either aBasic Business Information Entity (BBIE) or anAggregate Business Information Entity (ABIE).A Basic Business Information Entity is based ona Basic Core Component (BCC). An AggregateBusiness Information Entity is a re-use of anAggregate Core Component (ACC) in a speci-fied business context.

Figure 9 describes the Business InformationEntity types and shows relationships to the CoreComponent counterparts.

A Naming Convention is necessary to gain con-sistency in the naming and defining of all CoreComponents and Business Information Entities.The resulting consistency facilitates comparisonduring the discovery and analysis process, andprecludes ambiguity, such as the creation ofmultiple Core Components with different namesthat have the same semantic meaning.

C activity

T activity

T activity(q)

End

Initiating role Responder role

chor

eogr

aphy

StartCollaboration activity

Initiating role Responder roleEnd

Start Collaboration activity

chor

eogr

aphy

C activity

T activity(r)

T activity

Partner A Partner B

binary Collaboration (recursivity)

binary Collaboration (bC)

Business Transaction (BT)

Business Transaction (BT)

doc

doc

doc

Figure 7 BPSS describingBusiness processes

Business documentin a particularcontext

Documentpart in aparticularcontext

ContextAggregate

Component 1Component 2

Figure 8 Business document structure


Common Normative Normative EDIFACT X.12 Rossetta- C11 OAG BODbusiness category sub-category Net PIPprocess

Manage Procurement Procurement ORDCHG, 860, 852, PIP3A4 0410, 0411 004_Acknowledge_PO_005Purchase Order Management ORDERS, 850, 865, 056_Add_PO_005(Create/Change/ ORDRSP 875, 876 058_Cancel_PO_005Cancel and 057_Change_PO_004Accept PO) 010_Get_PO_005

054_Getlist_PO_004055_List_PO_004

Table 1 Example of CBPcross reference table

Catalog of Core Components and CommonBusiness ProcessesThe catalog of Common Business Processes(CBP) [3] is useful for discovery and analysis ofcore components that will be used as the build-ing blocks for deriving business documentswithin a given context. This can be done bychecking all sources of documents listed andcross-referenced on the Common Business Pro-cess Catalog to identify a document that mayhave the information needed.

Table 1 shows an example of how CommonBusiness Process “Manage Purchase Order” isshown in the Catalogue and its relation to otherstandards.

The Common Business Process is structured asa cross reference table with the following com-ponents:

CoreComponent

Type

Message /Document

AggregateCore

Component

BasicCore Component

Basic BusinessInformation Entity

CORE BUSINESS

is of type

is defined incontext as

contained in

Aggregate BusinessInformation Entity

is defined incontext as

contained in

contained in

contains / iscontained in

Core Component Library

Figure 9 Relationshipsbetween Core Components andBusiness Information Entities


Common Business ProcessesA business process describes in detail how trad-ing partners take on roles, relationships andresponsibilities to facilitate exchange of infor-mation. Common Business processes are identi-fied as commonly used across various organiza-tions, industries or other business entities.

Normative CategoryBuilt from components of a Porter Value Chain,see Figure 10.

Normative Sub-CategoryDecomposition of the Porter Component intological sub groups.

EDIFACT/X12/CII/OAG BOD/xCBLCommon industry standards used as a cross-ref-erence, by identifying their specific equivalentbusiness documents commonly used today.

RosettaNet PIPCommon business processes cross-referenced tobusiness transactions as specified by RosettaNetPartner Interface Processes™ (PIPs™) whichdefine business processes between trading part-ners.

3.6 Registry/RepositoryThe ebXML spefication’s goals are that of creat-ing a platform independent open registry/reposi-tory for housing the description and facilitatingthe exchange of business artifacts, and discover-ing business via collaboration profiles. The reg-istry contains the descriptions of these businessartifacts (like the index of a book), and therepository actually stores them (like the book’sactual content).

The Registry Information Model (ebRIM) pro-vides information on the type of metadata that isstored in the Registry as well as the relationshipsamong metadata. The relationships are industryontologies providing a structured coded vocabu-lary, making a significant enhancement to cur-rent glossary-based mechanisms.

3.6.1 Registry Information Model (RIM)The ebXML Registry provides a key to newfunctionality using the RIM information tree,which can be navigated based on businessdomains and required business functions. Notethat the information model is not modelingactual Repository items [6].

A short meaning of the main classes is given inTable 2.

Figure 11 summarizes the structure of the Reg-istry and the relationship with the Repository.

3.6.2 Registry ArchitectureThe ebXML Registry architecture consists of anebXML Registry and ebXML Registry Clients[5]. The Registry Client interfaces may be localto the registry or local to the user. Figure 12shows the relationship between the differentinterfaces.

There are several possible topologies supportedby the registry architecture with respect to theRegistry and the Registry Client as shown inFigure 13.

Figure 10 Graphicalrepresentation of thePorter Value Chain

procurement transportation

humanresources

manufacturing

customer service

financing

marketing& sales

procurement

$$ $$

$$

raw materials

labor

labor labor

deliv

ered

raw

mat

eria

ls

man

ufac

ture

dgo

ods

deliv

ered

man

ufac

ture

d go

ods

product

services

facilities, services& technology

labor

RegistryObject Top Class

User

AuditableEvent log all event (client initiated request) as instance

RegistryEntry Provide an access to all instance in the registry

ExtrinsicObject Describes content whose type is not known to Registry

IntrinsicObject Describes content whose type is known to Registry

Package Gouping in logical entities

Organization Info about submitting organisation

Classification Define tre structure

ExternalLink Define all what is not content in the registry

Table 2 Main classesin the RIM


Figure 11 Overview over exXMLRegistry/Repository

Figure 12 ebXML Registry Interfaces

Figure 13 Different topologies supported

Registry EntryUIDCommon NameSubmittingOrganisationDescriptionObject TypeVersionStatus........

ClassificationsNAICS/UNSPSCCountryGoverment agencySport category

AssociationsUID validates to UIDContainsSupercedesUsers....

AlternativesNameDescription

Repository

CPP

Instances

packages

Schemas

graphics

UML...

External links

<<Interface>>ObjectManager

<<Interface>>ObjectQueryManager

<<Interface>>RegistryService

<<Interface>>RegistryClient

Object Create,Update. Delete

Object query

and retrievel

Repository

ebXMLRegistry

Registry Interfaces

Registry Client Interfaces

Internet

The Registryprovides the Clientinterfaces to allUsers via a web baseduser interface

User accessing the Registryusing common web browser

Repository

ebXMLRegistry

The Client interfacesare provided by theclient and not theregistry. The clientmay be a RegistryBrowser application

User accessing the Registryusing a Registry browser thatcontains the Client interfaces

Internet

Registry Client Interfaces

Registry Interfaces


Conformance as an ebXML RegistryAn implementation conforms to this specifica-tion as an ebXML registry if it meets the follow-ing conditions:

1 Conforms to the ebXML Registry InformationModel [ebRIM].

2 Supports the syntax and semantics of theRegistry Interfaces and Security Model.

3 Supports the defined ebXML Registry DTD.

4 Optionally supports the syntax and semanticsof Section 8.3, SQL Query Support.

Conformance as an ebXML Registry ClientAn implementation conforms to this specifica-tion as an ebXML Registry Client if it meets thefollowing conditions:

1 Supports the ebXML CPA and bootstrappingprocess.

2 Supports the syntax and the semantics of theRegistry Client Interfaces.

3 Supports the defined ebXML Error MessageDTD.

4 Supports the defined ebXML Registry DTD.

3.7 Collaboration Protocol Profilesand Agreement

The Collaboration Protocol Profiles/Collabora-tion Protocol Agreement (CPP/CPA) specifica-tion [7] is the implementation of trading partneragreements in the ebXML framework. The termtrading partner agreement (TPA) is a generalterm that can cover both technical and businessrelated agreements, or a combination of boths.The ebXML, collaboration protocol agreements(CPA), are the machine interpretable versions ofsuch TPAs. One can think of such a CPA as thebridge between the transport (messaging) layerand the business layer.

Figure 14 illustrates schematically how the Col-laboration-Protocol Profiles (CPP) are built.

The scenario in Figure 15 gives an overview ofthe Collaboration Protocol Agreements (CPA)and how they are built from CPPs.

What Businesscapabilitiesit can performwhen conductinga BusinessCollaboration withother parties

Party´s information- Party´s name- Contact infoTransport ProtocolTransport Security ProtocolMessaging ProtocolLink to Process-Specification documentTime out/Retry- etc.

BuildParty A

CPP

Describe

CPA IDParty’s information- Party A- Party BTransport ProtocolTransport SecurityDocExchange ProtocolLink to Process-Specification Doc.Retry- etc.

CPA

1

CPPFor

Party A

negotiate

AgreedCPA

Agree-ment onCPA hasarrived

3

2

CPPFor

Party B

negotiate

AgreedCPA

Agree-ment onCPA hasarrived

3

4 Start Business activities with each otherFigure 15 Overview of

building of CPA

Figure 14 Overviewof the CPP


Business Process and run the associated elec-tronic exchanges.

The document-exchange layer accepts a Busi-ness document from the Process Specificationlayer at one Party and passes it to the transportlayer for transmission to the other Party. It per-forms the inverse steps for received Messages.

The TRP gives the specification to the Messag-ing Service which comprises:

1 Message Service interface defines the opera-tions that local object needs to perform.

2 Message Service Handler (MSH) for interpre-tation of the ebXML messages.

3 Transport service interface for Adaptation/mapping to the transport layer.

4 The error handling for the report of errorsoccurring during the processing of a message.

Figure 16 shows the ebMS functionality in moredetail.

Against the “application layer”: This is done byusing SOAP (Simple Object Access Protocol)which allows access to services, objects, andservers in a platform-independent manner andfacilitates interoperability by bridging competingtechnologies in a standard way.

Against the “transport layer”: A transport inter-face allows the use of different protocols likeHTTP, SMTP, IIOP.

The ebXML message exchanged between part-ners is considered as an attached “SOAP enve-lope”. The way of attachment depends on thecommunication protocol chosen. Figure 17 illus-trates how the SOAP envelopes the ebXMLmessage.

3.9 SecurityWhen working with B2B frameworks such asebXML [1], we could agree that there is a funda-mental conflict between achieving the level ofopenness required to deal with a (potentiallylarge) number of parties, and achieving theappropriate level of security. A characteristicof B2B initiative is that they try to use Internet –a global communication infrastructure – as aglobal trading infrastructure. While this is defi-nitely a very challenging endevor in terms ofsize, scope and nature, history has shown that itis possible to successfully open up new traderoutes and find acceptable ways to deal with theassociated risks. ebXML will prove itself to beinstrumental in opening up these new digitaltrade routes; but in doing so, it is necessary to

ebXML Application

Message Service Interface

Err

or H

andl

ing

Transport Interface

SOAP Processing

Header Processing

Header Parsing

Message Packaging

Reliable Messaging Services

SecurityServices

HTTP FTP SMTP IIOP ...

Figure 16 The ebMSfunctionality

MIME Part(s)

SOAP with Attachments MIME Envelope

MIME Part

SOAP-ENV:Envelope

Payload(s)

eb:Manifest

eb:Etc...

other:Etc...

eb:MessageHeader

eb:TraceHeaderList

eb:Etc...

other:Etc...

SOAP-ENV:Header

SOAP-ENV:Body

Communications Protocol Envelope(HTTP, SMTP, etc.)

MessagePackage

HeaderContainer

PayloadContainer(s)

Figure 17Layout ofthe ebXMLmessage

The CPPs and CPA together with Process Speci-fication are registred in the ebXML registry.

3.8 Messaging Services (ebMS)ebMS, specified by ebXML OASIS, is a stan-dardized Messaging Service which enables aninteroperable, secure and reliable exchange ofmessages between two parties [8].

ebXML compliant software can be used toimplement eBusiness scenarios where two ormore partners are engaged in binary/multi-Party


implement a robust security strategy to protectthe business involved.

In an ebXML environment it is not just an indi-vidual element that needs to be secured; thewhole business process defines the securityneeds and the first step in solving security prob-lems is to analyze the risks; from this analysis, itis possible to determine what to secure and whatnot to secure. This characterises the approach tosecurity taken in ebXML. There is no attemp tosecure the whole business process 100 % – thatsimply is not feasible; instead security is basedon mutual understanding and agreements, com-ing up with an acceptable risk and adjusting thesecurity measures accordingly.

As shown in Figure 18 the Collaboration Proto-col Profile (CPP) contains the representation ofagreed security policy. It is created as a resultof mapping security policies and collaborationparameters onto the business process definition.

Thus the CPP contains the set of possible andrequired security measures from the own com-pany’s point of view, after mapping to the busi-ness process. It is the first step towards a fullpolicy-based security system

A key role in implementing security within theframework is the use of Trusted Third Parties(TTP). Security is often necessarily fully inte-grated into internal processes to be most effec-tive, however in the B2B realm, a clearer inter-section domain of shared governance is neededto enable security agreements to be reachedbetween trading partners. This issue is oftenignored because of the way security agreements

between trading partners have been developedhistorically, with confidentiality between parties.These agreements may often be reached on anad hoc basis and sometimes dictated by domi-nant market players. TTPs need to be imple-mented to overcome the poor definition of secu-rity generally in the B2B eCommerce environ-ment and will be essential for fully automatingsupply chains.

The following TTPs is seen as the primary secu-rity service providers for the near future:

• Identity Management• PKI Trust Service Providers• Trusted Time Stamp and Repository• Trading Community Registry and Repository• Outsourced OSS Component SLA manager• Third Party Security Audit• Fraud Management Services• Aggregated Trust Service Providers (for effi-

ciently combining security services)

4 Differences Between ebXMLand WS

4.1 The Web Services stackIn order to describe how Web Service standardsrelate to the above features it is useful to beginby looking at a representative Web Servicesarchitecture.

Web Services architecture [9] is built from lay-ers of technology and standards on which ser-vices can be implemented and deployed. Eachlayer on this Web Services stack depends on thelayers below it. There are many variations ofthis architecture, but each variation generally

SecurityPolicies Business

ProcessDefinition

CollaborationParameters

SecurityEnvironmentParameters

BusinessProcesses

BusinessService

Interfaces

BusinessMessages

TradingPartner

DefinitionEbXML

Repository

Business Process andInformation Meta Model

CollaborationPartner Profile (CPP)

Figure 18 Security in CPP


includes the features described in the previoussection above the basic messaging and servicedescription foundation layers.

The diagram in Figure 19 illustrates a genericWeb Services architecture and how it maps tospecific architectures from prominent organiza-tions or companies.

Figure 20 is an attempt at illustrating the simili-tude and the difference between WS referenceand ebXML. EbXML is broadening the tradi-tional Web Service view and can be regarded asthe Web Services for Electronic Business.

5 Towards an e2-OSSFramework for theTelecom Industry

The EURESCOM project P1106 [10] has triedto identify the impact the emerging Internet stan-dards like ebXML have on the way to do busi-ness in the telecom industries.

The main purpose of the e2-OSS Frameworkwas to define an “e-enabled” B2B context spe-cific for telecommunications industry. Thisshould cover at least Business, Functional, Tech-nology, Security aspects/dimensions and wouldallow for a B2B supply chain integration.

Agreements

Orchestration

Quality of Service

Service

Packaging/Transport

Generic Stack

CPA

BPSS

MSH(over SOAP)

ebXML

TPA

WSFL

WSEL

WSDL

SOAPD-SIG

HTTP-R

IBM

???

XLANG

???

WSDL

SOAPWS-RoutingWS-Security

Microsoft

BPML

BPMI

CPPCPP

CPA

Registry usingUDDI

EbXMLReg/Rep

Repository

Registryusing UDDI

RegisterStoreFind

RegisterStoreFind

using using

using using using using

PUBLISHFIND

SOAP SOAP

agreed

WSDL(WSCI)

WSDL(WSCI)

BPSS BPSS

MS MSUSEServer PartyA PartyBClient

USE

Figure 19 The differentlayers and thecorresponding standards

Figure 20 Similitudeand differencesbetween ebXMLand XML-based WS


During the project it has become clear that thegeneral B2B standards framework as outlined byDerek Coleman of RosettaNet is appropriate fore-Business Integration standards for communica-tions suppliers. The notions of where B2B inte-grations relate to Enterprise integrations from arequirements perspective was also clear.

However, two major issues hampered a morerigorous analysis of how B2B and EnterpriseIntegration could be aligned for the e2-OSSframework.

• Lack of content standards for the telecomsvertical document and process B2B standardswith which to work.

• Lack of understanding of appropriate patternsfor integration within the Functional ServiceView of any implementation.

The project has identified where guidelines areneeded for the further development of contentfor the e2-OSS framework and several learningpoints have been gained about the style andapproach to design B2B collaborations usingthe transaction patterns outlined in UMM.

Many of the defined PIPs available in Rosetta-Net form a useful basis for B2B patterns fortransactions to support telco processes for fulfil-ment and billing. However, RosettaNet’s rigiddefinition of content standards defined for thecomputing and components industry rendersthem inappropriate for direct use. The alternativeis to re-use the PIP blueprints with alternativecontent standards within an ebXML BPSS Col-laboration.

It is clear that additional transactions arerequired for communications supply chain inte-grations and a full Business Operations Map isrequired as a framework within which thisshould done.

The project had the intention of developing acommunications service provider value chainoperations map that is complementary to theTMF eTOM. Early attempts at this have yet toreveal what the structure for such a map shouldbe and this work remains to be done.

A large part of the project focussed on processmodelling and the relationship of processes tocomponents. This activity covered business pro-cesses, description languages, the use of a mes-saging service for B2B and the use of compo-nent services to achieve backend integration toOSS. However, a significant part of the frame-work relates to content and document standards.

An assumption throughout the project is thatB2B integration will be achieved by the ex-change of XML documents. Most likely thesedocuments would be defined using the W3Cschema definition language XSD. The issuehowever is the source of Business DocumentDefinitions and Business and Technical Dictio-naries.

Names for selected business documents havebeen suggested as a consequence of identifyingBusiness Transactions (e.g. Trouble Ticket).However no attempt has been made to definetheir content.

There are potentially several sources and app-roaches to the creation of B2B business docu-ments standards. The two major questions are:

1 Use statically defined business document defi-nitions or assemble B2B document instancesfrom components;

2 Purposely build B2B standards or re-use andextend Enterprise standards.

Table 3 outlines four possible sources of stan-dards, which typify the approach.

The ebXML group has not yet clearly definedwhat it regards as an appropriate strategy fordefining vertical technical content. Currently itis suggested that B2B Business Documents bebased on components derived from a global taglibrary as proposed to the ITU in the tML initia-tive. Furthermore, these documents should bederived from the same components as used forEnterprise Business Documents.

This would suggest the need for a set of OSS-JEnterprise Business Document Componentsusing the tags defined within the proposed tMLtag library structure.

Statically Defined Documents Dynamically Assembled

Public Standards RosettaNet DTDs ebTWG Core Components

Extension of Private Standards OAGIS BODS encapsulated in OSS-J XML value type API B2B document envelope encapsulated in B2B document

envelopeTable 3 Content Standards


In the short term (pending agreement of a tele-com specific library of business document com-ponents) the only practicable route forward forcommunications service providers is to use andextend published “horizontal” standards such asxCBL or OAGIS.

6 References1 Professional ebXML Foundations. Wros

Press, 2001.

2 UN/CEFACT & OASIS. EbXML BusinessProcess Specification Schema v.1.0.(Technical report) December 4, 2002[online] – URL: http://www.ebxml.org/specs/ebBPSS.pdf

3 UN/CEFACT & OASIS. Catalog of Com-mon Business Processes v.1.0. (Technicalreport) December 4, 2002 [online] – URL:http://www.ebxml.org/specs/bpPROC.pdf

4 UN/CEFACT. Core Component TechnicalSpecification v.1.7. 21 Oct 2001.

5 UN/CEFACT & OASIS. Registry ServiceSpecification v.1.0. (Project team Technicalreport) December 4, 2002 [online] – URL:http://www.ebxml.org/specs/ebRS.pdf

6 UN/CEFACT & OASIS. ebXML RegistryInformation Model v.1.0. (Technical report)December 4, 2002 [online] – URL:http://www.ebxml.org/specs/ebRIM.pdf

7 UN/CEFACT & OASIS. Collaboration Pro-tocol Profile and Agreement Specificationv.1.0. (Technical report) December 4, 2002[online] – URL: http://www.ebxml.org/specs/ebCPP.pdf

8 UN/CEFACT & OASIS. Messaging ServiceSpecification v.1.0. (Technical report)December 4, 2002 [online] – URL:http://www.ebxml.org/specs/ebMS.pdf

9 O’Riordan, D. Business Process Standardsfor Web Services. Tect.

10 EURESCOM project P1106 Deliverable 3.Aug & Sep 2002. (EDIN 0328-1106 &EDIN 0329-1106.)


BackgroundTraditionally, telcos have been vertically inte-grated companies selling their applications viatheir own retail divisions on their own whollyowned transport.

Where wholesale organisations existed theywere principally departments created to dis-charge regulatory requirements for intercon-nection.

However, globalisation, regulation and the emer-gence of new Internet and multimedia servicepropositions have led to the emergence of manyexternal businesses with the need for wholesalecommunications services (Figure 1). To meetthese commercial and regulatory demands, manylarge telcos have introduced unbundling of theirwholesale services which have become majorbusinesses in their own right (Figure 2).

These new business relationships betweenwholesale providers and their partners arereflected in the TeleManagement Forum’srevised Telecoms Operations Map (TOM –now known as eTOM) which has been updated

to reflect the emerging e-business relationshipsbetween service providers and their partnersin emerging communications service providervalue chains (Figure 3).

The difficulty for wholesale carriers is how towork within this new commercial model of fed-erated businesses of external partners and cus-

Electronic Gateways – Forging the Links inCommunications Services Value Chains*)

D E R R I C K E V A N S , D A V E M I L H A M , E L A Y N E O ’ S U L L I V A N A N D M A R T I N R O B E R T S

A growing business trend is Internet-based business-to-business (B2B) integration of trading partners in

the creation of end-to-end value chains.

The architectural approach to such integration is typified by industry initiatives such as RosettaNet (1)

and ebXML (2).

For wholesale communications service providers, such architectures provide the opportunity to integrate

a wide range of fulfilment, assurance and billing systems and processes such as those described in the

TeleManagement Forum’s eTOM (4) with those of their third-party operator, service provider and retailer

customers, partners and suppliers.

Dave Milham (54) is a graduateof Electrical Engineering fromImperial College of Science andTechnology and in telecommu-nications from Essex University.He works on technical strategyin the BTexact technologiesOSS engineering unit and isresponsible for the coordinationof BT’s contributions to the OSSactivities of the TeleManagementForum, ITU-T, EURESCOM, andthe IETF. He is chair for the TMFValue Chain Market Centre con-cerned with Telecomm B2B andmanages EURESCOM ProjectP1106 studying Telecomm B2B.He has been awarded the cov-eted TeleManagement ForumFellowship in recognition of hiscontribution to the industry overthe last [email protected]

Derrick Evans (42) graduated inPhysics from Imperial Collegeof Science and Technology in1981. He joined BT Laboratoriesthat year and has since workedon a variety of OSS softwaredevelopment and solutions inte-grations projects. Currently heis leading a team of consultantsspecialising in OSS solutionsdesign and delivery includingconsulting on business-to-busi-ness interface specification fortelecommunications servicesmanagement.

[email protected]

BroadbandAccess Provider

Sales andMarketing

End Users

Sales andMarketing

Sales andMarketing

Portals

Content, Data, InternetSupport Services

BroadbandInfrastructure

ISPs, ASPsE-commerce

Providers

End-Users

WholesaleOperator

Management ServiceProviders

OtherOperators

ResellersSales and Branding

Content and Application

Network Services

Figure 1 Emerging wholesale customers (Source (5))

Figure 2 Commercial separation of wholesaleservice (Source (5))

*) This paper has previously been published in The Journal of The Communications Network, Vol 1, Part 1,April–June 2002

Telektronikk 4.2002

tomers, while still retaining the efficiency andeffectiveness benefits of the process and systemsintegration they had enjoyed in the past as partof a larger self-contained and integrated business.

Over recent years, integrated carriers hadworked to improve customer service and containcosts through greater process efficiency andeffectiveness. This had entailed the improvementof business processes through re-engineering &the realignment of processes along customervalue chains through business transformation.Such processes were further enhanced with thesupport of integrated OSS applications such asCSS (BT’s Customer Service System), SwitchManager, and Work Manager (WMS).

The benefits of such integrated system and pro-cess support have been to provide customer ori-ented end-to-end visibility of service deliveryand assurance and varying degrees of flow-through automation for the less complex massmarket products.

The challenge is now to continue to provide suchvisibility and flow-through with wholesale trad-ing partners who do not and cannot share directaccess to such systems and have systems andprocesses of their own anyway.

In terms of process integration the eTOM (Fig-ure 4) suggests the additional processes requiredto manage the launch of new service proposi-tions and operate them in conjunction with trad-ing partners through integration of processesin the ‘Marketing and Offer Management’ and‘Supply Chain Development and Management’

layers for new product development and the‘Customer Relationship Management’ and‘Supplier/Partner Relationship Management’layers for operations.

However, the eTOM process map does not add-ress the systems support for such integration.

Figure 5 shows a number of approaches typi-cally deployed within BT to enable managementof the customer interface with the organisation’sOSS stack.

One approach is to create web-based eCRM(electronic customer relationship management)portals that provide partners with mediated webaccess to restricted views of customer and ser-vice information. This approach is typified byBT’s eCO CRM application for BT Wholesale’scustomers. While this approach provides visibil-ity via a rich graphical user interface, tradingpartners are still left with the problem of integra-tion of such information with their own informa-tion systems.

An alternative approach is to use B2Bi XMLmessaging gateways to exchange business infor-mation as electronic documents between part-ners’ systems across the Internet.

The remainder of this article focuses on theseB2B integration technologies and architecturesthat may be used to loosely integrate partners’support systems and processes to achieve somelevel of end-to-end process visibility and flow-through.

Martin Roberts (40) graduatedfrom University of Wales,Aberystwyth, having studiedComputer Science. On leavinguniversity he worked on real-time systems in the chemicaland manufacturing industriesbefore joining BT. Since joiningBT, Martin has worked on cus-tomer facing applications fromthe early days of CMIP inter-faces and currently is the archi-tect for the XML interfaces inuse within BT Wholesale. He iseditor of one of the UN/CEFACTebtwg projects and is a keycontributor to the ITU tMLinitiative.

[email protected]

Elayne O’Sullivan (25) gradu-ated from Cork (UCC) with adegree in Music prior to gainingan M.Sc. in Information Systemsfrom Cardiff. Elayne now workson OSS solution design withinBT specialising in the designand implementation of B2B XMLinterfaces for BT Wholesale.Elayne is also researching theapplication of ebXML developedmodelling techniques to thetelecommunications industry.

[email protected]

Third-PartyServiceProvider

Function orProcessSupplier

Hardware,Software,

Solution, etc.Vendors

Intermediary

Customer

Service Provider

Comple-mentaryProvider

Figure 3 Service provider relationships (Source TeleManagement Forum 2001)

98


B2B Integration Concepts andArchitecturesThere are a variety of approaches to the integra-tion of systems that can be categorised as follows:

• document exchange;• exposed application;• exposed business services;• managed public process (PIP/transaction); and• managed public and private process.

Each of these approaches reflects a stage ofdevelopment in the evolution of e-commerceand each has its merits and applications (7).They are defined below:

Document ExchangeThis is the classical approach adopted by elec-tronic data interchange (EDI) applications in-

Customer

Strategy, Infrastructure and Products

Strategy andCommit

Operations

InfrastructureLifecycle

Management

ProductLifecycle

Management

OperationsSupport andReadiness

Fulfillment Assurance Billing

Marketing and Offer Management

Service Development and Management

Resource Development and Management(Application, Computing and Network)

Supplier Chain Developmentand Management

Customer Relationship Management

Service Management and Operations

Resource Management and Operations(Application, Computing and Network)

Supplier/Partner Relationship Management

Strategic andEnterprisePlanning

Enterprise

Management Brand Management,Market Researchand Advertising

Stakeholder andExternal Relations

Management

Disaster Recovery,Security and Fraud

Management

Financial andAsset

Management

HumanResources

Management

Research andDevelopment,

Technology Acquisition

Enterprise QualityManagement, Process and

IT Planning and Architecture

Figure 4 Telemanagement Forum’s eTOM v2.5(©TeleManagement Forum, October 2001)

CRM eCRMPortal

B2BiGateway

IntegratedCSS

CMR• Support CSC agents• Sales and service care• Contact management

B2C• Customer self-service• Web-based presence• Extend range of contact

B2B• Integrating businesses• Document based• Trading partners

Figure 5 Access to integrated OSS applications


volving the asynchronous exchange of structuredand standardised files representing documentssuch as purchase orders and quotes (Figure 6).

In ‘traditional’ applications this exchange issecured through the use of EDI value added net-work services (VANS) closed user group basednetworks (although initiatives such as OBI hadmoved such EDI architectures to the Internet (6)).

The execution of the business logic to produceand exchange the documents through some formof agreed public process is often executed direct-ly by the target applications.

While this approach provides some decouplingof applications, increasingly this approach isseen as expensive to implement and inflexibleto change.

Exposed ApplicationWith the advent of customisable software appli-cations and the use of distributed applications,more and more applications have publishedapplication programming interfaces (APIs) thatcan be used by one application to invoke another(Figure 7).

When this style of integration is employedbetween business partners it is often securedthrough the use of virtual private networks. Alsoto deal with system availability issues, messag-ing middleware is often employed to decouplethe two applications.

While this approach can provide a very rich andfunctional integration between two parties, thedirect integration of applications in this mannermakes it very susceptible to changes in the app-lications of one party or another. Also one isreliant on trading partners using similar operat-ing systems and applications technology.

Exposed Business ServiceThe exposed business service approach providesadditional flexibility over direct API integrationby presenting simplified and abstracted versionsof APIs via small discrete units of code that han-dle specific limited functionality.

The interaction is secured over the public Inter-net using encryption and strong authenticationvia the use of digital certificates (Figure 8).

Also the differences in technology between trad-ing partners is dealt with by using an applicationneutral implementation of XML messaging overthe Internet http protocol in the form of a mecha-nism know as SOAP (Simple Object Access Pro-tocol) (8).

This approach is being widely promoted underthe name of web services and by Microsoft aspart of its .NET initiative (9).

While this approach is likely to achieve greatbenefits for business-to-business integrationthere are still issues to be dealt with in usingsuch technology widely.

The principal issues are ones of standardisationin two areas:

• security and reliability (including receiptedacknowledgement of transactions and howto handle timeouts and failures); and

• vertical standards for content and businessprocess enacted for particular industry seg-ments.

It is possible that the first of these two may beaddressed in enhanced forms of web servicesstandards in the future. However, stricter defini-tion of industry standard services would still berequired.

Managed Public ProcessesThis form of integration builds on the notion ofweb services (although RosettaNet, as an earlyexample of such integration, pre-dates SOAP).

Where this differs from the exposed businessservice approach is the industry standardisationof process and content for a defined set of busi-ness activities, such as the exchange of a pur-chase order request (Figure 9).

Application Application

Document

Figure 6 Document exchangebased inegration of applications

Application ApplicationApplication API

Application ApplicationInternet

Bus

ines

sS

ervi

ces

Bus

ines

sS

ervi

ces

Figure 8 Exposed business service integration

Figure 7 Exposed API integration of applications


Such business activities conform to a set of stan-dard patterns and involve not just the exchangeof business documents but also standard signalsto indicate the successful (or otherwise) execu-tion of a transaction to assure a reliable andsecure exchange.

The combination of a web services approachtogether with standardised content provides avery strong basis for the integration of tradingpartner processes on a transaction-by-transactionbasis over the Internet.

However, for some interactions there is also anend-to-end process or choreography of suchtransactions to be standardised and managed.A typical example would be the UK industryagreed unbundled local loop (LLU) provisioningprocess that involves a multi-step approach tothe provision of a metallic path.

Managed Public and Private ProcessThe managed public and private process form ofintegration is a further enhancement to Internet-based integration and deals with the need forselected B2B processes to be an end-to-endchoreography of transactions (Figure 10).

This approach allows one to define a secondlayer of process that links individual publicprocesses (RosettaNet PIPs or ebXML transac-tions). This layer can also be used to managethe end-to-end process across multiple internalapplications.

Such a process is typically implemented usingenterprise workflow applications with integra-tion into applications via enterprise integrationmiddleware. Such an EAI integration of multipleapplications is becoming common practiceamongst telcos (10), which adds further appealto this form of integration.

In the same manner that public processes need tobe defined and agreed with trading partners, the‘public face’ of such choreographies need to bepublished.

ebXML, amongst other things, provides a stan-dard for exchanging a description of such achoreography in the form of a collaborationwhich can be decomposed into low level activi-ties implemented by individual business transac-tions to exchange business documents betweenpartner roles (the Business Process SpecificationSchema (3)) as an XML based model.

With the addition of this process modelling tech-nique, the ebXML collection of standards formsthe basis for future evolution of web servicesbased integration of trading partners’ processesand systems.

ebXMLThe stated mission of ebXML is:

“To provide an open XML-based infrastruc-ture enabling the global use of electronicbusiness information in an interoperable,secure and consistent manner by all parties.”

ebXML is sponsored by UN/CEFACT andOASIS, and is a suite of specifications designedto enable enterprises of any size and in any geo-graphical location to conduct e-business over theInternet. As such, the emphasis has been on amodular implementation of the specificationson a variety of platforms and scales to fit allpockets.

The key specifications of ebXML were pub-lished in May 2001 and are:

• EbXML Requirements Specification v1.06;

• ebXML Technical Architecture Specificationv1.04 (the overall ebXML conceptual archi-tecture);

• Business Process Specification Schema v1.01(the schema for the exchange of B2B processdesigns);

• Registry Information Model v2.0 (the generalrepository for recording B2B processes andagreements);

• Registry Services Specification v2.0 (the APIdefinition for access to the registry);

• Collaboration-Protocol Profile and AgreementSpecification v1.0 (the format for the ex-change of trading partner profiles includingthe B2B services supported and the means offorming B2B agreements); and

• Message Service Specification v1.0 (the mes-saging protocol for the exchange of ebXMLbusiness documents).

Application ApplicationInternet

Pub

lic P

roce

ssA

pplic

atio

n

Pub

lic P

roce

ssA

pplic

atio

n

Figure 9 Managed publicprocess integration

Internet

Pub

licP

roce

ss

Pub

lic P

roce

ss

Pub

licP

roce

ss

Pub

licP

roce

ss

Pub

lic P

roce

ss

Pub

licP

roce

ss

Figure 10 Managed privateand public process


Of these specifications, the most commonlyimplemented one is the message service forwhich there are now version 1.0 implementa-tions from most B2B gateway vendors.

RosettaNet has also stated that the messagingservice for ebXML is a likely candidate for thenext generation of the implementation frame-work (RNIF V3).

Figure 11 describes the ebXML concept of mes-saging-based integration.

Each trading partner fulfils a role and executestheir respective business processes on their sys-tems and the activities of each partner are syn-chronised by execution of shared business trans-actions involving the exchange of business doc-uments (typically in the form of XML files) suchas purchase order requests and confirmations.

In addition to the exchange of business docu-ments, other messages are exchanged as signalsof successful execution of phases of a transaction.

The end-to-end sequencing of such transactionsand the conditional paths between each step aredescribed as collaboration within the businessprocess specification schema that may be visu-alised in a number of ways. A typical approachis to use an activity graph as shown in Figure 12.

Using a combination of standard business trans-actions and documents within such collabora-tions forms the basis for a wide variety of B2Bprocesses to be created in support for complexmultiparty supply chains not just for procure-ment but also for assurance and other telco pro-cesses.

Challenges Ahead

The ChallengesWhile the path set by the eTOM and ebXML isclear, there are many hurdles to be overcomebefore such architectures are widely adopted.

Apart from the messaging service the implemen-tations of the other ebXML standards are notwidely available. The ebXML messaging serviceis now undergoing (as of October 2002) its sec-ond phase of interoperability testing with 12vendors from around the world (13).

For selected ebXML standards (such as BPSS)there are competing alternative standards. Also,the wide promotion of web services and .net asthe answer to ebusiness is likely to confuse thegeneral marketplace as to the need for ebXML-based solutions. This will undermine confidencein investment in such standards and delay adop-tion until the market position is clearer.

Despite the efforts of ebXML, RosettaNet andothers to produce cost-effective architectures fore-business integration there is still significantcost in realising solutions based on technologies.In particular, the integration to legacy applica-tions and the understanding of how to translatebetween the published B2B document and pro-cess standards and individual partners’ owninternal arrangements add significantly to cost.

RequestingActivity

Responding Role

RequestingActivity

Responding Role

Success FailureNotification of Business Failure

Request Document

Receipt Acknowledgement Signal

Acceptance Acknowledgement Signal

Response Document

Receipt Acknowledgement Signal

Figure 11 Exchange ofbusiness documents andsignals in executing atransaction betweenpartner roles(Taken from (3))

Order BTA

Order Status BTA

Change Order BTA

Cancel Order BTA

Buyer Seller

Figure 12 Example list ofbusiness transactions betweentwo trading partners that forma business collaboration


As can be seen from Figure 13, while ebXMLand others provide ready standards for the mes-saging and process integration of enterprises, amajor component of any B2B framework is ver-tical, business specific content.

RosettaNet has dealt with this for the electronicsand IT industry by publishing standard transac-tions (PIPs) with defined names, patterns andXML content.

Other industries, including telecommunicationscompanies, have made similar efforts onselected initiatives (such as number portability)on older EDI standards but have yet to come upwith comprehensive vertical process and datastandards for all potential telco B2B integrationson newer Internet-based e-commerce platforms.

Without such industry-defined content, tradingpartners are left with the expense of definingtheir own proprietary bilateral implementations.

Strategies for Meeting the ChallengesAs stated earlier, work has already commencedin implementing the various ebXML standardsand proving their interoperability.

Through adopting a modular approach, ebXMLhas further left the path clear for the market todecide which of the standards are most appropri-ate, and only time will tell what the final popu-lated framework will look like in terms of prod-ucts and standards.

The increased use of standard commercial appli-cations and their integration via EAI middleware

will also help open up the legacy environment toB2B integration, and reduce cost of integration.

As a further cost-reduction aid, some B2B ven-dors provide ‘lightweight’ pre-configured ver-sions of their gateway products that larger com-panies can distribute to their smaller partnerswith pre-implemented integrations and simplefile-based APIs.

In terms of further kick-starting the adoptionof B2B integration by smaller trading partners,the leading operators may well need to provideassistance and support in the development andimplementation of e-business standards suitablefor telcos.

This support should also include ‘partner enable-ment resources’ comprising specifications, andtesting environments for development of e-busi-ness integrations prior to live operation.

In terms of the wider telecommunications indus-try in the UK, BT and other operators have al-ready formed The Telecommunications IndustryB2B Forum (formerly known as the TelcoAPIForum) (12). The intent of this group is todevelop and promote telco specific B2B processand data standards and promote them throughthe ITU.

The approach of the group has been to adoptXML business documents from adjacent indus-tries (such as purchase orders) and extend themto cover the particular requirements of serviceorders for telecommunications services. It is theintention of the group to promote these standards

BusinessConceptualModel(Definition,format,structure andchoreography)

TechnicalConceptualModel(Standards,protocolsand tools)

Universal BusinessDictionary Content

Vertical TechnicalDictionary Content

Business DictionaryStructure

Technical DictionaryStructure

Business Document Definition

Core XML Format Standards

Messaging

Service-Oriented Architecture

Back-end Integration

Universal BusinessProcesses

Process Description Language

Process Coordination Framework

Directory Service

Tra

ding

Par

tner

Agr

eem

ent

(TP

A)

Sec

urity

Vertical(Supply Chain)

Business Processes

Business Model-Specific Processes

Figure 13 B2B standardsconceptual framework (11)


more widely, develop standards for other pro-cesses as well as develop procedures for theconfiguration management of these interfaces.

Applications Within BTOverall, BT Wholeale’s vision is to deploy B2Btechnologies as an enhancement to its eCO ser-vices, as part of a wider transformation of itsOSS infrastructure, and support as wide a rangeof customer and supplier facing processes as ispracticable using such technology.

Within BT Wholesale efforts to employ theseeBusiness architectures have already been under-way for over two years.

Currently the BT Wholesale eCO applicationsupports XML-based ordering interfaces usinga proprietary Access Framework mechanismdeveloped to allow trading partners to exchangebusiness documents using http post and get com-mands to a public hosted web server securedwith digital certificates.

The framework has been reused for XML inter-faces for LLU and ADSL provisioning and thereare currently efforts underway to look at supportfor trouble ticketing.

With the emergence of early implementations ofthe ebXML messaging service, BT is also look-ing to enhance these early implementations withphased replacement of the Access Frameworkwith an ebXML messaging gateway as a morestandards based and functional approach.

BT Retail is also active in the use of B2B tech-nologies with its suppliers (in particular Cisco)via use of RosettaNet standards and moreover,BT Wholesale is looking to reengineer andstreamline its network plan and build processeswith major network equipment vendors usingB2B gateways and standards.

ConclusionsEmerging e-business standards such as Roset-taNet and ebXML have been prompted by theemergence of the Internet as a platform for e-commerce.

As wholesale providers develop a wide range oftrading relationships with partners, suppliers andcustomers the opportunity presents itself toengage in a much wider series of collaborativecommerce activities than just the buying andselling of goods and services.

The TeleManagement Forum’s eTOM begins tosuggest just how wide the scope of these activi-ties could be and the opportunities for OSS inte-gration via B2B technologies.

However, there are significant standardisation,cost and maturity issues to be overcome prior towider spread adoption of these applications.

Nevertheless, the links are coming hot out of theforge: time to start building the chain.

References1 RosettaNet. August 16, 2002 [online] –

URL: http://www.RosettaNet.org

2 ebXML. August 16, 2002 [online] – URL:http://www.ebxml.org

3 Business Process Project Team. ebXMLBusiness Process Specification Schema,Version 1.01, 11 May 2001. URL:http://www.ebxml.org

4 Telemanagement Forum. eTOM The Busi-ness Process Framework for the Informationand Communication Services Industry –GB921 v2.5. URL: http://www.tmforum.org

5 Uglow, S, Gambhir, A. Wholesale: NewMarkets for Communications Carriers andService Providers. OVUM, Oct. 2000.

6 Open Buying on the Internet. August 16, 2002[online] – URL: http://www.openbuy.org/

7 Chappell, D et al. Professional ebXMLFoundations. Worx Press Ltd., 2001.(ISBN 1-861005-90-3)

8 Simple Object Access Protocol (SOAP) 1.1.W3C Note 08 May 2000. URL:http://www.w3.org/TR/SOAP/

9 XML Web Services. August 16, 2002[online] – URL: http://www.microsoft.com/net/defined/xmlservices.asp

10 Gerrese, J. iCE: The ‘Cool’ Operation Sup-port System and Interactive CustomerEmpowerment Engine. The Journal of theInstitution of British TelecommunicationsEngineers, 2 (3), 2001.

11 Coleman, D. B2B Standards. RosettaNetPresentation.

12 The Telecommunication Industry B2BForum. December 4, 2002 [online] – URL:http://www.telcoB2B.org.uk/.

13 The Drummond Group. October 1, 2002[online] – URL: http://www.drummondgroup.com/html-v2/pr_10-01-02.html


BackgroundThere is an acknowledged and universal needtoday for organizations to be able to collaborateelectronically, preferably throughout the supplychain. This requires an open infrastructure ofcollaborating applications that can be imple-mented by all participants in the supply chainwithout long and complex implementation pro-jects. The business world is dynamic, and anelectronic infrastructure is required to supporteasy and cost efficient change of business part-ners as well as business protocols.

With this in mind the Norsk EDIPRO Infrastruc-ture project embarked on a journey to establisha sound infrastructure – the goals being the en-abling of full application integration on a seman-tic level, resource effective and manageableenough to be adapted by small and mediumsized enterprises. By “full application integra-tion” we mean in this context the enabling oftwo or more collaborating business applicationsto produce, interpret and process the contents ofexchanged message data on the basis of thesemantics of a common reference model con-taining all information relevant for business col-laborations within the domain in question. Theapplications to be integrated would typically beend-user applications like ERP systems, logisticssystems and financial systems – in other wordsthe critical production systems of a company oran organization.

In order to succeed with electronic collaborationthere is a set of process and information modelsthat need to be aligned. The infrastructure needsto ensure that not only the users in the differentorganizations are interoperable, but also systemsand applications. For this a set of semantic defi-nitions need to exist that can make OrganizationA’s proprietary e-commerce systems communi-cate with Organization B’s proprietary e-com-merce system. To enable a flexible and easilyextensible collaboration, it is necessary to aligndifferent descriptions. First of all the collabora-tion should be built on a domain model. Adomain model is typically developed by industryorganizations and attempts to standardize pro-cesses and information across an industry tofacilitate electronic collaborations. Further, eachcompany’s description of their internal businessprocesses will constitute the business processmodel. Organizations in a given industry willtypically have different internal process modelsfor a given function, but they should be related

to the same domain model. Then at the finallevel two or more organizations, belonging tothe same or different domains, can go together tospecify how the specific collaboration processesshould be implemented between them in a col-laboration model.

The Proposed ArchitectureA central issue in defining an architecture is toembrace the rapid changes we see in technologyand business environments today. A naturalchoice would therefore be to use the model-driven approach for our architecture. With amodel-driven architecture we decouple designand realization so that our fundamental businessprocess design can be realized in the technologyof choice, earlier that might have been EDI/EDI-FACT or CORBA, today it could possibly beXML Web Services or electronic business XML(ebXML). This also allows you to describe yourcollaboration process in the same mannerregardless of which platform you want to basethe realization on. The central issue is to keepthe design in a platform independent version inorder to be able to easily migrate to an alterna-tive realization as business needs change andtechnology evolves.

Figure 1 shows the complete architecture model.An important requirement for our work has beenthat the Platform Independent Model (PIM) must

Next Generation Infrastructure forElectronic CollaborationØ Y V I N D A A S S V E

Øyvind Aassve (36) is an ITarchitect at Telenor Networks,where his main focus is IT archi-tecture and business-to-busi-ness issues. He holds an MScin Information Systems (2001)from the University of Texas atArlington. Before joining TelenorNetworks he worked as a pro-grammer at eTech Solutioncorp,and has previously also workedextensively with enterprise soft-ware as a business analyst andproject coordinator at Scandina-vian PC Systems Group (nowVisma Software). Mr. Aassvehas participated in NorskEdipro’s Infrastructure projectwhere he led the working group“Description of collaborationmodels in an open infrastruc-ture” and participated in twoother groups.

[email protected]

The Infrastructure ProjectThe Infrastructure project was initiated by

Norsk EDIPRO to facilitate the adoption of

electronic collaboration especially among

small and medium sized Norwegian enter-

prises by providing an open infrastructure

for collaborating applications and enterprises.

The vision is to achieve flexible and seamless

integration between applications of enter-

prises throughout the supply chain, and to

manage this in an easy, cost efficient and

universal way.

This article provides an overview of the

results of the Infrastructure project’s May

deliveries from the two working groups

“Description of collaboration models in an

open infrastructure” led by Øyvind Aassve,

Telenor Networks, and “Application Readable

Models in an open infrastructure” led by Arild

Nybakk, Scandinavian Transport Systems.


be available in two forms, one “for people” ver-sion (the left box of the Platform IndependentModel) that can be read and understood byhumans – preferably including non-IT profes-sionals; and one “for application” version (theright box of the Platform Independent Model)which is optimised to be read and processedby applications. The “for people” version isdescribed using a set of UML diagrams, whilefor the “for application” version these diagramsare implemented using a lighter version of theOMG standard XML Metadata Interchange(XMI). This “XMI Light” version was devel-oped by SINTEF for the project, because full-length XMI was found to be too verbose.

An extension of the Resource DescriptionFramework (RDF) – DARPA Agent MarkupLanguage (DAML/RDF) was also evaluated forthe “for application” version. RDF is central toW3C’s efforts to create the semantic web.DAML/RDF does not however handle activitydiagrams, mainly due to lack of attention todescribing business and collaboration processes.

With a collaboration process now modelled inUML and then converted into XMI Light, thenext step is to select a set of transformation rulesthat can transform the PIM into a Platform Spe-cific Realization (PSR). The idea here is thatthere will be one set of transformation rules foreach realization, and all you need to do is selectthe rule set for the realization of your choice.

Central to the model is also the Business ServiceInterface whose purpose is to map the domainsemantics of the platform independent model

with the semantics of the internal applicationmodel. This results in a significant improvementfrom the former field-to-field mappings in EDI,because it enables us to communicate messagecontents as specified by specific realization doc-uments (XSD schemas, BPSSs, etc.) and inter-pret these contents based on the underlying com-mon semantic domain model. Telecommunica-tion Markup Language (tML) is a possibledomain model for the telecom industry.

Description TechniquesMost of the processes to be implemented in thearchitecture described above will be stored inpublic or private repositories. To achieve suc-cessful interoperability it is crucial that the pro-cesses are described in the same manner by allthe participating business partners.

Figure 2 shows the three different submodels/UML diagrams that have been selected to cap-ture the complete business collaboration.

• The activity model (UML Activity diagram)shows what activities/processes to be per-formed by each role in a collaboration. Thisflow of operations and information is oftenreferred to as choreography or orchestration.The realization will be based on BPSS forebXML and WSFL for XML Web Services.

• The interaction model (UML Component dia-gram) illustrates which roles collaborate overthe different interfaces. Realizations will bebased on the BPSS for ebXML and WSDL forXML Web Services.

Figure 1 The architecturemodel

Internal modelR/R R/R

R/R

UN/CEFACTOASIS CC

Platform independent model

Activity model

Interaction model

Information model

Activity model

Interaction model

Information model

“For people” description-UML “For applications” description-XML

Transformationrules

Mapping tosemantic definitions

Application

Business Service Interface

R/R

Map to PIM model

Verify message

Instance of model

Map from modelto application

Message instance

Activity specifications(eb:BPSS, ws:WSFL)

Interaction specifications(eb:BPSS bus, transaction, ws:WSDL service)

Information specifications(eb:XSD, ws:WSDL/XSD)

Platform specific realization(eb:XML, Web Services)


• The information model (UML Class diagram)depicts the information included in the collab-oration in the form of classes, attributes andrelationships. The information model is alsothe basis for expressing the information con-tained in the flow-objects in the ActivityModel. Realizations will typically be basedon XML Schema and in some instances onWSDL for XML Web Services.

The three complementary submodels containattributes that together represent necessaryaspects of a collaboration. A minimum is todescribe the activity and information model todefine the collaboration process.

The models can be presented in either a concep-tual or a more detailed version. The activitymodel in the figure above is detailed in the sensethat it contains flow objects, while a conceptualmodel would only depict the process flow. Flowobjects are objects that represent the informationthat flows between the participating roles in theprocesses, and they contain the contents andstructure of the messages that are sent betweenthe collaborating parties.

An issue regarding the activity model is also therepresentation of state in the system. Interna-tional initiatives like ebXML has introducedBusiness Entity Types (Business Object Types)to help record the state of a collaboration as itprogresses. As the sub-processes are completedthe “state” of the collaboration reaches newlevels. State then becomes a function of theprogress of the collaboration and can be usefulfor the collaborating partners to synchronize.This can be achieved through a business entity(business object) whose purpose it is to updatethe collaboration status at all times. Change ofstatus happens when one party completes anactivity that is being synchronized through aninformation flow.

The Semantic ConnectionThe relationship to semantics and semanticinformation is critical to enable the collaboratingpartners to have the same understanding of thecontent in the platform independent model.

The word semantic means “science of the mean-ing of words”. In our work a semantic definitionis a precise and unambiguous explanation of themeaning associated with an element in a collab-oration model.

Any application is built upon a “semantic uni-verse” expressible through an activity and infor-mation model – the meaning content of theapplication is carried by the model. The part ofthis universe which – directly or indirectly – isinvolved when an application participates in an

electronic collaboration, must be – or be madeinto – a part of the semantic universe of the otherapplication(s) taking part in the collaboration.

This is the purpose of the Business ServiceInterface (BSI). The BSI downloads externalschemas (ex. a potential partner’s process real-ization document) from different Registries/Repositories (R/R) and makes the semantics ofthese available for the internal applications ofthe owner of the BSI. The BSI is basicallyresponsible for two mapping jobs. The first oneis the alignment of the semantics of an organiza-tion’s internal applications to the semantics ofthe platform independent model. The other oneis the mapping from the realization documentspecifications to the platform independent modelsemantics – this is partly done during set-up,partly on-the-fly as necessitated by changes orextensions in the realization documents. For thelatter mapping from Platform Specific Realiza-tions to Platform Independent Model an applica-

Figure 2 UML diagrams areused to describe the submodelsin the architecture. In the “for

application” model thesediagrams will be described

through XMI

Activity model

Interaction model

Information model

UML Activity diagram

UML Package/Component diagram(UML 2.0 inspired

UML Class diagram

HPL

TRA

LHH

LTB

ICustomer ISeller

IWareHouse

IProdOwn

ITransportServ

PurchaseProcess2

ProceedPurchase2

Handleinvoice2

OrderInfoOrderInfo

confInfo

invoiceInfo

OrderProcess2

DeliveryProcess2

Customer2Customer Seller2Seller

<<entity>>

PurchaseOrder

- poNr : int

- date : Date

<<entity>>

CustomerEntity

- name : String

- address : String

- phonenr : String

<<entity>>

Order

+ orderNr : Int

+ date : Date

<<entity>>

Invoice

- date : Date

- amount : Currency

<<entity>>

Product

+ prodNr : Int

+ description : String<<entity>>

OrderLine

+ nrOfProd : Int<<entity>>

Shipment

+ ndelivAddress : Address

<<entity>>

SellerEntity

- name : String


tion of the W3C standard Resource DescriptionFramework (RDF) is chosen, containing eitherXpointer expressions or Universal Unique Iden-tifiers (UUIDs) as the concrete mapping mecha-nism.

Applications participating in a collaborationwill have to map the semantics of any operation,information item or other business entity to beused in collaborations within the domain inquestion. We consider the semantics of such abusiness entity to be encapsulated in what wehave labelled a semantic carrier. A semanticcarrier can be thought of as a location or refer-ence point uniquely identifying the semantics ofthe business entity. It is important to note, how-ever, that the carrier is located in the context of amodel for the business domain in question, mak-ing it more than just an object with a given iden-tifier – the semantics of the carrier is the combi-nation of the semantics of the component as suchand the semantics of the model context in whichit appears. This means that we need to contextu-ally identify the different elements carryingsemantic information in the model. The detailswill not be presented in this article, but as anexample, in order to represent the informationmodel semantically it may be necessary tosemantically locate information on class,attribute, association and code list identifierlevel.

Platform Specific RealizationsThe project’s assumption is that XML Web Ser-vices and ebXML will become the most popularcandidates for Platform Specific Realizations.The specifics of XML Web Services will be bet-ter explained in other articles of this issue ofTelektronikk, but I find it worthwhile mentioninghere that in order to implement full collabora-tions through Web Services further capabilitiesthan those provided by WSDL, SOAP andUDDI today are necessary. In order to imple-ment Web Services as part of larger businessprocesses IBM has put forward the Web Ser-vices Flow Language, which is already sup-ported by a number of tool vendors. Microsofthas come up with their XLANG language whichserves similar purposes. IBM and Microsoft arecurrently working together to possibly combinetheir efforts so that the Web Services communityonly needs to relate to one orchestration stan-dard.

ebXML was developed in a joint initiative of theUnited Nations (UN/CEFACT) and the Organi-zation for the Advancement of Structured Infor-mation Standards (OASIS) between November1999 and May 2001. The ambitious goal was tocreate an infrastructure for a single global elec-tronic market. ebXML is composed of the fol-lowing four elements:

Figure 3 The ebXMLarchitecture

Agree on Business Arrangement

Download Scenarios and Profiles

5

Business ProfilesBusiness Scenarios

ebXMLRegistry

COMPANY BDO BUSINESS TRANSACTIONS

ebXML compliantsystem

6

Query about COMPANY A Profile

4

Register Implementation DetailsRegister COMPANY A Profile

3

Request Business Details

1XML

COMPANY A

Build Local SystemImplementation

2


Business Process Specification Schema (BPSS):The Specification Schema provides the defini-tion of an XML document that describes howan organization conducts its business. Whilethe CPP/CPA deals with the technical aspectsof how to conduct business electronically, theSpecification Schema deals with the actual busi-ness process. It specifies such things as the over-all business process, the roles, transactions, iden-tification of the business documents used, docu-ment flow, legal aspects, security aspects.

Trading Partner Information: The CollaborationProtocol Profile (CPP) provides the definition(DTD or XML schema) of an XML documentthat specifies the details of how an organizationis able to conduct business electronically. Itspecifies how to locate contact and other infor-mation about the organization, the types of net-work and file transport protocols it uses, networkaddresses, security implementations, and how itdoes business (a reference to a Business ProcessSpecification). The Collaboration ProtocolAgreement (CPA) specifies the details of howtwo organizations have agreed to conduct busi-ness electronically. It is formed by combiningthe CPPs of the two organizations.

Messaging Service: Provides a standard protocolneutral way to exchange business messagesbetween organizations. SOAP was finallyselected as the standard.

Registry: A database storing items that supportdoing business electronically. Examples of itemsin the registry might be XML schemas of busi-ness documents, definitions of library compo-nents for business process modelling and tradingpartner agreements.

The process of establishing a business collabora-tion based on ebXML will typically be as fol-lows (Figure 3): based on a review of the infor-mation available from an ebXML Registry Com-pany A can build or buy an ebXML implementa-tion suitable for its anticipated ebXML transac-tions. After enabling their own applications forebXML transactions Company A creates andregisters a CPP with the Registry. Once Com-pany A is registered other companies can look atCompany A's CPP to determine whether it iscompatible with their own CPP and require-ments. If it is, the potential partner should beable to negotiate a CPA automatically withCompany A. In addition there will normally bemeetings to specify the business conditions fortheir collaboration.

This should have given you a taste for the possi-bilities of business collaborations in the nearfuture. The full documentation of NorskEDIPRO’s Infrastructure project includingdescription and rationale behind the differentchoices is available at http://www.edipro.no/index.php?id=47796&cat=1323. “Description ofcollaboration models in an open infrastructure”is for the time being only available in Norwegian.

Telektronikk 4.2002

1 IntroductionThe purpose of this document is to show how touse Microsoft .NET to integrate with Java EJBservices using XML Web Services technology.This document is based upon experience fromthe eChannel (eKanal) project at Telenor. Usingthis kind of technology is rather new and excit-ing, and not many sites have been implementingthis kind of technology yet.

2 About the ApplicationThe eChannel project has developed a web site“Dine sider” (“Your pages”), which is a self-ser-vice channel web site for our private customerswith fixed line phones. On this site authenticatedusers can manage their subscription online andorder/cancel products and additional services.For instance they can get consultation on whichtype of subscription or service they should get,copies of previous invoices and incurred costsince last invoice. The site also provides a lot offunctionality for non-authenticated users. Ordersand cancellations of products/services are auto-mated by utilising the appropriate services sup-plied by our middleware platform.

“Dine sider” has approximately 70,000 visitors,and 20,000 users logged on every week. Thatmakes us one of the biggest web sites with thiskind of technology in Europe. The site also hasextensive use of personalized information andcampaigns, e.g. you do not receive campaignon broadband Internet connection if you alreadyhave this product. All of this is made possiblewith ASP.NET (C#), XML Web Services,SOAP and Commerce Server.

3 BackgroundEighteen months ago, “Dine sider” was imple-mented using Active Server Pages, communicat-ing with a Java middleware platform in anotherbusiness area in Telenor. For business relatedreasons we had to leave their middleware. Theresponsibilities of the middleware platform areabstracting functionality and information locatedin various internal production/ legacy systems.

Telenor was at that time working on a newmiddleware platform. Their goal was to abstractfunctionality from our legacy systems. The tech-nology used for implementing was alreadydecided to be Java.

Telenor was also striving to gain an intimateknowledge of its customers and to personalize

and up-sell its services. The previous solutionswere not focused on logging what customerswere doing when visiting the web site. Werequired our new solution to better keep trackof how users were browsing and using the webapplication. Another challenge we experiencedwith the Active Server Pages implementationwas the time and cost implications of rapidchanges to the user interface. This because theActive Server Pages contained both HTML anduser interface controls.

4 TechnologySeveral technologies for realizing our web front-end and functionality were evaluated.

• Java• Siebel• Microsoft .NET

We required a solution where we could easilymake adaptations and on-line integration. Siebeltechnology was not found to be the best solutionfor us. Microsoft .NET was the chosen vendorbased on our previous experiences with Micro-soft’s products and excellent support for XMLWeb Services.

XML Web Services are the cornerstone of the.NET platform. The hope for the XML Web Ser-vices technology is that it will bring us into anew era of programming. Rather than relying onthe assembly of platform dependent componentsor objects, the XML Web Services technology isbased on the reuse of distributed, platform inde-pendent services. These services and their corre-sponding contracts are exposed using (UDDI)catalogues publicly accessible.

5 Web Service OverviewA web service is a mechanism for invokingfunctionality from another application or systemon any platform using standard Internet tech-nologies.

XML Web Services exchange data using XMLand transport data using HTTP, for example.The most common Web Services language (pro-tocol) is currently Simple Object Access Proto-col (SOAP). The protocol does not, however,specify how messages are going to be built andhandled.

Important standards for Web Services are WebService Description Language (WSDL) and

The Self-Service Channel – “Dine sider” (“Your pages”)R O B E R T L A N D S E M

Robert Landsem (28) graduatedas Computer Engineer from Sør-Trøndelag University College(HiST) in 1997. He worked fortwo years at Enitel a.s, and iscurrently working as an Internetarchitect in Telenor Plus.

[email protected]

110


XML Schema Definition (XSD) documents. TheWSDL documents contain the services interfacedefinitions: the services messages, the servicesports and the services encoding. Messages aredescribed as RPC names and XSD types. Portsare described as IP and port number. Bindingsare, in our case, always SOAP RPC encoded.The XSD documents contain the messages typedefinitions, in an XML format.

The WSDL defines the interface and is used tocreate an XML Web Services proxy. This proxyis then used to interact with the Web Service.

On the service layer there is typically a Web Ser-vices handler to process the incoming Web Ser-vices call. The handler translates the call fromSOAP XML into the language of the servicesand then executes the method on the service.The response from the method call is then trans-lated back to SOAP XML and returned to theproxy. The translation from and to XML isreferred to as serialization/deserialization or,sometimes, marshalling/unmarshalling.

The roles of the above parts are shown in Figure 1.

6 SOAP OverviewThe Simple Object Access Protocol (SOAP) isan XML syntax for exchanging messages. It isdesigned to exchange structured and typed in-formation on the Web, for example. Because it isXML, it is both language and platform indepen-dent. SOAP allows applications implemented indifferent languages and on different platforms tocommunicate. At present, SOAP has been imple-mented in over 60 languages on over 20 plat-forms. SOAP is a fundamental part of Microsoft.NET and it will be important for developersmoving to Microsoft .NET to understand whatSOAP is and how it works.

Let us assume that we have a very simple corpo-rate database that holds a table specifying cus-tomer reference numbers, names, addresses andtelephone numbers. You now want to offer a ser-vice that enables other systems to perform alookup on this data. The service should returna name for a given telephone number.

The prototype of the service will look like this inC#:

string getCustomer ( string

customerPhoneNumber );

The SOAP developer will now encapsulatethe database request logic for the service in amethod in any kind of programming language,and then set up a process that listens for therequest to the service. The request is in SOAPformat and contains the service name and anyadditional parameters. The listener processdecodes the incoming SOAP request and trans-forms it into an invocation of the appropriatemethod. It then encodes the result of the methodcall into a SOAP message (response) and sendsit back to the requester. Figure 2 shows thearrangement.

A SOAP-encoded RPC dialogue contains botha request message and a response message. Ademonstration of how a simple service returnsthe name of the owner of a telephone number isshown on the following page.

Figure 1 Use of WSDL/XSDdocuments from the service

layer on the front end

Figure 2 Illustration of arequest from a client down toa listener on the service layer

Application

Web ServiceProxy

Web Servicehandler

Services

Front-end native languagemethod call

Web Service RPC(HTTP/XML)

SERVICE native languagemethod call

XSD

WSDL

Front-end layer

Enterprise firewall

Service layer

ServiceMethods

DataBase

ListenerClient

TransportLayer

SOAPResponse

SOAPRequest

MethodResponse

MethodCall

DatabaseResponse

DatabaseCall


Figure 3 Overview of the architecture used by Telenor

1 Method Signature

2 Request

3 Response

string getCustomer ( string customerPhoneNumber );

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<SOAP-ENV:Envelope

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<SOAP-ENV:Body>

<ns1:getCustomer

xmlns:ns1="urn:MySoapServices">

<param1 xsi:type="xsd:string">22041968</param1>

</ns1:getCustomer>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

<?xml version="1.0" encoding="UTF-8" ?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<SOAP-ENV:Body>

<ns1:getCustomerResponse

xmlns:ns1="urn:MySoapServices"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/ encoding/">

<return xsi:type="xsd:string">Robert Landsem</return>

</ns1:getCustomerResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

WebApplication

(C#)

NET WebService Proxy

RPC Router(Java Servlet)

Services(EJB)

NET method call

HTTP/XML (SOAP RPC)

EJB/RMI

XSD

WSDL

NET Platform

Internal enterprisefirewall

EJB Platform

Enterprise firewall

Web pages(ASPX)

NET method call

Browser

HTTP/HTML

DD


7 Our New Web SiteFor this particular project we used WSDL andXSD to describe the services provided by theservice layer. These documents were used asinput for the Microsoft .NET front-end systemin order to automatically create the Web Serviceproxy. The proxy wrapped all the Web Servicedetails into C#, and the Web Application devel-opers used the XML Web Services as normalmethod calls within their code. The WSDL andXSD are only used once to create the proxy atdesign time. At runtime the WSDL and XSDdocuments are not used.

The chosen XML Web Service handler is theopen source Apache SOAP. The access pointis a servlet, RPCRouter, which translates theSOAP XML to Java and performs EJB lookupand a remote invocation through reflection ofJava objects. The RPCRouter handles all theWeb Service requests. The servlet uses Deploy-ment Descriptors (DD) to translate (serialize/deserialize) from XML to Java and vice versa.The DD are Apache specific translation maps(XML to Java) described using a special XMLsyntax. Our implementation includes Deploy-ment Descriptors (DD).

8 Lessons LearnedWe had some problems converting some datatypes from Java to C#. Caution should be shownwith different handling of data types on differentplatforms.

Another important issue is Apache SOAP’s useof Deployment Descriptors. They introduce anunnecessary step in the development of WebServices. DD is a proprietary definition andcould be replaced with WSDL and XSD docu-ments.

Within three months in October 2001, Telenorimplemented a customized web site based onMicrosoft .NET platform.

9 ConclusionWhen it comes to exposing objects over theInternet, current XML Web Service technologyis an excellent (and a lot simpler, extensible andmanageable) alternative to DCOM or CORBA.It is also much easier to implement.

Even though XML Web Services were primarilychosen because of difficulties integrating hetero-geneous systems, there is no reason not to useXML Web Services to integrate homogeneoussystems.

By implementing XML Web Services, compa-nies can automate many business operations,thereby creating new operating efficiencies andmore efficient ways of doing business.

And with XML Web Services standards alreadyincorporated into their IT systems, companiesare better prepared to take advantage of upcom-ing opportunities to transform their business.

Web services are useful for both B2B and forinternal application integration, e.g. the develop-ment of applications that use Web Services toconnect to trusted business partners.

10 Further ReadingMicrosoft. November 12, 2002 [online] –URL: http://msdn.microsoft.com/soap

Schjefstad, K. White paper – ImplementingWeb Services in a heterogeneous environment.MSO Norway, 4 Dec 2001.

IBM on Web Services. November 12, 2002[online] – URL: http://www-106.ibm.com/developerworks/webservices/

Mayo, S. Five Early Birds’ Business CaseStudies. IDC Web Services, Aug 2002.

11 AcronymsSOAP Simple Object Access ProtocolHTML HyperText Transport ProtocolRPC Remote Procedure CallXML eXtensible Markup LanguageXSD XML Schema DatatypesWSDL Web Service Description LanguageEJB Enterprise Java BeansRMI Remote Method InvocationJDBC Java Database ConnectivityDAO Data Access object in the Origo projectDD Deployment Descriptor


Laptop

Outlook

PDA

Outlook

Cell phone

Outlook

Desktop

Outlook

Synchronise!

1 Background and ContextThis section describes the motivation behind ourwork on the User Profile Web Service (UPWS)and gives an overview of related work in theproblem area.

1.1 User Mobility and theWorld Wide Web

The background for this paper is two importanttrends. The first trend, mobility, concerns users’increasing ability to communicate anytime andanywhere. The huge popularity of mobile com-munication clearly shows how this kind of free-dom and flexibility is rapidly becoming animportant user demand. The other trend is thehuge popularity of the World Wide Web. It hasemerged as the by far most popular applicationon the Internet, and in harmony with the mobil-ity trend can now be accessed not only troughPCs but also using smaller, mobile devices, likemobile phones and personal digital assistants.Users already have access to the Web almostanytime, anywhere and from any device, andthere is every reason to believe that this trendwill continue to evolve towards more and moreflexible user options.

Today’s users experience many different ser-vices. It may be software application servicesresiding on the user’s own devices, or it may besoftware application services that reside on the

Web and that the user accesses through a Webbrowser. Users also utilise communication ser-vices such as voice communication and messag-ing – on both mobile and fixed networks.

1.2 Inhibitors of User MobilityToday however, the user’s mobility is limitedby the fact that her data are bound to the devicesand/or services that she uses. The first of theseproblems means that if a user needs to use thesame service or application on different devicesthis will often require synchronisation of databetween the devices (see Figure 1). Some prod-ucts, e.g. Outlook, offer synchronisation facili-ties so that a user automatically can update dataafter changes have been made on one device.However this solution is still tedious, and if theuser has more than two devices, the task of keep-ing all devices updated can be a complex one.

If the service resides on a Web server thisreduces the problem, since data will be storedon a server and accessed from all the differentdevices accessing the service. However, the sec-ond problem still remains: Data are bound to theservice, so that different services that might usethe same data will not be able to share them (seeFigure 2). Thus the user must maintain an extraset of data for each additional service, and alldata changes must be made once per service. Atypical example of this problem is having many

Web Services in Action: The User Profile Web ServiceA N N E M A R I E H A R T V I G S E N A N D D O V A N T H A N H

Do Van Thanh (44) obtained hisMSc in Electronic and ComputerSciences from the NorwegianUniv. of Science and Technology(NTNU) in 1984 and his PhD inInformatics from the Universityof Oslo in 1997. In 1991 hejoined Ericsson R&D Depart-ment in Oslo after 7 years ofR&D at Norsk Data, a minicom-puter manufacturer in Oslo. In2000 he joined Telenor R&D andis now in charge of PANDA (Per-sonal Area Network & DataApplications) research activitieswith a focus on SIP, XML andnext generation mobile applica-tions. He also holds a professorposition at the Department ofTelematics at NTNU in Trond-heim. He is author of numerouspublications and inventer of adozen [email protected]

Anne Marie Hartvigsen (25)finalised her Master in Informa-tion Systems at Agder UniversityCollege in June 2002, with thethesis “Studying EmergingTechnologies in Telenor – UsingWeb Services to Provide Univer-sally Accessible User Profiles”.She also holds a Cand.Mag. insocial sciences from the Norwe-gian University of Technologyand Science (NTNU). Formerlya visiting researcher at TelenorR&D, working in the PANDA(Personal Area Network andData Applications) researchgroup, she is now employedas a systems developer at theTelenor spin-off XymphonicSystems.

[email protected]

This paper describes the concept of the User Profile Web Service (UPWS) – an XML Web service that

allows users to store preferences and personal data in a central profile and at the same time as it allows

the user’s different applications and services access to it. A realisation of this service would offer great

enhancement of user mobility since it would allow for personal configuration of a user’s services

independent of time, place and device.

Figure 1 Synchronising between devices


sets of contact information – one on the mobilephone, one in the e-mail client, one in the chat-ting application, etc. Some of these data areoverlapping, and allowing the different servicesto share the data would simplify data mainte-nance for the user and give the user more free-dom and mobility.

All of this does not only count for user data, butalso for preferences and settings – either applica-tion specific or more general (e.g. privacy pref-erences). There are several settings that wouldbe convenient for the user not to have to config-ure again for each service to be used.

Also, it is important that services can be bothapplication services and other, e.g. communica-tion services, and thus this paper tries to look ata broad area taking in all categories in a user’sdaily use of IT services.

1.3 A Unified User ProfileInstead of binding user and configuration data todifferent devices and services, we propose herethat the appropriate binding is between the dataand the user. A user only needs one set of per-sonal data, and once a user has configured anapplication or service with preferences and set-tings other services should be able to reuse asmuch as possible of these preferences and set-tings. The only way to achieve this goal is tocapture all the relevant data in a user profile andthen let the different services access this profile– as shown in Figure 3. These data can then beused for configuration of the service and as a rep-ository of personal user data such as e-mail add-resses, phone numbers, favourite bookmarks, etc.

This profile must be available as a service to theuser’s different services, and there are some cru-cial requirements associated with this:

• The profile must have one general part andone service specific part for each service

• The profile must be extendable so that a newservice can be added instantly at any time

• The profile must be easily accessible from anydevice and service

These requirements are all crucial for the userprofile to succeed and later in this paper we willexplore how these requirements can all be ful-filled using XML Web Services. But first wewill take a look at existing initiatives towardssolving the problems we have described here.

1.4 Existing Solutions and InitiativesSeveral initiatives try to solve different problemsrelated to those described at the beginning of this

section, and in this section we sum up some ofthe major activities that are going on.

1.4.1 Virtual Home Environment3GPP’s Virtual Home Environment (VHE) ini-tiative recognises the user’s need to experiencethe same environment on the road that they havein their home or corporate environment. It is apart of the IMT-2000 and UMTS specification,and as such the environments targeted are lim-ited to 3G mobile networks. Still only in thespecification phase, VHE aims to let a foreignnetwork emulate the behaviour of a user’s homenetwork.

1.4.2 CC/PPThere is a lot of work going on concerning theutilisation of user profiles to enhance services,and particularly in the area of mobility manage-ment for wireless and mobile networks, mostoften focusing on conveying situational contextinformation about the environment, device andnetwork, and only to a lesser extent personalpreferences and needs.

The Composite Capabilities / Preferences Pro-files (CC/PP) is an example of this perspective,focusing primarily on the capabilities of the net-work, devices and software and not so much on

Figure 3 Central userprofile solution

Figure 2 Keepingredundant data Stores

Pine

AddressList

AddressList

WebMail

OperaMail

Outlook

Little or no sync!

AddressList

AddressList

Laptop

Outlook

PDA

Outlook

Cell phone

Proprietary

Desktop

Pine

Synchroniseagainst one place!

User ProfilePersonal Data • Address List • Bookmarks • Etc.

Application Data • Settings • Preferences


user preferences. Software services on the Webmay be accessed from devices with differentcapabilities – limitations in bandwidth and dis-play may for example benefit from receiving alightweight version of the service, while a userwith a powerful PC and broadband would bene-fit from receiving every feature that the servicecan offer. CC/PP addresses this issue by defininga way to specify what a user agent (defined interms of hardware and software platform anduser agent application such as a Web browser) iscapable of doing. Using CC/PP Web clients andservices can negotiate service content and con-tent delivery mechanisms to best fit the capabili-ties of the user agent. CC/PP also aims at defin-ing user preferences, although this is not speci-fied at this time. Thus CC/PP does not yet takecare of user preferences in a satisfactory way.

1.4.3 P3PThe Platform for Privacy Preferences (P3P)focuses on user preferences in terms of privacyprotection levels on Web sites. The user mustinstall a P3P client on the device she is using toaccess the Web page, and then the client and theWeb site can negotiate on the content. The ulti-mate P3P implementation would be integratedwith the Web browser on the client side, but thesolution is still bound to the device the useraccesses a given service (Web site) with, andalso to the client (Web browser) she uses.

1.4.4 .NET myServices.NET myServices is the only existing solutionsimilar to our UPWS. The aim of this service is

to offer users the ability to store personal infor-mation in a central repository, which can beaccessed by other applications such as an XMLWeb service. The concept relies heavily on .NETPassport service for single sign-on. However,our proposed framework goes beyond the scopeof .NET myServices, since users have no oppor-tunity to register different services as a part oftheir profile. Also, this project is still underdevelopment, and is not offered as a commercialservice yet.

2 The User Profile Web ServiceThe data model in Figure 4 shows a general out-line of the user profile, described in UML. Itshows how each user must have a general User-Profile where user specific data such as name,address, contacts, etc. can be stored. In additioneach user can have several UserApplicationPro-files where application specific data are stored.The content of ApplicationSpecific need not beunderstandable to any other than the service towhich it belongs.

2.1 Realisation AlternativesThere are many possible ways in which the userprofile could be realised and made available tothe user’s services and applications (from nowon called clients).

The user could for example carry all the datawith her. This could be done with the help of asmart card, but that would limit the solution todevices with the ability to read smart cards. Thelack of card readers and security mechanisms

Figure 4 User ProfileData Model

ApplicationRestriction ApplicationRoutingInfo ApplicationChargingInfo ApplicationSecurity ApplicationSpecific

UserApplicationProfile

ServiceRestriction RoutingInfo ChargingInfo SecurityInfo

UserProfile- name- address

UserData- address list- bookmarks

1 1

1

1111

1 1 1 1

0..*

11

0..1 0..1 0..1 0..1 0..1

1 1 1


makes this an unrealistic option. Besides thesolution would depend on the user not losingor damaging her card.

Instead we propose that the profile should bestored in a place reachable from all devices andservices in a programmatic way. The Internetand the World Wide Web seem like a naturalchoice, due to the ubiquity of the Web. By plac-ing the profile on a Web server it is accessiblefrom many fixed and wireless networks. Thereare however two problems that must be over-come. First of all the Web is more suited forretrieving data than submitting data back –which must be done to update the profile. It ispossible to use HTTP Post but this is not an idealsolution. Secondly, Web access is traditionallydone through a Web browser, while in our casewe need the service to be programmaticallyaccessible from the different clients.

One solution to these problems could be to useexisting approaches to distributed computing,such as COM+, CORBA, IIOP and Java RMI.There are however some serious problems con-nected with these approaches too, because theyput restrictions on the implementation details ofthe clients. First of all the client is often forcedto use the same technology as the service – e.g.a CORBA service cannot be accessed usingCOM+. Secondly the chosen technology canlimit possible limitations because they requirethe server and client to be implemented in a cer-tain way. For example, for a client to use JavaRMI it must be implemented in Java. The conse-quence of this is that the service will have to offerseveral different interfaces, or it will automati-cally deprive some clients of the possibility toaccess it without having to write a complex, ex-pensive and non-reusable interface to the service.

Another problem with these technologies is thatthey use tight coupling, which makes the solu-tions less flexible and less suited for using theWeb as the platform. Add to this that the tech-nologies are quite complex and heavy to imple-ment, plus the fact that firewalls are not handledvery elegantly, and it is no wonder that universalservices like our proposed user profile does notexist on the Web today.

2.2 XML Web ServicesIn this context XML Web services (see What isa Web Service in this issue of Telektronikk) con-stitutes a simpler technology for offering ser-vices on the Web. There is a couple of factorsthat make Web services the most suitable tech-nology for realising our service:

• Universal accessibility. The XML Web ser-vices specifications offer a higher level ofabstraction than the other technologies men-

tioned here (see How to Build a Web Servicein this issue of Telektronikk). By using XML-schema definition of data types and allowingany language and platform to map these to itsown representation it is possible to generateclients on any platform

• Loose coupling. This is the programmingmodel most suitable on the Web platform,since services will never be 100 % reliable.It also ensures that changes on either side donot affect the other party’s solution, as longas the interface is kept as it is. It also providesflexibility, since it becomes easy for a client toswitch to a new service.

• Simplicity. There is no doubt that skilleddevelopers are still needed, but the amount ofdevelopment that needs to be done is smaller,since the technology is simpler. This of coursealso means reduced functionality, but the planis to let the standard evolve as needs arise,instead of including everything from thebeginning. This wisdom originates from thesuccess of the Web, which has evolvedexactly in this way. Therefore the SOAP pro-tocol is designed with extensibility in mind.

• Industry support. With big players likeMicrosoft, IBM and BEA evangelising Webservices and implementing Web services stan-dards in their products, there is little doubtthat the new technology is something more

Figure 5 UPWSarchitectural overview

Figure 6 Use casesUser

(application)

Get Details

Set Details

System Border

Data store

ApplicationInterface

User

TrustedApplication

SOAP

User ProfileWeb Service


than a fad that will be gone in a year or two.The broad support means that most vendorsare already implementing the standards, sothat developers on many different platformscan get readily generated interface code with-out having to write much more than the busi-ness logic. It also means that the goal of100 % interoperability between differentplatforms is realistically obtainable.

As a Web service the user profile is accessible toany service that is connected to the Internet andable to talk and understand SOAP (on HTTP orany other transport protocol that the serviceprovider chooses to support). Since retrievingand updating the profile will be quite a costlyprocess in terms of time and bandwidth, themost suitable way to use the profile would be forthe client to download the relevant parts of theprofile at the beginning of a user session. Ifchanges occur the profile can be updated at theend of the session or whenever a user decidesduring a session.

Mechanisms must be in place to authenticateboth the user and the client of the profile service.Authentication can be as simple as basic authen-tication, but regarding that sensitive and per-sonal data will be transferred it would also bedesirable to use some kind of digital certificateand to encrypt sensitive data.

The end user can access the profile through aservice that uses the Web service interface, sincethe Web service itself cannot have a user inter-face. The resulting architecture is shown in Fig-ure 5. Thus the different clients will provide theuser interface, and if it is necessary the user pro-file provider itself can provide a client to allowfor easy administration of the profile.

The different clients will simply fetch user pro-file details and write back changed details. On ahigh level this results in the two use cases shownin Figure 6.

Set Details will have two different scenarios –one general and one for the first registration ofthe service.

Both scenarios require the user and client toauthenticate, so that the UPWS can give themaccess to the appropriate parts of the user profile.

3 Use ScenariosBy using the UPWS a user can

• access an updated contact list from any ser-vice requiring names, e-mail addresses, phonenumbers, fax numbers, etc.;

• access her favourite Web links from any Webbrowser on any device;

• automatically configure an application whosesettings are stored in the profile;

• automatically fill in Web forms;

• add new services to her profile on the fly.

4 ImplementationThere are several issues that must be resolvedwhen implementing the profile:

• Storage and retrieval of user profile data;

• 3rd party application access to and modifica-tion of user profile data;

• User access to and modification of userprofile data;

• Security;

• Providing the service;

• Consuming the service.

4.1 Storage and Retrieval of UserProfile Data

When deciding how to store and manage XMLdata there are at least four alternative ways to doit: In a file system, in a native XML database, ina modified object database or in a relationaldatabase. File systems and native XML data-bases are appropriate for storing XML docu-ments rather that XML data, the latter beingmore structured. Object databases have beenidentified as a natural storage for XML, buthave yet to prove their usefulness in this context.

When storing structured data, it is generally rec-ommended to use a relational database and thenextract the information from the database toXML when needed. Structured data will benefitfrom the relational model when it comes toretrieval, searching and aggregation of data.While this forces a need to transform, or decom-pose the original XML document, decomposingan XML document to be stored to a relationaldatabase is not all that difficult. Also, many rela-tional database vendors are implementing thinXML serialiser wrappers that enable them togenerate XML documents on demand from rela-tional data. So even if data will be coming in andgoing out as XML, e.g. in the form of SOAPmessages, they can and should be stored as rela-tional data.

One obvious advantage of using relationaldatabases is that the technology is mature, stable


and ubiquitous, and a whole range of tools existfor working with relational databases.

The service will extract the relational data intoXML documents before providing applicationsand users access to them. It will also have toextract data from XML documents to update thedatabase. Depending on the implementation,more or less of this functionality can reside inthe database itself. Different implementationswill have different ways of accessing data. The.NET development, for instance, will probablyuse ActiveX Data Objects for .NET (ADO.NET)to connect to data stores, while a J2EE imple-mentation will probably use JDBC (see Figure 7).

4.2 Third Party Application Accessto and Modification of UserProfile Data and Functions

We have already concluded that XML Webservices is the best alternative for realising theapplication.

The purpose of the User Profile Web Service isto give any other application access to the profiledata. After getting the data from the profile, anapplication can configure according to the set-tings defined in the profile. The applicationshould not have access to the whole profile,merely the parts relevant for the type of terminaland service in use, and according to user specifi-cations. This will be specified in the Applica-tionRestriction (see Figure 4). Based on theinformation retrieved from the profile service,the application can provide the user a person-alised service. The application must also beable to update the UserApplicationProfile thatbelongs to the calling application.

Since the service will be provided as an XMLWeb Service, the API will be a SOAP interface,described in WSDL format. The third partyapplication uses the WSDL file to understandthe interface and implement a client proxythrough which it can communicate with the Webservice. Through this interface the applicationcan both fetch the user profile data and returnnew or changed data to the user profile service(see Figure 8).

4.3 User Access to and Modificationof User Profile Data

The most convenient way to provide the useraccess to her data is through the applications thatwill be using the user profile service. To ensuredata privacy and integrity it is however impor-tant that different applications have limited readand write access to the data, otherwise a mali-cious application might change the user datawithout the user’s knowledge and consent. Thatis why restrictions are defined in the Applica-tionRestriction class.

Figure 9 shows how the user accesses the UserProfile Web Service through the user interfaceof a third party application.

Applications must be trusted by the Web servicein order to be allowed access. Depending on thetrust level, different parts of the profile might beavailable to the different applications. At leastone application should be completely trusted bythe Web service, so that the user can manage allher data through this application. The user pro-file provider itself could offer this application,or a trusted third party could offer it.

Third party applications could either be installedon the user’s device, or be accessible throughWeb interfaces such as HTML and WML. Whendelivered to the user as a Web application, anapplication could either provide one user inter-face (e.g. only HTML interface), or several userinterfaces (e.g. both WML and HTML inter-face). In the case of several interfaces, thesecould be provided as different, static interfaces,or as one dynamic interface, displaying differ-

Figure 8 Third partyapplication access to

the user profile service

Relational Database

3rd PartyApplication

SOAP(XML)

User Profile Web Service

Company Border

ADO.NET

JBDC

etc.

UserProfileWeb

Service

Company Border

SOAP(XML)

SOAP(XML)

SOAP(XML)

SOAP(XML)

3rdPartyAppli-cation

Fetch User´s Personal Data

Fetch Application Settings

Update User Data

Update Application Settings

Figure 7 Data storage and access


ently depending on the accessing device. Toachieve the last scenario the interface could bedescribed in XML, and XSLT style sheets couldbe used for generating the most suitable inter-face display (see Figure 10).

4.4 SecuritySecurity is extremely important in this service.Some of the data stored in the profile are per-sonal, sensitive information that the user must beable to trust will not be read or altered by anyoneelse than the user herself and the applicationsapproved by the user and the profile provider.

In addition to password authentication, securityprecautions would probably involve some use ofdigital certificates to further authenticate theclient, and to encrypt sensitive data. This can bedone using a secure key exchange protocol likeKerberos or HTTPS based on PKI key exchange.Applications should only gain access to relevantdata, in order to protect the service from misuse.

Security is a complex issue, depending verymuch on the context in which it is implemented.Therefore it is not appropriate to specify adetailed security design here.

4.5 Providing the User Profile WebService

When the data store and business logic of theservice is implemented on the provider’s plat-form, some kind of XML Web services frame-work is needed in order to make the serviceavailable to others. This can be done either withMicrosoft’s .NET framework, or with a J2EEimplementation that supports XML Web serviceprotocols. As soon as this is done, the service isavailable on the Web. The service can be in-voked by sending the appropriate SOAP mes-sages to the appropriate URIs, and what theseare is specified in the WSDL document, whichis also available on the Web.

Next, potential users of the Web service (thirdparty applications) must be aware of the service.One way is telling partners and other chosenactors about the service, and where they candownload the WSDL document. While a goodand secure way of testing the service to beginwith, it does not meet the requirements of globalubiquitous accessibility from any application. Toachieve this the service must be published in aglobal registry that can be searched by possibleclients. XML Web Services specifications there-fore also include the UDDI registry for universalregistration and discovery of XML Web Ser-vices.

Publishing the service to the UDDI registry doesnot only mean that the service must be 100 %stable and available, it also means that it mustimplement security precautions ensuring thatthe service will only be accessed by applicationsthat are authenticated and authorised to use it.A UDDI broker might offer some security andguarantees, but the service provider must alsoconsider which security mechanisms that arenecessary to implement in the service.

Users of the service can either be approved auto-matically online (e.g. with the help of authenti-cation and contract services provided by the bro-ker), or contracts can be negotiated manually,“off-line”. Which model is best suited is a mixof security concerns, business model (e.g. are theusers supposed to pay for using the service) andavailable solutions (e.g. how much is alreadyoffered by the broker).

4.6 Consuming the User Profile WebService

As discussed in the previous section, a client candiscover the service through a UDDI registry orby direct communication with the provider.After discovering the service and obtaining thenecessary access keys (passwords, certificatesor other things that the XML Web service mightrequire), the client must build a proxy to com-municate with the Web service. This is gener-

Figure 9Applicationusing theUPWS forpersonalisationof its servicesto the end user

Figure 10 Dynamic userinterface using XSL

3rd PartyApplication

InterfaceProvider by3rd Party

Application

?

UserFetch UserProfile Details,

Set UserProfile Details

User Profile Web Service (SOAP interface)

Data Store

HTML,WML,etc.

User

TrustedApplication


SOAP

XML

XML


ated automatically from the information in theWSDL file and integrated into the client’s soft-ware project. Now the client can call the proxymethods as if they were local methods. Howthese methods should be called and how theresults should be handled is entirely up tothe client application.

If the client for instance is granted access to theuser’s bookmarks, it will probably see a methodcalled something like getBookmarks. By callingthis method the client would obtain the user’sbookmarks. The client application is then freeto do with them whatever it wants, but it wouldprobably choose to store them in the user’s localbookmarks folder. If the client application werethe Internet Explorer Web browser, it wouldprobably store them in the “Favourites” folderbelonging to the user.

4.7 UML Application DesignThe Object Management Group (OMG) speci-fies a modelling language called Unified Mod-elling Language (UML) (Object ManagementGroup, 2001), which aims at enabling imple-mentation independent design of applications.This modelling specification has become verypopular and is implemented by a number of ven-dors, e.g. Rational and Telelogic.

To provide an overview of the user profile ser-vice design, three kinds of UML diagrams areshown here. First some use cases are presentedto show how other applications will interact withthe service. Then data objects are shown in aclass diagram. Lastly the use cases are elabo-rated in sequence diagrams, depicting how thedifferent data objects will interact in each usecase.

4.7.1 Use Cases and Class DiagramThe use cases show how actors may interactwith the user profile service. In use case dia-grams the actor, or user, can be either an enduser, or another system (application) using theservice.

Figure 6 shows a simple use case diagram. Itillustrates the main use of the system, namelyreading user profile data, and saving new ormodified data.

To be more accurate it is necessary to design adata model that shows what kind of data the userprofile service will contain.

Telecom user profiles would constitute a goodstarting point for the service. But telecom userprofiles as defined have many limitations. Theuser profile is intended for customisation of themain service, namely voice communication ortelephony, and its supplementary services, e.g.

call forwarding, call answering, etc. It is alsostored within the operator’s system and is notavailable to third party applications or services.In order to allow the users access to multipleapplications and services anytime, anywhereand on any terminal, the content of the user pro-file needs to be extended to fulfil the followingrequirements:

• For each user the user profile must be expand-able to incorporate the preferences and set-tings for any additional application or servicethat the user requires.

• For each application the user profile must con-tain the information necessary for the presen-tation of the application on the terminal typesrequested by the user.

• For each application the user profile must con-tain usage restrictions.

• The user profile must incorporate personaldata such as address book, telephone list,bookmarks, etc.

In accordance with these requirements, a datastructure for the user profile is proposed in UML(Unified Modelling Language) in Figure 4.

The UserProfile has six components: UserData,ServiceRestriction, RoutingInfo, ChargingInfo,SecurityInfo and UserApplicationProfile.

UserData contains for example addressList,bookmarks, etc.

ServiceRestriction has attributes such as:• Roaming restriction• Time restriction• Credit limit• Maximum number of terminal addresses for

group registration for incoming applications• Incoming screening• Outgoing screening• List of subscribed services

RoutingInfo has attributes such as• Forwarding activation status• Registered terminal address for incoming

applications• A linked-registered terminal address• Default terminal address for incoming appli-

cations• Routing by applications originating area• Routing by calling party identity• Time-dependent routing• Routing on “busy” condition• Routing on “no answer” condition• Default duration (or number of calls) for

incoming applications registration


ChargingInfo has attributes such as• Default charging reference location• Charging option selected• Temporary charging reference location• Advice of charge activation status

SecurityInfo has attributes such as• Authentication procedures subscribed• Security options subscribed• Type of authentication procedures activated• Max number of failed authentication attempts• Password

The UserProfile may contain zero or more User-ApplicationProfiles. The purpose of the UserAp-plicationProfile component is to enable customi-sation of an application. For each application(run in a service session), there may hence beassigned zero or one UserApplicationProfile. TheUserApplicationProfile may contain zero or oneApplicationRestriction, ApplicationRoutingInfo,ApplicationChargingInfo, ApplicationSecurity-Info and ApplicationSpecInfo. It is therefore pos-sible to specify the restrictions, routing, charging,and security options for each application.

The ApplicationSpecInfo is a component thatcontains application specific data. Greater flexi-bility is achieved in this way. An application ishowever not required to have its own UserAppli-cationProfile. For applications that do not havetheir own profile the main UserProfile is appliedat the initiation of the application. The usershould have access to a service that permits himto interrogate and modify some of the attributesof his UserProfile. His access rights are linkedto and used by an access control procedure.

While all these classes are important in a work-ing telecom user profile application, some ofthem fall outside the scope of this thesis. Focus-ing on the usage of XML Web services in orderto provide access to data, the classes mostimportant in this setting are UserProfile, User-Data, UserApplicationProfile and UserApplica-tionSpecific, since these must be accessible fromthe third party application.

RoutingInfo, ChargingInfo, ApplicationRouting-Info and ApplicationChargingInfo deal withrouting of calls and the operator’s basis forbilling the customers, and will not be discussedfurther here. For the sake of simplicity theseclasses are omitted in the rest of the design.

ServiceRestriction in telecom profiles is mainlyused for time- and place restrictions, and theApplicationRestriction can serve the same pur-pose. However, ApplicationRestriction can alsobe used for restricting the application’s privi-leges; i.e. regarding access to the user profile datasuch as bookmarks and personal data. Securityand ApplicationSecurity can be used for authenti-cating and authorising the user and application.

Figure 11 shows a more detailed use case dia-gram. The user of the service must be able tofetch and alter some of the objects in Figure 4,namely the UserProfile, UserData, UserApplica-tionProfile and UserApplicationSpecific. Theother classes are for internal use, and will notinteract directly with the user.

In the next section, these use cases are elabo-rated into sequence diagrams, showing whatmust happen on the inside of the system oncea use case occurs.

4.7.2 Sequence DiagramsSequence diagrams are drawn for each of the usecases, and often as several scenarios for each usecase. The purpose is to show how the system’sobjects must interact when an actor is using thesystem.

Figure 12 and Figure 13 show the sequence dia-grams for get and set UserProfile. After the useris authenticated, application restrictions arechecked to prevent the application from alteringdata that this particular application does not havewrite access to. If the application is allowed, theuser profile object will be updated accordinglyand a confirmation is sent back to the callingapplication.

Get and set UserData are similar to get and setUserProfile, and are only shown in the appendix.

Figure 14 shows how UserApplicationProfile isfetched. Each application should have access to

Figure 11 Detaileduse case diagram

User(application)

Get UserProfile

System Border

Set UserProfile

Get UserData

Set UserData

Get UserApplicationProfile

Set UserApplicationProfile

Get UserApplication Specific

Set UserApplication Specific


Figure 12 Sequence diagram: get UserProfile

Figure 13 Sequence diagram: set UserProfile

User(application)

System Border

getUserProfile(userID, password, appID)

(OK?)

authUser(userID, password)


SecurityInfo ApplicationRestriction

UserProfile

(ApplicationRestriction)

getRestriction(userID, appID)

(UserProfile)

getProfile(userID, appIDApplicationRestriction)

(UserProfile)

User(application)

System Border

setUserProfile(userID, password, appID, UserProfile)

(OK?)



SecurityInfo ApplicationRestriction

UserProfile

(ApplicationRestriction)

getRestriction(userID, appID)

(OK?)

(OK?)

updateProfile(userID, appIDApplicationRestriction, UserProfile)

all data in its specific UserApplicationProfileobject, so there is no need to check restrictions.Otherwise get and set UserApplicationProfile issimilar to get and set UserProfile.

Get and set ApplicationSpecific are similar toget and set UserApplicationProfile and are onlyshown in the appendix.

The preceding diagrams have shown the mostcommon use case scenarios. Another scenario

for the use cases is when the user or applicationis not yet registered in the user profile.

Figure 15 shows how a New Application sce-nario could be handled.

The procedures for registering a new user willnot be drawn here, since it depends on how thecompany offering the user profile chooses toinclude new users. Telecom companies couldoffer the service to existing customers, since


data about them would already be stored. In thatcase, an activation procedure where the customeragrees on the service terms may be all that isneeded to register the new user.

5 Business ModelAn actor that can be trusted both by the user andthe service provider must host a service like this.The user needs to be certain that her data will

Figure 14 Sequencediagram: get User-ApplicationProfile

Figure 15 Sequencediagram: set User-ApplicationProfile,new applicationscenario

User(application)

System Border

getUserApplicationProfile(userID, password, appID)

(OK?)



SecurityInfo UserApplicationProfile

(UserApplicationProfile)

fetchProfile(userID, appID)


User(application)

System Border

setUserApplicationProfile(userID, password, appID,

userApplicationProfile)

(OK?)



SecurityInfo


registerProfile(userID, appID)


User(application)

setUserApplicationProfile(userID, password, appID,

userApplicationProfile)

(OK?)


(OK)

setProfile(userID, appID)


UserApplicationProfile


not get lost or accessed by unauthorised parties.The service provider on the other hand wouldalso need to be sure that the service specific datawould not be altered without permission fromthe service, and that the user data are correct.Telecom providers already maintain extensiveuser profiles to configure their communicationservices, and the user data are validated in thesense that correct information about real usersis ensured. As such telecom companies or othercompanies with this kind of customer informa-tion, and also government administrations havea starting point for providing such a service. Tosecure customer rights it is possible to imaginethat several such institutions would cooperate inproviding the user profile.

Several payment schemes can be imagined. Firstof all it is a question of who should pay for theservice – the user, the service provider or both.Secondly it would be possible to charge eitherper use or per time unit (e.g. monthly fee). Prob-ably a mixture of the different possibilities couldbe offered, but we will propose one model here.

We assume that a telecom company chooses tooffer a user profile service to its customers.These customers already pay a monthly sub-scription fee, and the service could be offered asadded value to certain subscription types, or inreturn of an additional monthly fee. To ensurethat the service will actually be useful to the cus-tomers, any application can access the servicefor free. Subscribing to this service then, the userwould be able to use it with any of her servicesthat have chosen to implement the service. Sinceclients are easy to make, many service providersmay consider this a cheap way to add significantvalue to the service.

6 Issues to Resolve andFurther Work

This paper has merely presented a draft of a pos-sible Web service: The user profile Web service.There are, however, several issues related to theuser profile that need to be resolved before a realand commercial Web service can be offered.

6.1 Legal ConsiderationsStoring user data demands a permit from author-ities, and the ability to obtain such a permit is animportant issue to consider. A provider mustalso be prepared to prove that user data will notbe available to third parties without the user’sfull and cognisant consent.

6.2 Privacy Considerations and UserAcceptance

Apart from the legal considerations there is adistinct ethical issue about storing and managingpeople’s personal data. In the kind of service

provided here this issue becomes even more vis-ible, since the scope is to include as many of theuser’s data as possible. Users are concernedabout privacy, particularly on the Internet (Cra-nor et al. 1999). Although the goal is to providethe user and the user’s services with a valuableservice that will make data management easieron all parts, it is easy to see how motives can bequestioned, and users are and should be scepticaltowards putting all their data in the hands of one,big actor. It becomes extremely important thatthe provider is regarded as a fair and trustedactor. This is yet another reason for severalactors to ally – the notion of several actors work-ing together may increase credibility.

6.3 Technical ConsiderationsOur tentative data model is not complete, andparticularly there is a need to discuss which datashould be user specific and which should beapplication specific. One should also considerthe use of application categories to enable shar-ing of data between different applications in thesame application domain. There are also manyimplementation specific aspects that must be dis-cussed, such as security architecture and whichplatform to use.

7 ConclusionWe have described an application called theUser Profile Web Service. This applicationallows users to store preferences and personaldata in a central profile, with the purpose ofgranting different services access to it. In thisway the proposed application allows the user’sservices to self-configure.

The enabling technology for the User ProfileWeb Service is XML Web Services. Using XMLWeb Services allows services on any platformand device to take advantage of the user profile,as long as they can use the Web services proto-cols and compliant transport protocols (e.g.HTTP or SMTP). A realisation of this servicewould offer great enhancement of user mobilitysince it would allow for personal configurationof a user’s services independent of time, placeand device. However, the work is in an earlystage and there are several issues that need to beresolved first – both on the technical level andbusiness considerations.

8 Further ReadingCranor, L, Reagle, J, Ackerman, M S. (1999).Beyond Concern : Understanding Net Users’Attitudes About Online Privacy. AT&T Labs-Research Technical Report TR 99.4.3. August16, 2002 [online] – URL: http://www.research.att.com/resources/trs/TRs/99/99.4/99.4.3/report.htm