Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings Universitet SE-601 74 Norrköping, Sweden 601 74 Norrköping

LiU-ITN-TEK-A--08/006--SE

Design and implementation of anintegration platform for

telematics servicesFredrik Jonsson

Lina Larsson

2008-01-29

LiU-ITN-TEK-A--08/006--SE

Design and implementation of anintegration platform for

telematics servicesExamensarbete utfört i kommunikations- och transportsystem

vid Tekniska Högskolan vidLinköpings unversitet

Fredrik JonssonLina Larsson

Handledare Jesper BonanderExaminator Di Yuan

Norrköping 2008-01-29

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Fredrik Jonsson, Lina Larsson

Acknowledgements

This work is done on behalf of Cybercom Sweden West for the purpose ofinvestigating the possibilities of system integration between mobile and sta-tionary systems within the transport and logistics sector. Great thanks tothe following people:

Jesper Bonander, project supervisor, CybercomMagnus Carlsson, project sponsor, CybercomDavid Gundlegard, project supervisor, Linkoping UniversityJohan Hoff, consultant, CybercomNiklas Mattsson, consultant, CybercomDi Yuan, examiner, Linkoping University

Abstract

Many companies within the transport and logistics sector faceproblems with integrating telematics and information systems withintheir organizations. The problem is often the lack of standardiza-tion between different solution providers. Cybercom Telematics ProxyPlatform (TPP) aims to bridge these different systems together by act-ing as a message broker. In the thesis the MSI Group XML formatwas chosen as the internal format of TPP. As a technical platformMicrosoft BizTalk Server was chosen instead of developing a C# ap-plication from scratch. A demo solution with two fictive externalsystems was developed and proved TPP possible to work as a brokerbetween a mobile and a stationary system.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aim of the project . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . 11.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.1 Data format . . . . . . . . . . . . . . . . . . . . . . . . 21.4.2 Demo application . . . . . . . . . . . . . . . . . . . . . 2

1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5.1 Microsoft platform . . . . . . . . . . . . . . . . . . . . 21.5.2 XML standard . . . . . . . . . . . . . . . . . . . . . . 21.5.3 Mobile office . . . . . . . . . . . . . . . . . . . . . . . . 21.5.4 External systems . . . . . . . . . . . . . . . . . . . . . 3

1.6 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 The concept of TPP 52.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Brief architectural description . . . . . . . . . . . . . . . . . . 62.3 Architectural context . . . . . . . . . . . . . . . . . . . . . . . 7

3 An internal data format 93.1 Data representation . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Existing XML formats . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Freightwise . . . . . . . . . . . . . . . . . . . . . . . . 103.2.2 Universal Business Language (UBL) . . . . . . . . . . . 103.2.3 Transport XML . . . . . . . . . . . . . . . . . . . . . . 103.2.4 Pharos Mobile . . . . . . . . . . . . . . . . . . . . . . . 113.2.5 MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.6 MSI field tests 2006 . . . . . . . . . . . . . . . . . . . . 12

4 Technical platforms for integration 144.1 In-house C# solution . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 144.1.2 XML handling and transformation . . . . . . . . . . . 154.1.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.4 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.5 Process overview and management . . . . . . . . . . . 15

4.2 BizTalk Server Solution . . . . . . . . . . . . . . . . . . . . . . 154.2.1 Connectivity through Adapters . . . . . . . . . . . . . 164.2.2 XML-handling and transformation . . . . . . . . . . . 16

4.2.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 184.2.4 ”Routing” by Orchestrations . . . . . . . . . . . . . . . 184.2.5 Business Process Management . . . . . . . . . . . . . . 19

5 System description 205.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Stationary system . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.4 TPP core engine . . . . . . . . . . . . . . . . . . . . . . . . . 225.5 Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.6 Mobile system . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 User case description 256.1 Sending a new order . . . . . . . . . . . . . . . . . . . . . . . 25

6.1.1 ASP.NET web page and the Order management database 256.1.2 Transport planner integrator . . . . . . . . . . . . . . . 276.1.3 Core engine orchestration . . . . . . . . . . . . . . . . 276.1.4 Telematics provider Connector . . . . . . . . . . . . . . 286.1.5 Telematics provider database and PDA application . . 28

6.2 Sending status updates . . . . . . . . . . . . . . . . . . . . . . 286.2.1 Telematics provider database and PDA application . . 286.2.2 Telematics Provider Connector . . . . . . . . . . . . . 286.2.3 Core engine orchestration . . . . . . . . . . . . . . . . 296.2.4 Transport planner integrator . . . . . . . . . . . . . . . 296.2.5 ASP.NET web page and the Order management database 29

7 Discussion 307.1 The relevance of TPP . . . . . . . . . . . . . . . . . . . . . . . 307.2 Choosing a XML-format for telematics . . . . . . . . . . . . . 307.3 Technical platform for TPP . . . . . . . . . . . . . . . . . . . 317.4 To make TPP production ready . . . . . . . . . . . . . . . . . 327.5 Extending TPP with in-house tools . . . . . . . . . . . . . . . 32

8 Conclusion 33

References 33

Glossary 36

1 Introduction

1.1 Background

Cybercom has a long experience of being a competence and solutions providerwithin the vehicle and transport industry, involving Volvo, Scania, Autolivand Schenker as customers. The interest in telematics solutions is increasingrapidly and Cybercom has an ambition of being one of the leading providersof competence and platforms. A part of Cybercom’s investment in telemat-ics is the idea of providing a telematics proxy. A proxy is a broker linkingsystems with different API:s and protocols together. The concept is calledthe Cybercom Telematics Proxy Platform (TPP) and will be a telematicsplatform integrating different systems within the transport and logistics in-dustry in a cost-efficient way. The features of this platform can be dividedinto three areas; Fleet Management, Transport Management and Security,all requiring both integration solutions and tools for monitoring information.Fleet Management involves information about the vehicle like positioning,vehicle diagnostics and driver performance. Transport Management dealswith sending transport orders, invoices and routing information and the Se-curity part handles alarm and alert data like geofencing, panic button andsurveillance camera. Each of these areas require its own integration mannersand tools for monitoring data. This thesis however, will treat the TransportManagement part of TPP, focusing mainly on the integration solution. Thispart will from now on be referred to as TPP.

