Application of web service technologies on a b2b communication platform by means of a pattern and UML based software development process

Abstrakt

Die spanische Hotel-, Restaurant- und Cateringindustrie zählt ungefähr 230.000 Einrichtungen. Diese sorgen für einen jährlichen Umsatz von etwa 15.6 Milliarden Euros. Alle diese Einrichtungen verkaufen Nahrungsmittel an private Abnehmer. Gleichzeitig versorgen Produzenten und Händler das Gaststättengewerbe mit Speisen und Getränken. Für gewöhnlich handeln die einzelnen Teilnehmer des Nahrungsmitteldistributionsnetzwerks mit ihren Produkten auf der Grundlage manuell aufgegebener Bestellungen. Dies ist ein Prozess, der durch den Einsatz von Computerund Internettechnologie effektiviert werden kann.

Ein jüngst auch von der spanischen Regierung unterstütztes und vor etwa drei Jahren gegründetes Projekt mit dem Namen „Catanet“ soll diese Lücke schließen.

In der aktuellen Version der Catanet-Plattform müssen die Kunden Webseiten-basierte Schnittstellen verwenden, um auf die Catanet Dienste zuzugreifen. Über 100 verschiedene Kunden nutzen bereits diese Catanet-Version, um Bestellungen aufzugeben, Produktkataloge zu studieren, Versandbestätigungen zu verschicken usw. Diese Lösung jedoch weist erhebliche Mängel auf. So stellt die menschliche Interaktion immer noch einen unabdingbaren Bestandteil der über die Plattform abgewickelten Geschäftsprozesse dar. Zudem verläuft die Kunden-Plattform-Interaktion weitgehend asynchron. Die Vorteile des Computereinsatzes werden somit nicht voll ausgeschöpft.

Ziel dieser Diplomarbeit war es, eine zusätzliche Plattform zu planen und zu entwickeln, die die direkte Integration der Kunden-ERPs in die Catanet-Plattform erlaubt. Die praktische Bedeutung dieser Arbeit wird dadurch verdeutlicht, dass zahlreiche, sehr bedeutende Marktteilnehmer wie Lauren Films, Pepsi, Unilever und Nestle bereits Verträge mit Catanet geschlossen haben und nun darauf warten, in die neue Catanet-Version, die im Rahmen dieser Diplomarbeit entwickelt werden sollte, integriert zu werden.

Da die neue Catanet-Plattform auf der Grundlage von Web Services Technologie entwickelt werden sollte und Web Services momentan noch nicht ohne weiteres für den Einsatz in einem kommerziellen Kontext geeignet sind, mussten zusätzliche Technologien untersucht werden, um den Ansprüchen, die sich aus der kommerziellen Anwendung ergeben (so wie die Sicherheit und Zuverlässigkeit der versendeten SOAP Nachrichten), Rechnung zu tragen. Darüber hinaus mussten Erfordernisse, die die praktische Anwendung mit sich bringt, wie zum Beispiel mögliche FirewallProbleme, die Stabilität, Performanz und Implementierungs-/Integrationskosten, bei der Suche nach geeigneten Technologien berücksichtigt werden.

Die spätere Entscheidung, .NET-Framework-basierte Programme kundenseitig zu verwenden bei gleichzeitiger serverseitiger Verwendung von Java-Programmen, warf zudem die Schwierigkeit auf, das .NET-Java Integrationsproblem bei gleichzeitiger Berücksichtigung der Kompatibilität mit den übrigen Technologien lösen zu müssen. Auch hier mussten die oben genannten Aspekte der Praxistauglichkeit beachtet werden.

Die Tatsache, dass die Ergebnisse dieser Arbeit später von anspruchsvollen Kunden kommerziell verwendet werden sollten, erforderte insbesondere auch die Betonung der Qualität der entwickelten Software. Die Auswahl und Verfolgung eines geeigneten Softwareentwicklungsprozesses stellt ebenso ein Beispiel für die Anstrengung, dieses Ziel zu erreichen, dar wie die Ausarbeitung und Verwendung einer passenden Teststrategie.

Die Resultate dieser Arbeit bestehen in einer ersten Java-basierten Implementierung der neuen Plattform, bestehend aus über 12.000 Zeilen Quellcode, die in verschiedenen Modulen organisiert sind, und einer umfassenden Studie, wie die neue Catanet Plattform entsprechend den oben genannten Design-, Geschwindigkeits-, Qualitäts- und funktionalen Kriterien zu realisieren ist. Im Rahmen dessen wurden zahlreiche Reliabilitäts- und Sicherheitstechnologien untersucht, bewertet und im Plattformdesign berücksichtigt, obwohl sie aufgrund der Begrenzung der zur Verfügung stehenden Zeit nicht mehr vollständig implementiert werden konnten.

Nahezu die Hälfte des entwickelten Quellcodes besteht aus Tests, die entsprechend der ausgearbeiteten Teststrategie implementiert wurden. Außerdem wurde die Performanz des entwickelten Systems analysiert, und Performanz -Flaschenhälse wurden identifiziert.

There are about 230.000 establishments in the Spanish hotel, restaurant and catering industry accounting for an annual turnover of about 15.6 thousand million euros. All of them sell food to private consumers. Additionally suppliers and traders supply the catering trade with food and beverage products. Usually the different players in this food distribution network trade products by means of orders which are placed manually. This is a process which can be enhanced through the application of computer and Internet technology.

A project lately also supported by the Spanish government is supposed to fill this gap. This project is called “Catanet” and has been established three years ago.