1.2 Aim of the project

The thesis should explore the Transport Management concept ”Mobile Of-fice”, that is, all information sent between vehicle and transport managementsystem that concerns the administration of a transport. The two foremostobjectives are determining a suitable data format to be used for internalcommunication within TPP and also developing and evaluating a technicalsolution. To test the solution derived, a functioning demo should be imple-mented. The demo should span from a PDA as a client through TPP and toa fictitious order management system - a standard PC.

1.3 Problem formulation

What would be a suitable specification of an XML-based format for MobileOffice information within TPP? Based on the idea of TPP, what would bean appropriate technical solution?

1

1.4 Method

The method of approaching these problems was to split the assignment intotwo parts; finding and investigating a suitable data format and implementinga demo using the format specified or chosen. These tasks were solved partlyin parallell during the project, however the search for data formats was ofcourse completed of before the final implementation process began.

1.4.1 Data format

To find and evaluate the XML standards suitable for Mobile Office informa-tion that exist today a survey was done. In addition, interviews were donewith representatives from different actors in the transport and logistics in-dustry, each of them experienced within the field of standard interfaces. Theevaluation of the formats was based on a set of criterions that were set up.

1.4.2 Demo application

Before implementing the actual demo different approaches were studied. AC# solution was investigated followed by a process of investigating BizTalkServer and its integration possibilities. To finally implement the demo aset of user cases were specified, setting up the desired functionality of theplatform.

1.5 Scope

1.5.1 Microsoft platform

The demo was developed using Microsoft Visual Studio. This in turn causedthe use of C# as a program language. The existing integration platformused was due to the Microsoft platform Microsoft BizTalk Server. The PDAapplication was developed for a PDA running Windows CE 5.0, a Windowsoperating system for embedded and mobile devices.

1.5.2 XML standard

The data format used for information within TPP is based on the XMLstandard.

1.5.3 Mobile office

The expected function of TPP was to handle Mobile Office information.Cybercom defined Mobile Office through the following tasks:

2

• Real-time information exchange between driver and dispatcher

- Diving orders

- Route information

- Loading and unloading reports

- Invoicing

- Payment

- E-mail, SMS, Instant Messaging (IM)

• Onboard navigation

• Cargo handling

- Barcode reading

- RFID support

A selection of these functions was necessary for the implementation. A deci-sion was made that the new functionality focus area should be sending andreceiving transport orders and reporting loading and unloading.

1.5.4 External systems

External systems used in the demo were a standard PC as the server orstationary system and a Windows CE enabled PDA as the client or themobile system. Links from the external systems to TPP are presumed tobe of TCP/IP nature. Priority was given to implementing the actual demorather than investigating transmission protocols.

1.6 Disposition

• Section 2 gives background and motivation to the thesis, describingthe general problems associated with system integration, followed by aconceptual description of TPP.

• Section 3 describes the need of a proper data format and presents someexisting formats.

• Section 4 treats technical solutions for integration platforms and sug-gests some solutions for TPP.

• Section 5 presents the solution derived on a conceptual level, with adescription of the message flow and the components chosen.

3

• Section 6 gives a more detailed system description exemplifying a mes-sage flow.

• Section 7 makes the discussion of the solution, giving recommendationsand discussing further development.

• Section 8 represents the conclusion of the thesis.

4

2 The concept of TPP

2.1 Motivation

The general practice today when implementing a telematics solution in thetransport industry is to make a custom integration between the systems thatare to be connected. [1] This is generally because that is the fastest way toconnect a new system to an organization. Later on however, a system mightneed to communicate with more than one other party, mobile or stationary.Each pair of these systems then has to be integrated separately. Each newmobile system introduced to the organization has to go through the sameprocess of integration towards its systems. If any system was to be updatedin some way, possibly many integrations would need to bee updated too,one for each connected system. Even a relatively small amount of mobileand stationary systems causes a solution that is quite hard to maintain, asillustrated in Figure 1. To avoid the situation with frequent updates, somecompanies instead choose to minimize the number of involved systems usedin their organizations. In doing so, switching to another system later oncould be hard, even though that solution would be more profitable. Thecompany becomes limited to very few systems, and adapting to changes inthe telematics market could definitely be an exhaustive process.

Enterprise Application Integration is a concept that could be a solutionto integration problems. The idea of this solution is to have a middlewareinstalled between the systems. This middleware would act as a message bro-ker, generally a third-party solution that would handle all transfers betweenparts of the organization or different organizations. The reason for havingthis middleware would then be to resolve integrations in a structured wayand to ease future integrations.

5

Figure 1: The situation arising when performing one-to-one integrations.

2.2 Brief architectural description

By using the middleware solution, messages in one host would be sent tothe other via TPP. The architecture can be described by three types of com-ponents, depicted Figure 2. The parts of TPP that interact with externalsystems have been defined as connectors and integrators. Connectors andintegrators are components interfacing mobile and stationary systems, re-spectively. What characterizes these components is that connectors haveanalogous ways of being implemented and function despite distinct mobiledevices. The same applies on integrators, having somewhat similar ways ofbeing implemented regardless of the type of stationary system. The thirdcomponent is the core system, the engine that handles the actual integra-tion. Assume a transport planner wishes to send a job order to the driver ofa specific vehicle. He or she sends the order from the transport managementsystem, coded in its own format and using its own communication mecha-nism. The TPP integrator receives the message, converts it into an internalformat for transport orders and passes the message to the core engine, whereit is routed to the right connector facing the receiving peer (i.e. the rightvehicle). The connector converts the TPP order message to the local mes-sage type for orders on the PDA. The point of the internal format insideTPP is that it should be able to convert between many external formats,that is, TPP should be able to communicate with many different mobile andstationary systems.

6

Figure 2: The solution of a broker handling messages.

2.3 Architectural context

The concept of a proxy, a message broker could architecturally be oriented innumerous ways. [2] In [2], a number of paradigms for distributed computingis presented, that put different applications into certain contexts. TPP asa broker architecture is a Client-Server model in the sense that the clientand the server have asymmetric roles in a collaboration process. The clientshould for example not be able to issue a transport order, only the ordermanagement system should have that capability. Another property of thismodel is that the client specifies requests of a specific service provided bythe server, which is in turn answered by the server. The paradigm doesnot allow the server to initiate communication. However, in TPP that is adecision to be made by the developers. The opposite scenario could happenhere; the server might want to send a request to the client, for example askingthe client to accept an order, without requesting a specific service from theclient.

Although it is possible to put TPP into a client-server context, it is moreimportant to highlight the role of the middleware. One paradigm that couldrepresent the broker solution is The Message-Oriented Middleware (MOM)paradigm. The MOM paradigm describes a solution where a middlewareserves as an intermediary among separate processes, through which mes-sages are switched asynchronously. Two message models exist within theparadigm; the Point-to-Point message model, where the sender deposits mes-sages via the middleware into the queue of the receiving process, and the

7

Publish/Subscribe model, where the sender publishes messages via the mid-dleware that are subscribed by a receiver or a group of receivers. Which mes-sage model that suits TPP depends on the expected functionality of TPPand the development of the solution. The important aspect of the brokersolution is the actual intermediary being a connection between the senderand the receiver and its ability to handle heterogeneous systems.

8

3 An internal data format

3.1 Data representation

In order to send messages between different systems through a platform, acommon representation of the data is required. One system may provideone piece of information, while another would provide a different. Generallythere is a need for a data format containing tags enough to support anytype of data transmitted in that specific system. The platform shouldn’thave to be updated every time a new system with a new message type isconnected. The XML standard was chosen for this purpose because it wasspecified in the project assignment but also because it is a de facto standardfor information exchange within data communications. In [3], it is statedthat XML facilitates mobile system integration.

What is required for TPP is an XML format capable of handling theinformation presumed to be sent in a telematics system. This data, thetelematics data can be defined as all the information exchanged between ve-hicle and transport planner during a transport. In addition, TPP shouldbe extendable to more functions like sending for example vehicle diagnosticsand position data, wherefore the XML format should also support these func-tions. A proper XML format could either be fully developed using our ownlist of requirements and guesses about relevant data, or an existing formatcould be used. Many existing formats contain XML tags supporting purebusiness data, such as invoices and purchase orders. There is a fair differ-ence in integrating systems sending this type of data than systems sendingtransport-related data. From a Mobile Office point of view it is irrelevantwhere the invoices should be sent or who issued the original purchase order,and from a business point of view the fuel consumption or exact position ofthe vehicle are useless information. TPP should focus on real-time telemat-ics information, hence the challenge was to specify a format with sufficientsupport for that.

3.2 Existing XML formats

Two suggestions were given by the supervisor at Cybercom; MSI-group (Mo-bile Stationary Interface Group) - a Swedish consortium, and ITS (IntelligentTranportation Systems) - a part of US department of transportation. Thestandards provided by ITS appeared to be too narrow and divided into differ-ent sectors, such as only Emergency Management. ITS focuses on road andtraffic, not so much the transport planner and vehicle. A few other standardformats were taken into account. These formats where chosen from a set of

9

criterions that were set up in order to facilitate the selection from the widerange of XML formats that exists today. The criterions are the following:

• XML - the format should be based on the XML standard

• Availability - the format should be available to use at this time

• Transport - the transport part of the format should be sufficient forpresent and preferably future functions of TPP:

- Handle transport orders and loading/unloading updates

- Handle Fleet Management data such as vehicle diagnostics

- Handle driver data such as time reporting

3.2.1 Freightwise

Freightwise is a project initiated by EU and German consultancy BMT. EU’s6th Framework Programme in which Freightwise is being developed within isintended to bring together transport management, traffic and infrastructuremanagement and administration [4]. The project focuses on cooperationbetween these three sectors to ease the development of solutions and integrateexisting systems for intermodal transports. The objective is to shift cargotransports from road to intermodal transports, that is, introducing shortsea shipping, inland waterways and rail to the road transports to find theoptimal utilization of different transport types for each transport. However,since the standard and framework are to be introduced in 2010 it was notfurther considered.

3.2.2 Universal Business Language (UBL)

The UBL is an attempt of defining an XML library of business documentssuch as purchase orders, invoices etc [5]. The format handles the whole orderchain from product catalogue to handling of purchase order and issuing ofthe invoice. It was developed by The Organization for the Advancement ofStructured Information Standards (OASIS), a global consortium that devel-ops and supports web service standards and e-business solutions. Havinglooked at the content of the format, it appears to miss substantial supporttelematics data, which is required for TPP.

3.2.3 Transport XML

Transport XML was founded by the Norwegian organization Norstella. Theformat concentrates on two functional ares; Transport Job and Track&Trace

10

[6]. Transport Job involves all message data that is transmitted before, dur-ing, upon completion of and anytime after a goods transport is performed.The Track&Trace function includes all requests, responses and reports onadministrative and operational events, that is for example loading and un-loading. Implementing TPP with Transport XML would solve the basic re-quirement of order handling. TPP however, is meant to be a general solutionwherefore this format failed due to its narrowness.

There is a present development of a format called Shortsea XML that isan extension of Transport XML. The format is a message standard for com-munication between all parties in the short sea transport chain [7]. It coversa wider spectrum of services in the order chain than Transport XML, includ-ing for example invoicing, customs clearing and documentation. However thefocus area along with the fact that the format is built on Transport XMLwhich is in turn inappropriate for TPP left this format out of consideration.

3.2.4 Pharos Mobile

Pharos Mobile is an XML format developed by e-com Logistics, subsidiary ofSwedish International Freight Association. Like the Universal Business Lan-guage, it is too much focused on business data to suit a telematics platform.The format is not so much aimed for haulage contractors but more for for-warding agents [8]. TPP requires a format that has support for informationat the end of the informatics chain, down to the mobile system. A formatfor forwarding agents likely contains information that is more usable higherin the informatics chain.

3.2.5 MSI