In the current version of the Catanet platform clients have to employ a web page based interface in order to access the Catanet services. More than 100 different customers use this version of the Catanet to place orders, look up product catalogs, confirm the shipping of orders, etc. But this solution comes short on several aspects. Human participation for example still constitutes a crucial part of the transactions and the interaction with the Catanet platform is completely asynchronous. Therefore the benefits the use of computer assistance provides cannot be fully exploited.

Thus the purpose of this thesis was to design and implement an additional level of the Catanet platform which allows the integration of the customer’s ERPs into the Catanet platform. The practical relevance of this work becomes clear considering the fact that very important industry players like Lauren Films, Pepsi, Unilever and Nestle have signed already contracts with the Catanet waiting to be integrated by the new platform version which should be developed within this work.

Since the new Catanet platform is supposed to be realized using Web Service technology and Web Services are actually not yet ready for easily being utilized in a commercial context, a number of additional technologies had to be investigated in order to meet the requirements (such as security and exactly-once delivery of the SOAP messages) which make it eligible for Catanet business transactions. Moreover certain real world constraints had to be taken into account like for example the firewall compatibility of the analyzed technologies as well as their stability, implementation/integration costs and perfomance. The later decision to use .NET Framework based programs on the customer side while realizing the server side system in Java additionally raised the difficulty to manage the .NET-Java integration while regarding the compatibility of the integration technology with the security and reliability technologies. In addition the abovementioned real world constraints also had to be taken into account for the selection of a suitable .NET-Java integration mechanism.

The fact that the results of this work were supposed to be used in a commercial context by demanding clients required also in particular the consideration of the quality of the developed software. The selection and tracing of a suitable software development process as well as the elaboration and application of an eligible test strategy are two examples for the effort to reach this goal.

The result of this work is a first Java implementation of the new platform, comprising 12.000 lines of sourcecode which are organized in several modules as well as a comprehensive study of how to realize the new Catanet platform according to the abovementioned design, performance, quality and functional criteria. Thereby numerous reliability and security technologies have been investigated, evaluated and regarded by the platform design even though due to the time constraints of this work they couldn’t be fully implemented.

Almost half of the developed source code represents tests which are implemented according to the elaborated test strategy. Moreover the performance of the developed system has been analyzed and performance bottlenecks have been identified.

Acknowledgements

I would like to seize this opportunity to express my thanks to anybody who made it possible for me to write my diploma thesis in this great city making this part of my studies a very enriching experience.

First of all many thanks to Dr. Xavier Ginesta for giving me the chance of working in one of his projects and for being always very generous in granting me the freedom necessary to master the challenge of meeting also the sometimes diverging demands on my work placed by the German study regulations.

I want to express my special thanks also to Prof. Dr. Dr. hc. Radu Popescu-Zeletin and Stephan Steglich who kindly agreed to accept the supervision of my diploma thesis in Germany.

Last but not least many thanks also to my good friend Frank Bergmann among others for only making this project possible through his contacts and for never hesitating to offer his help in case of problems.

Table of Illustrations

Figure 1: Overall Catanet Platform

Figure 2: Just-In-Time Integration

Figure 3: Web Services Technology Stack

Figure 4: SOAP Message Structure

Figure 5: Basic RPC Messaging Architecture

Figure 6: UDDI Registry Access

Figure 7: Catanet API Approach

Figure 8: Catanet Proxy Approach

Figure 9: SOAP Message Loss

Figure 10: SOAP Message Duplication

Figure 11: WS Protocol Stack: Reliable Transport Protocol

Figure 12: Reliable Messaging Through HTTPR

Figure 13: WS Protocol Stack: Reliable SOAP

Figure 14: JMS Reliable Message Transfer

Figure 15: JMS Based Service Bus

Figure 16: SOAP over JMS Architecture

Figure 17: Adapter Based JMS -Architecture

Figure 18: Reliable ebMS Message Transfer

Figure 19: Reliable Messaging Using JAXM and ebXML

Figure 20: SSL Protocol Stack

Figure 21: SSL Handshake

Figure 22: SSL Session Key Generation

Figure 23: XML Signature: Signing Data

Figure 24: XML Encryption: Encrypting Data

Figure 25: JNBridgePro Architecture

Figure 26: Antidecomposition Axiom

Figure 27: Anticomposition Axiom

Figure 28: Big Bang Integration 1

Figure 29: Big Bang Integration 2

Figure 30: Bottom-Up Integration 1

Figure 31: Bottom-Up Integration 2

Figure 32: Bottom-Up Integration 3

Figure 33: Top-Down Integration 1

Figure 34: Top-Down Integration 2

Figure 35: Top-Down Integration 3

Figure 36: Development P rocess - Overview

Figure 37: Use Case Diagram

Figure 38: Development Process - Build Phase

Figure 39: Development Process - Development Cycle

Figure 40: Development Process - Analyze Phase

Figure 41: Conceptual Model of the First Development Cycle

Figure 42: Sequence Diagram 1 - Place Order

Figure 43: Sequence Diagram 2 - Approve Order

Figure 44: Sequence Diagram 3 - Deliver Order (Accept Pending Service)

Figure 45: Development Process - Design Phase

Figure 46: Collaboration Diagram Extract 1

Figure 47: Collaboration Diagram Extract 2

Figure 48: Collaboration Diagram Extract 3

Figure 49: Collaboration Diagram Extract 4

Figure 50: Collaboration Diagram Extract 5

Figure 51: Collaboration Diagram Extract 6

Figure 52: Class Diagram For the First Development Cycle