MSI Group is a Swedish consortium that aim to ease the use of mobileand stationary systems within the transport sector [9]. The members ofMSI Group are representatives from the transport industry and providers ofmobile and stationary systems, such as Volvo, PocketMobile and IBS. Theorganization was founded through a research project, ”Nyttoskapande IT forakeriverksamheter” in July 2003, founded by Vinnova and coordinated byViktoriainstitutet AB. The project took form as a survey, involving repre-sentatives from organizations within markets for mobile systems, stationarysystems and costumer organizations, intending to highlight the problems ex-perienced with information technology in the transport business. One com-monly experienced problem was the way mobile and stationary systems areput together. User organizations felt limited by the proprietary interfacesprovided by the suppliers. The outcome of this survey resulted in the devel-

11

opment of a standardized interface, Mobile Stationary Interface (MSI). Thisinterface is an XML standard containing tags that support a great amountof the information exchanged in a telematics system. Since the standardwas developed all together with the major players in the Swedish transportmarket, it should be wide enough to meet the requirements from the telem-atics industry today. MSI Group has a more ambitious goal though thanMSI being just a data format. The organization wants to develop a com-plete new standard for the communication between mobile and stationarysystems. This includes a collaboration protocol specifying how to addressanother host, session handling and other collaboration aspects. Figure 3shows a subset of the MSI format.

3.2.6 MSI field tests 2006

Some field tests were done with MSI during summer 2006 proving that MSIworks as a format in real systems. The tests were carried out at two sites in-volving two stationary systems - Transport Management Systems (TMS) andone mobile system - Telematics Service Provider (TSP). One TMS involveda third-party integration server in the integration of MSI, and the other usedtheir own infrastructure. The part of the format that was tested was onlythe Assignment representation of the schema, depicted in Figure 3. The in-formation in this tag contains information only about the actual transportorder. The result of using MSI was that more parties of the integration chainhad to adapt to the interface than in the usual case. The typical case whennot using MSI is that the TMS uses a proprietary interface that the TSP hasto adapt to. The TMS then generally controls the implementation process.With MSI both TMS and TSP had to adapt to the interface, causing certainfrustration among the participants of the tests. Furthermore the collabora-tion protocol does not yet in MSI, as stated in section 3.2.5. This causedmuch interaction between the TMS and the TSP, pointing on the weight ofhaving such a protocol [10].

Very little can be said about the functionality of MSI after having lookedat the test results, since such small representation of the structure was appliedon the tests. [11] However, the collaboration protocol in MSI is essential forcommunication and without it MSI would loose its meaning.

12

Figure 3: The Assignment tag in MSI, representing a transport order of anykind.

13

4 Technical platforms for integration

A technical platform in this thesis is defined as the hardware and softwarecombination that manages the requests from the peers. The main functional-ity of TPP is the ability to manage requests from telematics peers. There arenumerous ways of achieving this but the two alternatives considered here area Web Service solution in C# and a BizTalk Server solution. The followingaspects were evaluated in order to find a suitable platform.

• Connectivity - how easy standard protocols and widely available APIscan be used.

• XML handling and transformation - the support for handling and trans-forming XML documents.

• Reliability - the system’s ability to handle errors and unexpected situ-ations.

• Routing - how convenient the support is for a message routing mecha-nism.

• Process overview and management - if it’s possible to overview andtrack errors and progress.

4.1 In-house C# solution

One way to develop a technical platform is to write it from scratch. Thiswould require plenty of work but lead to great flexibility and control. Thetechnical platform would only have the limitations that are built into it bythe TPP programmers. To communicate between connector, core engine andintegrators Web Service techniques could be used. This way the system wouldbecome more flexible and the different parts of the solution could be hostedat different machines and TPP wouldn’t be bound to the .NET frameworkbecause many platforms (i.e. Java) have support for Web Services. Of courseother ways of communication could be considered but a Web Service-basedsolution was seen as the most flexible, however not the technique with bestperformance.

4.1.1 Connectivity

The .NET platform provides a comprehensive list of APIs to connect to allkinds of ERPs (such as SAP), web services and database systems. Havingthat said it still requires the developer to handle the communication in manyways.

14

4.1.2 XML handling and transformation

Support for XML is essential in the .NET framework. Reading, writing andtransforming XML data is convenient. With help of XSLT it’s not hard tomap one XML document to another form, i.e. from an OEM-format to astandard telematics-format.

4.1.3 Reliability

Being a general programming language, C# would require a solution thatneeds to build up an own way of handling errors and failures. No messagescan be tolerated to be lost due to an internal error of the TPP platform.The mechanism for this needs to be implemented in a structured way thatcan almost guarantee the reliability. One way to make this work is withunit testing where the programmer writes tests that simulates different caseswhere problems can occur.

4.1.4 Routing

The routing mechanism in the system would need to be coded into the system.This could lead to a situation where the logic of the routing mechanism couldbe hard to overview.

4.1.5 Process overview and management

There is no underlying infrastructure to get status information from. Mech-anisms for monitoring the status of the system and manage error will haveto be developed at the parts of the system that needs to report errors andstatus updates. This will require the programmer to imbed code in manydifferent parts of the system. However the reporting and overview can becustomized the way the client wants it. This could be an important feature.

4.2 BizTalk Server Solution

Microsoft offers a solution to integration problems through their productBizTalk Server 2006. [12] BizTalk is a set of tools forming an integrationplatform that enables integration of business processes. The messaging pro-cess in BizTalk is carried out using several components, also referred to asartifacts, and is illustrated in Figure 4. First a message is received witha component called Recieve Adapter. This receive adapter knows how tocommunicate with for example a Web Service, or a specific line- of-businessapplication (LOB), such as SAP. The message is then passed on to a Recieve

15

Figure 4: Overview of BizTalk messaging.

Pipeline, that can change it in different ways. For example, the message istransformed from its external format to an XML message, which is supposedto be used within BizTalk. The message is then stored in an SQL Serverdatabase called MessageBox. The BizTalk Orchestrations, which is the busi-ness layer of the engine, picks up the message from the MessageBox andprocesses it before it is passed on to the Send Pipeline which transforms themessage to the format required by its destination and sends it via a SendAdapter. The whole concept of communicating with other applications relieson the BizTalk send and receive ports. Ports can contain adapters, pipelinesand data mappings. A description of these components is presented below.