Figure 53: JBuilder Class Diagram 1

Figure 54: JBuilder Class Diagram 2

Figure 55: Package Structure of First Development Cycle

Figure 56: Service Package

Figure 57: Development Cycle 1 - Collaboration Diagram 1

Figure 58: Development Cycle 1 - Collaboration Diagram 2

Figure 59: Development Cycle 1 - Collaboration Diagram 3

Figure 60: Development Cycle 1 - Collaboration Diagram 4

Figure 61: Development Cycle 1 - Collaboration Diagram 5

Figure 62: Development Cycle 1 - Collaboration Diagram 6

Figure 63: Development Process - Construct Phase

Figure 64: Development Process - Test Phase

Figure 65: Performance Chart

Figure 66: Performance Chart

Figure 67: Performance Chart

Figure 68: Performance Chart

1 Introduction

1.1 Motivation and Definition of the Project

1.1.1 Outline of the Catanet Project

There are about 230.000 establishments in the Spanish hotel, restaurant and catering industry accounting for a turnover of about 15.6 thousand million euros. All of them sell food to private consumers. On the other hand suppliers and traders supply the catering trade with food and beverage products. Usually the different players in this food distribution network trade products by means of orders which are placed manually. This is a process which can be enhanced through the application of computer and Internet technology.

A project lately also supported by the Spanish government is supposed to fill this gap. This project is called “Catanet” and has been established three years ago.

Actually the Catanet platform is used by more than 100 customers, amongst them very important industry players like Lauren Films, Pepsi, Unilever and Nestle . Some of them will carry out a significant part of their overall food orders by the Catanet platform, which corresponds to a turnover volume of many million euros.

In the former version of the Catanet platform clients had to apply a web page based interface in order to use the Catanet services. As this approach prohibited the full exploitation of the benefits the use of computer assistance provides (e.g. human participation still constitutes an inevitable and crucial part of the transaction, the interaction is completely asynchronous) an additional level is being added to the Catanet platform eliminating these shortcomings.

During the time of this work the number of Catanet customers has grown explosively increasing also the diversity of the customer’s computer systems. Additionally new subprojects could be launched due to the acquisition of a government grant. These encompassed among others new value added services demanded by the customers like an instant messaging module and a module for the automatic update of the local product catalog.

The characteristics of the IT infrastructure of the new customers which will carry out transactions with a serious turnover via the Catanet platform and the necessity to integrate the new subprojects required an adaptation of the design of the platform prototype which had been developed by this time and which is described in this work.

Within this context the decision has been done to use .NET Framework based programs on the customer side instead of Java which had been used so far. The reasons for this were besides the easier integration with the IT infrastructure of the new customers the rising wish to provide a client module similar to a file sharing program which should also provide an attractive user interface for the manual interaction with the Catanet platform. Therefore the existing web based user interface should be utilized by integrating an Internet Explorer into the client module. For these applications .NET seemed to be more suitable that Java.

Besides the provision of a business to business platform the Catanet project aims to establish a product description code similar to the EAN13 barcode used in supermarkets in order to settle up products at the counter. This electronic barcode with the name “Registro Gastronómico” is dedicated to transport product information via the Internet and consists of generic building blocks (e.g. the product family hierarchy it belongs to, its vendors, its wrappers, etc.), while the different product aspects (represented by the corresponding building blocks) may only be modified by certain customers. The product descriptions are held in a central oracle database provided by the Catanet platform and are editable by the Catanet customers via a web interface according to their role.

1.1.2 Definition of the Main Tasks of this Work

The figure below depicts the latest version of the Catanet platform design from a conceptual point of view.

Abbildung in dieser Leseprobe nicht enthalten

This figure shows the overall architecture of the Catanet platform consisting of client and server side modules.

Figure 1: Overall Catanet Platform

According to this model the Catanet platform consists of the modules at the server side and the modules at the client side.

On the client side different integration modules assure that the client can be integrated into the Catanet platform. Some clients for example dispose of an ERP system like SAP that has to be integrated with the platform while other clients prefer a user interface to connect to the Catanet platform.

The main communication channel between the client and the server side is to be realized using the SOAP protocol. The purpose thereby is to realize a synchronous communication between the customer’s IT infrastructure with the Catanet platform server.

The communication has to be secured, i.e. the integrity and confidentiality of the transmitted data and the authenticity of the sender has to be assured. Additionally it has to be proved for every transaction that the sender is authorized to access the desired service.

Internally the transaction data is transferred as a string in XML format. Therefore a generic representation format that fits for any service request had to be specified as well as specific formats for the different transactions. Customers pass service requests as a string containing the request information. This information may be encoded in a customer specific format. Thus the requests received from the customers have to be parsed and the request data has to be extracted before converting it into the XML representation.

On the server side the different transactions are delegated to the implementing service modules after having extracted the transaction id from the service requests. The service modules may be located at different servers.

1.2 Identification of Central Questions

1.2.1 Selection and Application of Appropriate Security Mechanisms

Security technologies have to be found and applied in order to make the data transfer confidential, resistant to modifications during the transport and to ensure the authenticity of the transmitted data.

As there are many possible ways to reach this goal (e.g. through the application of SSL, XML Security) the different security technologies had to be evaluated concerning there suitability.

1.2.2 Platform Design by Following an Appropriate Software Development Process

The platform had to be designed carefully to ensure a good chance for reusability of the components in further releases. Moreover as the Catanet platform was still heavily under construction during the realization of this project it became apparent that the flexibility of the software due its thorough design was of great use whenever major changes of the overall architecture were decided.

In order to make the platform maintainable and expandable by future team members a high grade of comprehensibility of the software had to be given top priority. This was especially important as the project is carried out in a university context which is characterized by a high fluctuation of the developers. Thus a great number of UML diagrams had to be produced for being able to maintain and extend the system later.

1.2.3 Implementation Style

In addition to the detailed UML documentation of the platform extensive source code comments had to be added to enhance the comprehensibility of the software by later developers.

For the same reason the software has been implemented according to the [SUNJ02] Java coding guidelines. Moreover the variable, method and object names had to be chosen with the aim of making the source code maximal self explanatory and long methods (more than 20 lines of code) had to be avoided.

1.2.4 Transaction Reliability

Additionally to the security of the data transfer the transmission had to be investigated concerning its reliability and finally appropriate mechanisms had to be evaluated. This becomes clear imagining the case in which a customer places an order at the Catanet platform using an unreliable connection. It could happen now for example that the order is placed successfully at the Catanet platform but the corresponding return message gets lost on its way to the customer. The customer would now assume that the order hasn’t been processed properly and would start the retransmission of the same order placement request. The Catanet server would process the request again with the result that the order would be sent to the respective supplier twice thus shipping the requested products once more.

1.2.5 System Integration

Different mechanisms (e.g. CORBA vs. RMI vs. socket connections vs. JNI etc.) for the integration of the Catanet platform at the client side had to investigated and evaluated.

1.2.6 Real World Business Suitability: Speed and Stability

Since important customers will carry out serious parts of their transactions via the Catanet platform a reasonable speed of the software has been a must. Therefore profound performance measurements had to be done in order to find and eliminate performance bottlenecks.

As important as an appropriate speed of the software was a high grade of accuracy which has been supposed to be reached through the exhaustive employment of tests.

1.2.7 SOAP Communication Details

Concerning the realization of the SOAP based communication with the Catanet platform several details have had to be analyzed like which SOAP message transfer style to apply (RPC-style vs. message-style SOAP) and which SOAP implementation to use.

1.2.8 .NET-Java Integration

The decision to use .NET Framework based programs on the customer side raised a number of additional questions. This has been for example the question how to integrate the .NET based client side with the Java based server side.

Likewise the integrateability of the potential security and reliability mechanisms with the .NET Framework as well as with the Java based server side has had to be taken into consideration while analyzing the security and reliability issues.

1.3 Overview of this Work

Apart from the introduction this diploma thesis consists of three main chapters: the “Technology Background” chapter briefly lining out the fundamentals of the Web Services paradigm according to which the Catanet platform is being implemented, the “Concepts” chapter which represents the theoretical main part of this work and the “Realization” chapter which describes how the implementations of this work have been done.

Each of these chapters consists of an introduction, which sketches the contents of the chapter, the body and a final subchapter providing a summary and drawing conclusions.

In the second chapter of this thesis an introduction to the fundamentals of the Web Service philosophy is given as the Catanet platform is being implemented according to the Web Services paradigm. The second chapter comprises also the analysis of design and implementation questions related to the SOAP protocol as raised in 1.2.7.

The “Concepts” chapter analyzes and answers the security, reliability and .NETJava integration issues stated in 1.2.1, 1.2.4, 1.2.8. It also addresses the overall design decision whether to provide a client component or to provide only an interface description for the integration of the Catanet customers which is strongly related to the available system integration technologies as mentioned in 1.2.5. Also this point has been analyzed and evaluated.

The issues of which Development Process to use and how to test the system properly like brought up in 1.2.2. and 1.2.6 have been investigated and answered likewise in this chapter.

Due to the extent of the “Concepts” chapter every subchapter also encompasses here a leading introduction and trailing conclusion chapter just like the main chapters of this thesis.

The “Realization” chapter describes how Craig Larman’s development process has been followed step by step in order to implement the first release of the Catanet platform. It also deals with the performance measurements which have been considered necessary according to 1.2.6.

The “Conclusion” chapter gives a summary of this work (“Summary”), evaluates the future of Web Services for e-business (“Future Prospects”) and names the tasks which couldn’t be fulfilled because of the time constraints of this work (“Open Issues”).

Many UML diagrams have been evacuated to the Appendix due to their dimension. The same holds for the detailed measuring results of the performance measurements and details concerning the error handling. As more than 12.000 lines of source code have been written in the context of this thesis as part of the first Catanet platform release it would have gone beyond the scope of this work to put print-outs of them into the Appendix as well.

1.4 Objectives

An implemented platform which matches the abovementioned accuracy, performance, reliability and security needs. These will be clearly defined in the requirements analysis section of the main part of this work.

A second main objective of this work is the quality of the implementation, in particular the comprehensibility and expandability of the program and the reusability of its components.

2 Technological Background: Web Services

As the Catanet platform will be built according to the Web Services philosophy, this chapter shall give an introduction to the fundamental principles of Web Services.

The communication between the Catanet clients and server will be realized by means of SOAP and WSDL descriptions which constitute an important component of the Web Service technology stack.

2.1 Introduction

Here is a definition of the Web Service term According to the W3C Working Group on “Web Services Architecture Requirements” which can be found under [CFN02]:

“A Web Service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and that supports direct interactions with other software applications using XML-based messages via Internet-based protocols.”

The W3C definition says that all of the fundamental building blocks of Web Services, which are the definition, discovery, access of Web Services are strongly related to XML. Additionally also the bindings (to the underlying “Internet-based protocols” for example) can be defined with XML.