4.2.1 Connectivity through Adapters

Adapters are implementations of communication mechanisms, such as proto-cols [13]. One can choose to use the built-in adapters in BizTalk or create acustomized adapter. The adapters provided by BizTalk stretches from BaseEDI to FILE and FTP to HTTP, POP3, SMTP and SAP.

4.2.2 XML-handling and transformation

Pipelines BizTalk communicates with applications by sending messages ofdifferent kinds such as purchase orders, invoices and so on. Doing so, gener-ally these messages need to be processed in some way in order for BizTalk tohandle them correctly. For example the internal language inside BizTalk isXML, and since not all applications outside understand XML, Bizalk needsto translate the messages from any format into XML format. This is thenaccomplished with pipelines. The processing of messages is done with several

16

Figure 5: The Recieve pipeline.

components, each handling a particular part of the processing. The RecievePipeline for example consists of the following components; Decode, Disas-semble, Validate and Resolve Party, Figure 5. BizTalk provides some defaultpipelines, including a send/recieve pair that can be used to handle messagesthat are already in the form of XML. There is also a graphical tool calledPipeline Designer that is used to develop custom pipelines. With this toolthe developer can drag and drop components to whatever behavior desiredby the pipeline.

Data mappings Pipelines do the transformation of external messages toan XML format; however, the developer is responsible for specifying this for-mat. This is done with XML Schema Definition Language (XSD), a way todescribe what data an XML document should contain. The elements of theschema can be defined graphically using BizTalk Editor as well as importedfrom files or Web Services. Often information in incoming messages needsto be passed on to outgoing messages and therefore, a mapping of the mes-sages is required. This can be done as soon as the messages have an XMLrepresentation. A map in BizTalk is a graphical relation between two XMLschemas, created in BizTalk Mapper, defining the connections between thesource and destination schema. The World Wide Web Consortium (W3C)has defined the Extensible Stylesheet Language Transformation (XSLT) asa way to describe transformations between different XML schemes. BizTalkmaps are therefore implemented as XSLT transformations. Transformationsare made by drawing a line between elements in the source and destinationschema or, in the more complex case using a functoid on the link. A functoidis a component performing a certain programming-like task, like concatenat-ing strings or looping through a table. A simple map is illustrated in Figure6

17

Figure 6: A BizTalk map using functoids.

4.2.3 Reliability

BizTalk is designed to never lose a message. If an error occurs in one partof the system the message will be stored in the message box and an errormessage will be created. The administrator can track down the reason of thefailure and the message can be resent when the BizTalk application worksproperly again.

4.2.4 ”Routing” by Orchestrations

Creating business processes generally requires collaboration between devel-opers and business people. BizTalk supports this collaboration providing thedeveloper tool inside Visual Studio, but also an add-in of this tool to Visio,Microsoft Office diagramming software. An orchestration made in VisualStudio can be imported into the Visio- based tool and vice versa. This wasboth developers and business people can communicate and collaborate in thedevelopment of an automated business process. In Visual Studio however,an orchestration is made via BizTalk Orchestration Designer by putting to-gether different shapes that together form the business process. These shapescan be seen as business actions, ways to transform and transfer the messagesentering the orchestration, Figure 7. In this way, advanced business imposedrouting can be made. On the other hand messages can be sent straight fromone port to another without be handled by an orchestration. This will in-crease performance but obviously take out all flexibility; hence no routing isbeing made.

18

Figure 7: An orchestration handling a purchase order.

4.2.5 Business Process Management

Apart from seeing integration in BizTalk only as developing a message bro-ker, one can refer to it in a larger context as Business Process Management(BPM). In BizTalk BPM in turn contains two important technologies: Busi-ness Rule Engine (BRE) and Business Activity Monitoring (BAM). The BREis used when applications require complex set of rules to execute, too com-plex for the orchestration designer to handle. The BRE is then connectedvia the orchestration to take care of this process. The BAM services allowreal-time data to be monitored not only by technicians, but also by normalpeople, users of the system. The information can be viewed through toolssuch as for example Microsoft Excel and Office Performance Point Server.

19

5 System description

5.1 Overview

Figure 8: Overview of the TPP solution.

The demo application consists of a set of BizTalk applications forming theactual platform and a mobile and a stationary system representing the clientand server side, Figure 8. The XML format used is the format developed bythe MSI Group.

Orders are generated in the stationary system and stored in an ordermanagement database. The TPP integrator listens to the order manage-ment database and picks up new messages. It transforms the message intothe internal MSI format and forwards it to the routing engine. In the rout-ing engine the message gets directed to the connector where the message istransformed, this time to the external a format that corresponds with thetelematics provider database. The message gets inserted into the database.

The PDA loads its content from the database. When the PDA user makeschanges, a message gets generated and goes through the same procedure onlyreversed. This will be called the reversed flow from now on.

This chapter will try to give an understanding of the architecture of thisdemonstration implementation of the TPP. Figure 9 gives an overview of thedifferent components and the message flow in the system. More technicaldetails can be found in the next chapter.

20

Figure 9: Architectual details. The thin arrows show the message flow andthe thick arrows indicate references between different BizTalk applications.

5.2 Stationary system

The stationary system is represented by a web site with a database asdata provider. This database will be referred to as the order managementdatabase. The web site is only communicating with the database and is de-signed to be sealed system, i.e. no API:s or similar integration possibilitiesexists.

When new orders arrive to the order management system they don’t havetrucks assigned to them. Hence the user needs to choose an order and assigna truck to it. When a truck is assigned to an order it causes a status changeof that order in the database. This can be viewed in Figure 10.

Figure 10: Assigning a truck to an order.

21

5.3 Integrator

The integrator’s receive adapter listens to the order management database fororders with status ”Pending assignment”, that is, orders waiting to be con-firmed by the assigned driver. When a order has been read by the databaseand picked up by the receive adapter a flag called ”Sent” in the database isset, meaning the order has been sent and will not be sent again, even thoughit still has ”Pending assignment” as status. The messages are then mappedinto the MSI format. This is done with a BizTalk map.