Another important aspect is mentioned in this definition, which is the fact that Web Services are not designed for direct human interaction. Rather, Web Services operate at the code level; they are called by and exchange data with other software. However Web Services will be incorporated into software designed for human interaction as well.

Finally Web Services can be referenced by other software applications by means of an URI.

There exist many other definitions of what Web Services are. Another interesting one by “The Stencil Group” can be found under [Ste01]. For a short introduction the definition cited above shall be sufficient.

2.2 Web Services Architecture: Just-In-Time Integration

According to [STK02] the fundamental principle of Web Services is the Just-In-Time integration.

The idea is that in the Web Services architecture, a service provider publishes a description of the services he offers via a service registry. The service consumers search the service registry to find a service that meets their needs. The service consumer finally binds to the selected Web Service.

Binding refers to a service consumer actually using the service offered by a service provider. The gag of Just-in-Time integration is that this can happen at any time, especially at runtime. That is, a client might not know which procedures it will be calling until it is running, searches the registry, and identifies a suitable candidate. This is analogous to late binding in object-oriented programming.

Abbildung in dieser Leseprobe nicht enthalten

This figure illustrates the Just-In-Time integration concept which is characteristic for the Web Service philosophy.

Figure 2: Just-In-Time Integration

The figure above illustrates how the Web Service Just-In-Time integration works: a company P creates a number of Web Services and the WSDL file which describes the corresponding Web Services. The company publishes the WSDL based Web Service description to an UDDI registry.

Company R searches the UDDI registry for a Web Service that meets its requirements and selects the Web Service offered by company P. An UDDI registry can be searched according to different search criteria.

Company R now uses the WSDL description to create a client component capable of making requests to the selected Web Service. Company R runs the application. At runtime, the client component binds to the Web Service and executes SOAP requests, passing data as XML over HTTP.

2.3 Web Services Core Technologies

In this chapter I will give a short introduction to the technologies that form the core of the Web Service architecture. In order to understand what is the focus of these technologies and how they are related to the Web Service architecture it makes sense to consider the constituting technologies as a Web Service protocol stack.

Taking this point of view the Web Services architecture is implemented through the layering of five types of technologies, organized into layers that build upon one another.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3: Web Services Technology Stack

This stack looks very similar to the TCP/IP network model used to describe the architecture of Internet-based applications.

The additional packaging, description, and discovery layers in the Web Services stack are the layers essential to providing the Just-In-Time Integration capability.

Because each part of the Web Services stack addresses a separate business problem, only those pieces that make the most sense at any given time have to be implemented. In our case for example the usage of discovery facilities doesn’t make sense as we incorporate the Web Service provider ourselves and know already which Web Services will be used for which Catanet transaction.

The Web Service description layer plays only a role in that WSDL descriptions are used to generate the client side SOAP clients which connect to the Web Services located at the Catanet server.

Therefore it will be given only a very concise introduction to UDDI and WSDL in this chapter while SOAP will be discussed more in detail.

2.3.1 Packaging Layer: SOAP

SOAP‘s place in the Web Services technology stack is a standardized packaging protocol for messages shared by applications. The specification defines nothing more than a simple XML-based envelope for the information being transferred, and a set of rules for translating application and platform-specific data types into XML representations.

SOAP is XML. That is, SOAP is an application of the XML specification. It relies heavily on XML standards like XML Schema and XML Namespaces for its definition and function.

The fundamental idea is that two applications, regardless of operating system, programming language, or any other technical implementation detail, may openly share information using nothing more than a simple message encoded in a way that both applications understand. SOAP provides a standard way to structure XML messages.

2.3.1.1 SOAP Messages

A SOAP message consists of an envelope containing an optional header and a mandatory body.

Abbildung in dieser Leseprobe nicht enthalten

Figure 4: SOAP Message Structure

Every Envelope may contain a Header element and must contain exactly one Body element. The Body may contain as many child nodes as are required.

The core components of the SOAP Envelope specification are:

- <s:Envelope>: the <s:Envelope> is the topmost container that comprises the SOAP message.
- <s:Header>: the optional <s:Header> contains additional blocks of information about how the body payload is to be processed. Each element contained by the Header is called a header block. The purpose of a header block is to send contextual information relevant to the processing of a SOAP message.
- <s:Body>: the mandatory <s:Body> element contains the actual message to be processed. Anything that can be expressed in XML syntax can go in the body of the message. References may be used to reference external information sources that are not part of the SOAP envelope (binary data for example).

2.3.1.2 The SOAP Data Types

The data types supported by the SOAP encoding style are the data types defined by the “XML Schema data types” specification. All data types used within a SOAP-encoded block of XML must either be taken directly from the XML Schema specification or derived from types therein.

Data types supported by SOAP include also structs, arrays, character-array and strings.

2.3.1.3 RPC-style vs. Document-style SOAP

SOAP has two related applications: RPC and EDI.

RPC-style SOAP

Remote Procedure Calls (RPC) are the basis of distributed computing, the way for one program to make a procedure call on another, passing arguments and receiving return values.

If SOAP is used for RPC (known as “RPC-style SOAP”) then the XML payload of the SOAP message will be a representation of parameter or return values.

Typically RPC-style SOAP messages come in pairs, as shown in the Figure below: the request (the client sends function call information to the server) and the response (the server sends return values back to the client).

Abbildung in dieser Leseprobe nicht enthalten

Figure 5: Basic RPC

Messaging Architecture

The example below shows a fictive RPC-style SOAP message that represents a request for getting the status of an order that has been placed before at the Catanet server:

Abbildung in dieser Leseprobe nicht enthalten

The header remains the same for EDI and RPC style SOAP messages. What changes is only the body tag which contains in this case the name of the Web Service (catanetOrderStatusService), the name of the service method (getOrderStatus) and the method parameter (orderId), which is in this case an integer value.

[Sav02] discussed the advantages and disadvantages of RPC and EDI-style SOAP.

Advantages of RPC-style SOAP are that it is easy to implement and that successfully transferred SOAP messages can be recognized by the receipt of a corresponding return value.

Disadvantages are that web services that are called by RPC style SOAP messages become tightly coupled to the SOAP client. This means that whenever there are any changes made to the signature of a web service method this would break all of the clients using this web service. The fact that Web Service method details like their signature are exposed to service requestors with RPC-style SOAP is also denoted as tight coupling (of the Web Service client to the Web Service server).

In addition to this RPC style SOAP messages are less resilient to network problems like congestion. Using RPC style SOAP this would result in the respective SOAP client to freeze until the expected return message finally arrives or the transmission timer hits. The fact that the SOAP client blocks until the RPC transaction has finished is also called synchronism of the Web Service client and server.

Nevertheless RPC-based Web Services, which can be accessed by the JAX-RPC APIs (Java API for XML Remote Procedure Calls), are much more popular due to the simplicity of their use than EDI-based Web Services.

Document-style SOAP

Electronic Document Interchange (EDI) is basis of automated business transactions, defining a standard format and interpretation of financial and commercial documents and messages.

If SOAP is used for EDI then the transferred XML payload will be an XML document representing for example a purchase order.

The body of a document-style SOAP message is shown below:

Abbildung in dieser Leseprobe nicht enthalten

The advantages of Web Services accessed by EDI-style SOAP messages are first of all that they are loosely coupled to the SOAP client. There are no method signatures exposed to the SOAP client. This results in much more flexibility: server changes don’t lead to the necessity of client changes. EDI-style SOAP clients exchange SOAP messages asynchronously with EDI-style SOAP servers. This avoids the blocking of the SOAP clients while waiting for the SOAP request and response being delivered. Hence message-style SOAP derives the full value offered by the Web Services architecture making message -based SOAP more robust and easier to change than RPC-style SOAP.

The problem with EDI-style SOAP now is that on one hand in order to work properly it relies on asynchronous, guaranteed message delivery while on the other hand this is a feature that is naturally not provided by the most popular implementations of the Web Service stack. Normally JAXM is used in order to make EDI-style SOAP calls with Java and JAXM doesn’t allow to make asynchronous SOAP calls with guaranteed delivery to arbitrary destinations. In order to reach a reliable asynchronous SOAP message transfer with JAXM so called profiles (like for example ebXML), which are domain-specific SOAP applications, have to be used.

2.3.1.4 SOAP Implementations

The integration of SOAP toolkits varies with the transport layer. Some implement their own HTTP servers for managing the HTTP traffic by means of which the SOAP messages are most frequently transferred. Some expect to be installed as part of a particular web server, so that rather than serving up a web page, the HTTP daemon hands the SOAP message to the toolkit’s proxy component, which does the work of invoking the code behind the Web Service.

Whether the transport is built-in or pluggable, all SOAP toolkits provide the proxy component, which parses and interprets the SOAP message to invoke application code. The proxy must understand how to deal with things like encoding styles and translation of native types of data into XML (and vice versa).

When the proxy component is handed a SOAP message by a listener, it must do three things:

1. Deserialize the message, if necessary, from XML into some native format suitable for passing off to the code.
2. Invoke the code.
3. Serialize the response (if it’s an RPC-style SOAP message) to the message back into XML and hand it back to the transport listener for delivery back to the requester.

2.3.2 Description Layer: WSDL

When a Web Service is implemented, it must make decisions on every level as to which network, transport, and packaging protocols it will support. A description of that service represents those decisions in such a way that the Service Consumer can contact and use the service.

The Web Services Description Language (WSDL) is the de facto standard for providing those descriptions. WSDL is not yet a W3C standard but a second Working Draft of WSDL 1.2 was released by W3C in January 2003.

WSDL is an XML-based language used to describe a Web Service’s external interface.

Web Servic es can then be made available to other users by giving them a link to its WSDL file. UDDI registries, described later, provide a place where information about a Web Service can be published.

2.3.2.1 WSDL Files

According to [SUN02] the elements of a WSDL file address what is in the Web Service, how it is communicated and where the Web Service resides:

- What: Definitions of messages and data types exchanged between client and server
- How: How the abstract interface (the portType) is bound to concrete protocols. This can be for example SOAP is being used over HTTP.
- Where: Specifies he location (URI) of the Web Service

2.3.3 Discovery Layer: UDDI

The discovery layer provides the mechanism for consumers to fetch the descriptions of providers. One of the more widely recognized discovery mechanisms available is the Universal Description, Discovery, and Integration (UDDI) project.

2.3.3.1 The UDDI Registry

The UDDI project defines a searchable registry for services and their WSDL descriptions so that consumers can automatically discover the services they need.

The UDDI registry allows a business to publicly list a description of itself and the services it provides. Potential consumers of those services can locate them based on taxonomical information, such as what the service does or what industry the service targets.

UDDI requests are transferred via SOAP to an UDDI Registry for receiving Web Service descriptions.

2.3.3.2 UDDI Registry Access

Abbildung in dieser Leseprobe nicht enthalten

Figure 6: UDDI Registry Access