In the reversed flow the PDA sends order status updates, every timethe transport job has proceeded, i.e. goods are picked up. These updatemessages are then mapped from MSI back to database format and insertedin a ”status change” table. The tasks of the integrator are illustrated inFigure 11.

Figure 11: The integrator and its tasks.

5.4 TPP core engine

The core engine is meant to handle the routing of messages to different con-nectors depending on the receiver’s system. Since there is only one mobilesystem in this demo, the only thing the orchestrations do is to transfer mes-sages between the integrator and the connector.

What is worth mentioning though, when looking at Figure 9 is that in-tegrators, connectors and core engine use the MSI Schema library to createMSI messages. By doing so, it is ensured that a MSI message in one partof TPP will be the same in any other part. It eases the upgrade of MSI tonewer versions in the future. Figure 12 illustrates the core engine messageflow.

22

Figure 12: Rouing engine and its message flow.

5.5 Connector

The connector has somewhat the same function as the integrator but handlesonly mobile systems. It transforms the MSI message to a format that canbe inserted into the telematics provider database, and performs the insert.In the reversed flow the receive adapter checks for status updates in thetelematics provider database. It picks up the any new status and transformsit into a MSI message and sends it to the core engine. This is shown in Figure13.

Figure 13: The connector and its tasks.

5.6 Mobile system

The PDA application shows all orders assigned to the driver of the vehicle.Order data, such as pick-up and drop-off location and time, can be accessed

23

through the PDA application. When the driver performs an activity thatchanges the status of the order he or she reports that in the application. Alldata is stored in the telematics provider database. It fetches informationabout orders on regular basis and inserts status updates into the database,depicted in Figure 14.

Figure 14: The PDA application.

24

6 User case description

6.1 Sending a new order

6.1.1 ASP.NET web page and the Order management database

Figure 15: Overview of all orders

The stationary system is an ASP.NET web application, shown in Figure15. All communication with the database is carried out using stored proce-dures. Stored procedures are subroutines that applications can use to accessrelational databases without making the direct queries.

All the information connected to an order is collected from the ordermanagement database and presented on the web site using a stored procedurecalled SelectOrderById. This stored procedure is shown in Figure 16.

When an order is first added to the order database (e.g. ERP), it receivesthe flag ”‘sent” which is then set to false. This indicates that this orderhasn’t been sent through the TPP integrator, which assumes that the orderdatabase can be changed to work with TPP. Another solution to this problemis presented in the case of the Telematics provider database.

When a user assigns an order to a truck the status of the order changes,the new status is also logged to a table with status changes. ”Sent” is stillset to false at this time. The order management database is a MicrosoftSQL Server. Since the order management system is fictive, the structure ofthe Order management database is based on an assumption of the need ofinformation for the functionality on the web page. Figure 17 gives a view ofthe relations in the database.

25

Figure 16: The stored procedure for selecting an order.

Figure 17: Relations in the order management database.

26

Figure 18: One of the mapping views from the mapping of order managementdatabase XML to MSI-XML.

6.1.2 Transport planner integrator

Because SQL Server is used for storing information in the Order Managementsystem, the BizTalk SQL adapters are used. The integrator consists of a Sendand Receive adapter, and an XML Transmit and XML Receive pipeline, oneadapter and pipeline for every direction of the message flow.

When a order has been read from the database and picked up by thereceive adapter the ”sent” flag is set to true, meaning the order has beensent and will not be read again, even though it still has Pending assignmentas status.

The database query for getting new orders returns it result as a XMLdocument, representing the database format used by the stationary system.The mapping between the database XML-format and MSI is done by BizTalkmapping, see Figure 18. This is a tool where the developer graphically drawsthe relationship between data tags in the different XML-documents.

6.1.3 Core engine orchestration

After the transformation to MSI the order goes through the core engineorchestration where nothing happens with the message. In a more complexcase with more systems involved, it might have been necessary to implement

27

routing logics here.

6.1.4 Telematics provider Connector

Like the integrator the connector is implemented like a two-way BizTalk SQLAdapter and a two-way pipeline, that is an XML Receive and XML Transmitpipeline.

When a new order has been sent through TPP the XML Transmit pipelinetransforms it into a XML representation the input to a stored procedure withthe name InsertNewOrder. It creates the new order, adds the orders rows(the goods) and adds a new row in a table called ”LastKnownStatus”.

The ”LastKnownStatus” table keeps track of the status of the order, moreon this in the next section.

6.1.5 Telematics provider database and PDA application

The telematics provider database belongs to the mobile system and is con-tinuously filled with orders throughout a demo process, hence there are noorders in this database from the beginning.

The PDA application is implemented in C# for Windows CE 5.0. ThePDA communicates directly with the telematics provider database, whereforenothing is stored locally in the PDA. The PDA application checks for neworders to collect when the user clicks the ”Unassigned” button.

6.2 Sending status updates

6.2.1 Telematics provider database and PDA application

When the driver updates the status in the application the order changes inthe database. Note however that the status doesn’t change in the ”Last-KnownStatus” table. When a driver clicks ”Delivered” on the application,he or she can sign the order and the signature is stored in byte code in thedatabase.

6.2.2 Telematics Provider Connector

The connector calls a stored procedure in the Telematics Provider Databasethat checks if there are any orders where the status in the order table differsfrom the one in ”LastKnownStatus” table. This would indicate that thestatus have changed since the last check. The stored procedure returns thestatus update and updates ”LastKnownStatus” table with the new update,hence the order table and the ”LastKnownStatus” table will match again.

28

When it finds a status update it forwards it as a new message type to XMLReceive pipeline where it will be transformed into MSI-XML and sent furtherthrough TPP.

6.2.3 Core engine orchestration

In this case there is one orchestration for the reversed flow that doesn’t domore than transfer the status update to the integrator.

6.2.4 Transport planner integrator

The status update gets transformed to an XML-document that correspondsto the input of the InsertNewStatus stored procedure. A special case occurswhen a confirmation of order delivery is being sent. The signature of thereceiving customer has to be transmitted to the web application database.In order to transmit an image based on byte code it has to be converted toBASE64, which is a way to represent byte information in a text file (suchas an XML file). In the order management database the BASE64 encodedimage is converted back to byte code and stored in the order table.