According to [JeC02] two APIs are described by the UDDI specification: the inquiry API and the Publishing API. They are accessed using the same techniques but use different XML documents, data structures, and access points. The inquiry API locates information about a business, the services a business offers, the specifications of those services, and information about what to do in a failure situation. Any read operation from a UDDI registry uses one of the inquiry API's messages. The inquiry API does not require authenticated access and is subsequently accessed using HTTP.

The Publishing API is used to create, store, or update information located in a UDDI registry. All functions in this API require authenticated access to a UDDI registry; the UDDI registry must have a logon identity, and the security credentials for this identity must be passed as a parameter of the XML document for each UDDI invocation. Because publishing requires authenticated access, it is accessed over HTTPS, with a different URL than the one used with the inquiry access point.

2.4 Conclusion

In this chapter the basics of the Web Service architecture have been outlined as the Catanet platform is implemented according to the Web Service philosophy.

The functioning of Web Services can best be explained by referring to the Web Service’s Just-In-Time integration principle. In order to make the Just-In-Time integration possible three core technologies which are all XML based can be utilized: UDDI for locating Web Services and their description. WSDL to describe Web Service interfaces in a way that they can be accessed by a foreign program and SOAP to realize the communication between the Web Service provider and consumer.

Not all of these technologies have to be utilized necessarily. In the case of the Catanet platform for example only WSDL descriptions and the SOAP protocol are used.

A more detailed look has been casted on the SOAP protocol as this is the Web Service technology that is used most intensively for the Catanet platform.

The fundamental idea of SOAP is that two applications, regardless of operating system, programming language and other technical implementation details should be able to share information by means of SOAP. Therefore SOAP defines a simple XML-based envelope and rules for translating application and platform specific data types into XML representation.

SOAP comes in two flavors: EDI-style SOAP and RPC-style SOAP. In RPC-style SOAP the SOAP payload will be a representation of parameter and return values. A RPC-style SOAP message is followed by a corresponding return message holding the results of the service invocation. In EDI-style SOAP the XML payload of a SOAP message is a whole XML document and the Web Service request consists of a single message to the SOAP server without a corresponding return message.

Main advantages of RPC-style SOAP are that RPC-style SOAP requests are easy to implement in Java by means of the JAX-RPC libraries. Moreover the successful delivery of a SOAP request can be immediately recognized by the receipt of the corresponding return message. Disadvantages of RPC-style SOAP are that it tightly couples Web Services clients to the Web Services server, which means that Web Services internals like in this case a method signature are exposed to the client. Therefore any changes to the Web Service interface break the depending clients. Moreover the communication between the RPC-style SOAP clients and server is synchronous, which means that the SOAP clients block until they finally receive the SOAP response message or the transmission timer hits. In case of network problems this would cause a RPC-style SOAP client to freeze for a certain time.

In contrast to RPC-style SOAP EDI- or message-style SOAP works asynchronously and loosely coupled. Therefore it derives the full value offered by Web Services. The problem with EDI-style SOAP is that in order to work properly it requires a data transmission with guaranteed message delivery which is a feature that is not provided by the most popular implementations of the Web Service protocol stack. Therefore it is very unhandy and rarely used.

SOAP implementations may implement their own HTTP servers for managing the HTTP traffic by means of which SOAP messages are normally transferred. Others have to be installed as part of a particular web server. But all of them have a SOAP proxy-component in common which parses and interprets the incoming SOAP messages to invoke the application code.

Concerning the communication style RPC-style SOAP has been selected to be used for the data transfer between the Catanet clients and server. The abovementioned drawbacks of RPC-style SOAP are not tha t serious in our case as a synchronized communication between the Catanet clients and server is what has actually been the intention of this project. The other main disadvantage of RPC-style SOAP, the lack of flexibility due to tightly coupling between the SOAP server and client has been moderated through the definition of a Web Service interface that is as flexible as possible, that is the Web Service interface consists of methods for the different transactions which expect a string containing the transaction data, like for example a purchase order, as the only parameter. So this solution is something like a mixture of EDI- and RPC-style SOAP trying to exploit the advantages of either approach. Another advantage of RPC-style SOAP is that it eases the implementation of an own reliability protocol as it can always be decided by the presence of a return message that a SOAP transaction has succeeded and no further retransmissions are necessary. Moreover a SOAP return value may contain information concerning the success of the server side processing which may fail for example because of semantical errors in the transaction file.

Axis SOAP is used as the SOAP proxy implementation. Axis SOAP is open source software and the de facto standard SOAP implementation for Java. The Axis SOAP implementation is plugged in an Apache Tomcat server which is used as HTTP handler. On the client side Axis SOAP client libraries and JAX-RPC are used to generate SOAP messages and to send them to the SOAP server.

3 Concepts

This chapter represents the theoretical main part of this work.

The first subchapter classifies Larman’s Pattern and UML based incremental software development process which has been utilized for the implementation of the programs which have been developed in the context of this work. It is compared to the Waterfall model and the lightweight Extreme Programming development process.

The second subchapter discusses the overall design decision whether it is more feasible to let the Catanet customers realize the integration of their IT infrastructure into the Catanet platform on their own handing them only an interface description or whether a Catanet module should be provided for this purpose.

For being able to come to this decision the various technologies that could be used to integrate the Catanet client module into the customer’s IT infrastructure have had to be investigated. This is what the second subchapter deals with.

The following subchapters represent technology investigations analyzing technologies to provide a reliable and secure SOAP communication and to integrate the .NET based client side modules with the Java based server side modules.

The last subchapter elaborates the test strategy that has been employed to test the developed software.

3.1 Selection of an Appropriate Development Process

For the development of the system an iterative software development process according to Larman has been utilized.

This incremental/iterative approach represents something like an intermediate between the traditional Waterfall model and the lightweight Extreme Programming. In order to be able to better classify Larman’s iterative approach these three development processes shall be outlined briefly in this chapter.

3.1.1 The Waterfall Model

The main characteristic of the Waterfall model is that each activity within the development process (architectural design, detailed design, implementation, component testing, system testing, and deployment of the system) is done exactly once for the whole set of system requirements and it is not intended to regress to a prior development step.

There are many points of the Waterfall model that have been criticized. Here are some of them:

- Problems with the software are not discovered until the system tests.
- The requirements of the system are supposed to be definitely stated prior to the system design, which is normally hard to realize as the design and implementation frequently disclose requirements. A later change of the requirements will make the development method unstable.
- Also missing system components and unexpected development needs discovered during the implementation are a problem as the return to a former development step is not taken into account by the Waterfall model.
- Another problem represents performance issues. The performance of the system cannot be tested until it is almost implemented and performance shortcomings due to an unsuitable design for example are then difficult to fix.

3.1.2 Iterative / Incremental Software Development According to Craig Larman

In contrast to the waterfall model incremental development processes like the one suggested by Craig Larman in [Lar98] carries out the different development phases more than once.

Here is how Larman introduces his methodology:

“An iterative life-cycle is based on successive enlargement and refinement of a system through multiple development cycles of analysis, design, implementation and testing.

The system grows by adding new functions within each development cycle. After a preliminary Plan and Elaborate phase, development proceeds in a Build phase through a series of development cycles.

Each cycle tackles a relatively small set of requirements, proceeding through analysis, design, construction and testing (see 1.1, p.17). The system grows incrementally as each cycle is completed.”

This has the advantage that the complexity of the development is always controllable. Additionally implementations for the already completed development cycles are early available. Therefore an early feedback is available and shortcomings of the requirement analysis for example become apparent earlier.

Larman’s iterative development strategy is something like an intermediate between the Waterfall model and Extreme Programming as on one hand he stresses the importance of a detailed analysis and design like the Waterfall model in order to reduce the risks involved in developing a software system where changes in later phases of the development are more expansive than early changes.

But on the other hand analysis and design are incremental and he avoids the complexity of a large upfront design phase and allows the adoption of changing requirements. Additionally Larman doesn’t exclude the possibility to defer requirement considerations to later phases of the development.

3.1.3 Extreme Programming

Extreme Programming takes Larman’s approach to dispose with an extensive upfront analysis and design to extremes in that the design of the code is actually done while it’s being written. Thereby the implementation always focuses only on a small piece of software which is part of a bigger Use Case (called story).

The design of the software thereby is done by means of Refactorings, which are described in [Fow00], and which are guidelines of how to clean up the existing code in a controlled manner in order to improve the design while minimizing the chances of introducing new bugs. Thus the design needed for implementing the currently focused functionality is established.

In comparison to traditional software development processes where the costs for changes raise exponentially with the time this isn’t the case for Extreme Programming. Therefore it can be started with a simple solution which can be expanded without big effort step by step.

Refactoring is used to keep the design of the software clean thus helping to reduce the costs for future expenditures.

Extreme Programming uses a very simple initial upfront design for the basic requirements to create a running system. Programmers then work in pairs using Refactorings to improve the design of the code whenever it’s necessary to add new functions, to facilitate solutions or to clean up the code.

The customer participates in the development process as he chooses the most valuable functions, requirements or stories (similar to Use Cases) which shall be added. He thereby controls the direction in which the project shall evolve, always being able to change the direction if necessary.

More information about Extreme Programming can be found under [Bec01].

3.1.4 Summary / Conclusion

Even though the waterfall model has never seriously been considered as a development process candidate for this project it shall be mentioned for the sake of completeness that the main problem with the waterfall model is that it doesn’t regard the nature of software projects which rarely flow in a sequential process. In the waterfall model once a step is finished there is no stepping back. If for example new insights in the requirements of the software system are gained, these insights cannot be utilized for the project. Therefore the waterfall model often leads to wrong software products.

The Extreme Programming approach has also appeared to be an attractive candidate for a development process for this project at first since it also addresses rather small software projects and also represents a lightweight development process that wouldn’t have been overkill for this project. Additionally with extensive Refactorings and Unit Tests it relies heavily on techniques which are used anyway for this project.

A number of reasons have argued against the application of Extreme Programming which theoretically would have been an alternative candidate for the software development approach suggested by Craig Larman which finally has been applied.

These advantages are first of all that there is no proper documentation generated for the code throughout the Extreme Programming development process. This would have been a problem especially in this case where the project results had to be handed to other developers which were not familiar with the program after 14 months. Therefore it was crucial to maintain a thorough documentation of the code. Second the Extreme Programming development process requires that always two programmers work concurrently on the code. By the time of the beginning of this project this wouldn’t have been possible as there were only a handful of programmers working on completely different parts of the Catanet platform. Moreover Extreme Programming postulates that the customer participates in the development process. This wouldn’t have been feasible as there are dozens of different Catanet customers with different needs and computer systems. The coordination of the development process with all or many of them wouldn’t have been possible.

Apart from these hard facts which spoke against the utilization of the Extreme Programming approach I personally prefer Larman’s development process as it lines out very clearly and step by step how to receive a well designed object oriented software system in comparison to the for my taste more generic guidelines offered by Extreme Programming.

[...]