6.2.5 ASP.NET web page and the Order management database

In the reversed flow, new status updates are received from the telematicssystem. These are inserted into the change of status table and the order isupdated with the new status.

When the customer confirms the delivery by signing the order an text-coded image gets transmitted coded as BASE64. It needs to be decodedin order to be inserted into the Order management database. This is donewithin the database with a function which analyses the BASE64-text andsubstitutes the characters to corresponding byte code.

29

7 Discussion

7.1 The relevance of TPP

The interviews held with representatives from the transport and logistics in-dustry indicate that integrating different telematics systems is indeed some-thing that many companies strive to achieve. The technical challenges tomake this happen are not considered difficult in small parts but at largecomplex and time consuming. This often leads to less integrations actuallybeing performed and information not getting interweaved. The cost of inte-gration stops the introduction of new cost-saving telematics systems. Thereis an urge for means of easing the integration within the field of telematics.TPP could definitely facilitate the merging of data from all different telem-atics and information systems used in organizations. It might not solve theoverall problem of seamless communication between different OEMs, integra-tions would obviously still have to be performed. The integrations performedwould however be more cost-efficient than without an integration platformat all.

7.2 Choosing a XML-format for telematics

The goal of having a standard format for TPP is to be able to representas much transport-related information as possible. When a new telematicsservice is introduced it should be likely that the information related to thisservice already have support in the format. Otherwise the format would haveto be expanded to handle the new information. Every time a rewrite of theformat is needed, all components of the system that relies on the formatwould have to be adjusted to work with the new format. Avoiding that sortof rewriting is one of the purposes with TPP, hence a format that is expectedto need expansion is not acceptable.

An in-house format covering completely all message data in a telematicssystem would take too long time to develop and is beyond the scope of thisproject. Developing a format or extending an existing format would meancollecting a tremendous amount of data, since the whole transport industrywould have to be investigated in order to find what information is suitable toa system. Developing a specific format to solve only the problems faced todaywould not achieve the goal of TPP being an all-round telematics solution.Finding an already existing format was consequently the only alternative.During the research of existing formats it became clear that most standardinitiatives focus on solving problems involving the business transactions be-tween a company and its customer. Less priority was given to interaction

30

between transport service provider and executor of the transport. Severalexisting standards have basic support for telematics. However, due to theirsole focus on another problem it they don’t seem appropriate for telematicsapplications.

The only format that had telematics as its main scope and purpose wasMSI. This data format focuses only on the communication between mobileand stationary systems from a transport and logistics point of view. If MSI-group’s long-term vision with MSI would be reality today the integrationpart of TPP would not be requested by customers. The MSI vision wouldsolve the problems with integrating different systems. However, as that isnot yet reality and will probably not be for another few years, there is still aneed for TPP. Additionally as TPP uses the MSI format internally it is fullyprepared to be a broker between non-MSI systems and MSI-enabled systems.Apart from being a broker in environments with many dynamic systems thatcould be one of the more important applications of TPP.

7.3 Technical platform for TPP

While exploring alternatives for the technical platform it gradually becameclear that BizTalk, being an integration platform, had all the capabilitiesneeded for TPP. While a demo of a small information flow in C# also was de-veloped it was clear that the fail safety mechanisms in BizTalk vastly exceedsanything that could be developed within this thesis. Being a more robustproduct, BizTalk requires more from the hardware and handles much fewermessages per second. However, it supports load balancing and as hardwareprices keeps dropping it shouldn’t be a problem handling as many messagesas needed. In the trade-off between performance and hardware prices inthe sense of doing the right thing or doing it fast, it is true for the servermarket today that hardware prices is less than the price of developing evenmore complex code in order to improve performance. By using a third-partyproduct as a part of the solution some of the profit from selling the solutionwould benefit this third part instead of benefiting Cybercom. On the otherhand the development cost is greatly reduced and so is the risk of developinga product that will not sell well enough on the market. This is a trade-offthat all companies have to face and in this case the complexity of developingan own solution, however possible, might cost more to develop and maintainthan buying. As no major design or architecture changes had to be done inorder to use BizTalk it was rather easy to choose that for TPP.

31

7.4 To make TPP production ready

The system suggested in this thesis is only to be considered a proof of concept.It is also limited to handle a small portion of the capabilities of the MSIformat. When a real production environment is to be integrated a deeperanalysis has to be done and the need has to be estimated. TPP then has tobe extended to work with the new set of requirements. The customer mightuse a system with built-in ”adapters” to which BizTalk can’t communicate.In this case an adapter must either be bought if it exists, developed by theTPP team or the system must be extended to communicate with a standardprotocol that BizTalk supports. Depending on how many ingoing systems thesolution has, the routing mechanism has to be adjusted to route messagesto the right recipients. The business logic of the customer company hasto be implemented in the orchestration as well. With every project thatutilizes TPP the functionality will grow and following projects will benefitfrom both actual BizTalk projects as well as knowledge acquired in previousimplementations. In the long term TPP could be a bundle of almost readycomponents that can be put together and customized to fit the next projectat hand. After a while the MSI format will be more or less fully covered inTPP and it can serve as a proxy between an MSI network of MSI-enabledhosts and a environment with non-MSI hosts.

7.5 Extending TPP with in-house tools

A parallel project to this thesis was to develop a suite of tools to process andvisualize information about vehicles and transport orders. The natural wishand concern is whether it would be possible to integrate the two projectsand gain any synergy. The main idea was that the information that flowedthrough the integration platform would be stored in the middle and be acces-sible for these tools. However, TPP at this stage only consists of a integrationplatform and doesn’t store any data internally. If the tools suite should beused with TPP it has to be integrated in the same way as any other fleetmanagement or stationary system would. That being said, it would of coursebe easier because the development teams share both locations and possiblymembers. The in-house tools could also be built in a way that it easier thanother systems to integrate and takes advantage of TPP’s strengths.

32

8 Conclusion

The TPP demo was developed and built throughout this project using theMSI Group XML data format for internal communication. This means thatall external systems, mobile or stationary, proprietary data formats are trans-lated into the MSI format and then sent to the destination system where theyare translated into the local system’s own data format. By using the MSIdata format as foundation TPP becomes reliable and extendable within thefield of telematics. Even though the demo described in this thesis is not readyfor production the architecture could be used as a blue print for building aTPP implementation to solve a real world problem. The Microsoft BizTalkintegration platform offers stable basis on which TPP gets interaction witheverything from ERPs to database systems and fileservers. It also simplifiesthe handling of XML messages sent through TPP and makes the solutionmore fail-safe compared to be using an in-house developed integration plat-form.

33

References

[1] Linthicum, D, Enterprise application integration, Addison-Wesley, Mas-sachusetts 1999

[2] Distributed Computing - Principles ans Applications, M. L. Liu, PearsonAddison-Wesley, California Polytechnic State University, San LuisObispo, 2004.

[3] Towards Seamless System Integration in Road Haulage Firms, Gohar-pour and Seifzadeh, Goteborgs Universitet 2005

[4] http://freightwise.info/cms/ 2007-09-26

[5] http://www.oasis-open.org/committees/tc home.php?wg abbrev=ubl2007-09-26

[6] http://www.norstella.no/getfile.php/175829.177/transportXML3.2EnglishApr1805.pdf2007-09-26

[7] http://www.shortseaxml.org/ 2007-09-26

[8] Interview with Rikard Lindgren, univeristy lecturer, Viktoriainstitutet,2007-09-27

[9] http://www.msigroup.se/index.asp?page=content/organisation 2007-09-27

[10] Test results of MSI 0.18, Magnus Andersson, Viktoriainstitutet 2007-02-20

[11] Interview with Magnus Andersson (phone), PhD at Viktoriainstitutet2007-11-05

34

[12] Introducing Microsoft BizTalk Server 2006 R2, David Chappell, Chap-pell and Associates, August 2007

[13] Understanding Microsoft BizTalk Server 2006 R2, David Chappell,Chappell and Associates, August 2005

35

Glossary

.NET - The Microsoft .NET Framework is a software component that isa part of Microsoft Windows operating systems. It provides a large bodyof pre-coded solutions to common program requirements, and manages theexecution of programs written specifically for the framework. The .NETFramework is a key Microsoft offering, and is intended to be used by mostnew applications created for the Windows platform.API - An application programming interface (API) is a source code interfacethat an operating system or library provides to support requests for servicesto be made of it by computer programs.BizTalk Server - is a business process management (BPM) server. Throughthe use of ”adapters” which are tailored to communicate with different soft-ware systems used in a large enterprise, it enables companies to automateand integrate business processes.Broker - Negotiator between external independent systems, often with dif-ferent communication protocols.C# - is an object-oriented programming language developed by Microsoft aspart of the .NET. It has a procedural, object-oriented syntax based on C++and includes aspects of several other programming languages (most notablyDelphi and Java) with a particular emphasis on simplification.ERP - Enterprise Resource Planning (ERP) systems integrate (or attempt tointegrate) all data and processes of an organization into a unified system. Atypical ERP system will use multiple components of computer software andhardware to achieve the integration. A key ingredient of most ERP systemsis the use of a unified database to store data for the various system modules.Middleware - see Broker.Mobile Office - the concept of managing office-related task mobile or in avehicle.OEM - Original equipment manufacturer, is a term that refers to containment-based re-branding, namely where one company uses a component of anothercompany within its product, or sells the product of another company underits own brand. OEM refers to the company that originally manufactured theproduct.PDA - Personal digital assistants are handheld computers, but have becomemuch more versatile over the years. PDAs are also known as small computersor palmtop computers.Protocol - In computing, a protocol is a convention or standard that controlsor enables the connection, communication, and data transfer between twocomputing endpoints.Proxy - see Broker.

36

SAP - The world’s largest supplier of ERP-systemsSQL Server - Microsoft SQL Server is a relational database managementsystem (RDBMS) produced by Microsoft. Its primary query language isTransact-SQL, an implementation of the ANSI/ISO standard StructuredQuery Language (SQL) used by both Microsoft and Sybase.Stored Procedure - is a subroutine available to applications accessing a rela-tional database system. Stored procedures (sometimes called a sproc or SP)are actually stored in the database.TCP/IP - (also refered to as the ”Internet protocol suite”) is the set ofcommunication protocols that implement the protocol stack on which theInternet and most commercial networks run.TMS - Transport Management System, generally the stationary system.TPP - Telematics Proxy Platform, a broker platform between telematics sys-tems developed by Cybercom. In this thesis, TPP refers to the integrationpart of the platform.TSP - Telematics Service Provider, generally the stationary system.Updategram - An updategram is a piece of XML data that contains informa-tion about how to modify data in a database, expressed as an insert, update,or delete operation of existing records.Visio - Microsoft Visio is diagramming software for Microsoft Windows. Ituses vector graphics to create diagrams.Visual Studio - Microsoft Visual Studio is the flagship Integrated Develop-ment Environment (IDE) from Microsoft. It can be used to develop consoleand GUI applications along with Windows Forms applications, web sites,web applications, and web services in both native code as well as managedcode for all platforms supported by Microsoft Windows, Windows Mobile,.NET Framework, .NET Compact Framework.W3C - The World Wide Web Consortium (W3C) is the main internationalstandards organization for the World Wide Web (abbreviated WWW or W3).Web Service - A Web service (also Web Service) is defined by the W3C as”a software system designed to support interoperable Machine to Machineinteraction over a network.” Web services are frequently just Web APIs thatcan be accessed over a network, such as the Internet, and executed on a re-mote system hosting the requested services.Windows CE 5.0 - is a variation of Microsoft’s Windows operating systemfor minimalistic computers and embedded systems.XML - The Extensible Markup Language (XML) is a general-purpose markuplanguage.XSD - XML Schema Definition is one of several XML schema languages. Itwas the first separate schema language for XML to achieve Recommendationstatus by the W3C.

37

XSLT - Extensible Stylesheet Language Transformations (XSLT) is an XML-based language used for the transformation of XML documents into otherXML or ”human-readable” documents.

38