Warenkorb
0 Artikel | US$ 0,00
ID 7256
Schnieders, Arnd: Application of Web Service Technologies on a B2B-Communication
Platform by means of a Pattern- and URL-Based Software Development Process
Hamburg: Diplomica GmbH, 2003
Zugl.: Technische Universität Berlin, Technische Universität, Diplomarbeit, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
IV
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 Computer-
und 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 Firewall-
Probleme, 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
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
V
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 Softwareentwicklungs-
prozesses 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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
VI
Abstract
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
VII
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
VIII
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
IX
Table of Contents
1
Introduction
1
1.1
Motivation and Definition of the Project
1
1.1.1
Outline of the Catanet Project
1
1.1.2
Definition of the Main Tasks of this Work
2
1.2
Identification of Central Questions
5
1.2.1
Selection and Application of Appropriate Security
Mechanisms
5
1.2.2
Platform Design by Following an Appropriate Software
Development Process
5
1.2.3
Implementation Style
5
1.2.4
Transaction Reliability
6
1.2.5
System Integration
6
1.2.6
Real World Business Suitability: Speed and Stability
6
1.2.7
SOAP Communication Details
6
1.2.8
.NET-Java Integration
6
1.3
Overview of this Work
8
1.4
Objectives
10
2
Technological Background: Web Services
11
2.1
Introduction
11
2.2
Web Services Architecture: Just-In-Time Integration
12
2.3
Web Services Core Technologies
14
2.3.1
Packaging Layer: SOAP
15
2.3.1.1
SOAP Messages
15
2.3.1.2
The SOAP Data Types
17
2.3.1.3
RPC-style vs. Document-style SOAP
17
2.3.1.4
SOAP Implementations
20
2.3.2
Description Layer: WSDL
20
2.3.2.1
WSDL Files
21
2.3.3
Discovery Layer: UDDI
21
2.3.3.1
The UDDI Registry
21
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
X
2.3.3.2
UDDI Registry Access
22
2.4
Conclusion
23
3
Concepts
26
3.1
Selection of an Appropriate Development Process
27
3.1.1
The Waterfall Model
27
3.1.2
Iterative / Incremental Software Development According to
Craig Larman
28
3.1.3
Extreme Programming
28
3.1.4
Summary / Conclusion
29
3.2
Catanet Proxy vs. Catanet API Approach
31
3.2.1
Criteria for Design Decision Proxy Delivery vs. API Solution 32
3.2.1.1
Costs
32
3.2.1.2
Performance
34
3.2.1.3
Stability
34
3.2.1.4
Adaptability / Extensibility
35
3.2.1.5
User Acceptance
36
3.2.1.6
Further Considerations
36
3.2.2
Conclusion
37
3.3
Technology Evaluation for Interface between Catanet Client
and Customer's IT Infrastructure
39
3.3.1
Socket Connection
39
3.3.2
RMI (Remote Method Invocation)
39
3.3.3
CORBA (Common Object Request Broker Architecture)
40
3.3.4
JNI (Java Native Interface)
40
3.3.5
Command Line Interface
40
3.3.6
Database
41
3.3.7
Directory Based Interaction
41
3.3.8
Web Service Interface
42
3.3.9
Conclusion
42
3.4
Technology Study: How to Provide a Reliable SOAP
Communication between the Catanet Client and Server 44
3.4.1
Reliability at the Transport Level
47
3.4.1.1
Reliable HTTP (HTTPR)
47
3.4.1.2
Blocks Extensible Exchange Protocol (BEEP)
49
3.4.2
Reliability at the SOAP Protocol Level
50
3.4.2.1
Web Services Reliability Specification (WS-Reliability)
50
3.4.2.2
Web Services Reliable Messaging Protocol (WS-
ReliableMessaging)
51
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
XI
3.4.3
SOAP in Connection with JMS
51
3.4.3.1
Main Characteristics and Advantages of JMS
51
3.4.3.2
JMS and Web Services
53
3.4.4
Electronic Business XML (ebXML)
57
3.4.4.1
ebXML Message Service Specification
58
3.4.4.2
Accessing ebXML via JAXM Clients
59
3.4.5
Implementing an Own Reliability Protocol
60
3.4.6
Summary / Conclusion
61
3.5
Technology Study: How to Provide a Secure SOAP
Communication between the Catanet Client and Server 65
3.5.1
Introduction
65
3.5.2
Secure Socket Layer (SSL)
66
3.5.2.1
SSL Features
67
3.5.2.2
Handshake
68
3.5.2.3
Protocol Processing
70
3.5.2.4
Advantages / Disadvantages
71
3.5.3
XML Security
72
3.5.3.1
XML Signature
72
3.5.3.2
XML Encryption
73
3.5.3.3
Advantages / Disadvantages
75
3.5.4
Summary / Conclusion
75
3.6
Technology Study: Integration of .NET Client with Axis SOAP
Server
78
3.6.1
Approach 1: Utilization of an Entirely to Java Ported .NET
Framework
78
3.6.2
Approach 2: Compiling Java Code to MSIL
78
3.6.3
Approach 3: Compiling Java Source Code to .NET Languages
and Vice Versa
79
3.6.4
Approach 4: Using a Bridge to Interlink a .NET with a Java
Runtime Environment
79
3.6.5
Approach 5: by Using a Web Service Interface between .NET
and Java
82
3.6.6
Summary / Conclusion
83
3.7
Test Strategy
86
3.7.1
Requirements
86
3.7.2
Test Process
86
3.7.3
Component Testing with JUnit
88
3.7.4
Integration Testing
89
3.7.4.1
Big Bang Integration
90
3.7.4.2
Bottom-up Integration
92
3.7.4.3
Top-down Integration
94
3.7.5
Coverage
96
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
XII
3.7.5.1
Two Exemplary Coverage Models
97
3.7.5.2
Object Oriented Coverage
97
3.7.6
Summary / Conclusion
98
3.8
Summary / Conclusion
101
4
Realization
104
4.1
Software Development Process
105
4.1.1
Outline of Development Process
105
4.1.1.1
Phases
105
4.1.1.2
UML (Unified Modeling Language)
106
4.1.2
Plan and Elaborate Phase
106
4.1.2.1
Requirements Specification
107
4.1.3
Build Phase
121
4.1.3.1
Glossary
122
4.2
First Development Cycle
123
4.2.1
Analyze Phase
123
4.2.1.1
Conceptual Model
124
4.2.1.2
System Sequence Diagrams
130
4.2.1.3
Contracts
132
4.2.2
Design Phase
134
4.2.2.1
Expanded Real Use Cases
134
4.2.2.2
Collaboration Diagrams
140
4.2.2.3
Design of Class Diagrams
150
4.2.2.4
System Architecture Package Building
154
4.2.2.5
Complete Collaboration Diagrams Reflecting the Packet
Structure of the System
160
4.2.3
Construct Phase
168
4.2.4
Test Phase
169
4.3
Performance Measurements
170
4.3.1
First Series of Measurements: Analyzing the Overall Platform
Performance
170
4.3.1.1
Realization
171
4.3.1.2
Results
171
4.3.2
Second Series of Measurements: Evaluating the Performance
Only of the SOAP Based Message Transfer
172
4.3.2.1
Realization
173
4.3.2.2
Results
173
4.3.3
Third Series of Measurements: Evaluating the Performance of
the Server Side Processing
174
4.3.3.1
Realization
175
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
XIII
4.3.3.2
Results
175
4.3.4
Further Series of Measurements: The Performance Bottleneck
Has Been Identified
176
4.3.4.1
Results
176
4.4
Second Development Cycle
178
4.4.1
Implementation of the Retransmission in Case of Error and
Directory Based System Integration
178
4.4.2
Expanded Real Use Case
178
4.5
Third Development Cycle
182
4.5.1
Implementation of the Order Status Update Requests
182
4.5.2
Acknowledge Order
182
4.5.2.1
Expanded Real Use Cases
182
4.5.2.2
Concepts / Conceptual Model
184
4.5.3
Shipping Confirmation
185
4.5.3.1
Expanded Real Use Case
185
4.5.3.2
Concepts / Conceptual Model
187
4.6
Summary / Conclusion
188
5
Conclusion
192
5.1
Summary
192
5.1.1
Chapter two
192
5.1.2
Chapter three
192
5.1.3
Chapter four
195
5.2
Future Prospects
197
5.3
Open Issues
200
6
List of References
201
7
Appendix
205
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
XIV
Table of Illustrations
Figure 1: Overall Catanet Platform
3
Figure 2: Just-In-Time Integration
12
Figure 3: Web Services Technology Stack
14
Figure 4: SOAP Message Structure
16
Figure 5: Basic RPC Messaging Architecture
17
Figure 6: UDDI Registry Access
22
Figure 7: Catanet API Approach
31
Figure 8: Catanet Proxy Approach
32
Figure 9: SOAP Message Loss
45
Figure 10: SOAP Message Duplication
46
Figure 11: WS Protocol Stack: Reliable Transport Protocol
47
Figure 12: Reliable Messaging Through HTTPR
48
Figure 13: WS Protocol Stack: Reliable SOAP
50
Figure 14: JMS Reliable Message Transfer
52
Figure 15: JMS Based Service Bus
53
Figure 16: SOAP over JMS Architecture
54
Figure 17: Adapter Based JMS-Architecture
55
Figure 18: Reliable ebMS Message Transfer
58
Figure 19: Reliable Messaging Using JAXM and ebXML
59
Figure 20: SSL Protocol Stack
66
Figure 21: SSL Handshake
69
Figure 22: SSL Session Key Generation
70
Figure 23: XML Signature: Signing Data
73
Figure 24: XML Encryption: Encrypting Data
74
Figure 25: JNBridgePro Architecture
81
Figure 26: Antidecomposition Axiom
87
Figure 27: Anticomposition Axiom
88
Figure 28: Big Bang Integration 1
91
Figure 29: Big Bang Integration 2
91
Figure 30: Bottom-Up Integration 1
92
Figure 31: Bottom-Up Integration 2
93
Figure 32: Bottom-Up Integration 3
93
Figure 33: Top-Down Integration 1
95
Figure 34: Top-Down Integration 2
95
Figure 35: Top-Down Integration 3
96
Figure 36: Development P rocess Overview
106
Figure 37: Use Case Diagram
116
Figure 38: Development Process Build Phase
122
Figure 39: Development Process Development Cycle
123
Figure 40: Development Process Analyze Phase
124
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
XV
Figure 41: Conceptual Model of the First Development Cycle
130
Figure 42: Sequence Diagram 1 Place Order
131
Figure 43: Sequence Diagram 2 Approve Order
131
Figure 44: Sequence Diagram 3 Deliver Order (Accept Pending Service) 131
Figure 45: Development Process Design Phase
134
Figure 46: Collaboration Diagram Extract 1
144
Figure 47: Collaboration Diagram Extract 2
145
Figure 48: Collaboration Diagram Extract 3
146
Figure 49: Collaboration Diagram Extract 4
147
Figure 50: Collaboration Diagram Extract 5
148
Figure 51: Collaboration Diagram Extract 6
149
Figure 52: Class Diagram For the First Development Cycle
152
Figure 53: JBuilder Class Diagram 1
153
Figure 54: JBuilder Class Diagram 2
153
Figure 55: Package Structure of First Development Cycle
155
Figure 56: Service Package
156
Figure 57: Development Cycle 1 Collaboration Diagram 1
161
Figure 58: Development Cycle 1 Collaboration Diagram 2
162
Figure 59: Development Cycle 1 Collaboration Diagram 3
163
Figure 60: Development Cycle 1 Collaboration Diagram 4
164
Figure 61: Development Cycle 1 Collaboration Diagram 5
166
Figure 62: Development Cycle 1 Collaboration Diagram 6
167
Figure 63: Development Process Construct Phase
168
Figure 64: Development Process Test Phase
169
Figure 65: Performance Chart 1
172
Figure 66: Performance Chart 2
173
Figure 67: Performance Chart 3
175
Figure 68: Performance Chart 4
177
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
1
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
2
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
3
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
4
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
5
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
6
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
7
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
8
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 .NET-
Java 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
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
9
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
10
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
11
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
12
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.
This figure illustrates the Just-In-Time integration concept which is
characteristic for the Web Service philosophy.
Figure 2: Just-In-Time
Integration
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
13
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
14
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.
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
15
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
16
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).
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
17
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).
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:
<s:Envelope XMLns:s="http://www.w3.org/2001/06/soap-envelope">
<s:Header>
<m:transaction XMLns:m="soap-transaction"
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
18
s:mustUnderstand="true">
<transactionID>1234</transactionID>
</m:transaction>
</s:Header>
<s:Body>
<n:getOrderStatus XMLns:n="urn:catanetOrderStatusService">
<orderId xsi:type="xsd:int">
9874
</orderId>
</n:getOrderStatus>
</s:Body>
</s:Envelope>
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
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
19
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:
<s:Body>
<n:purchaseOrder XMLns:n="urn:OrderService">
<person>Christopher Robin</person>
<dept>Accounting</dept>
</from>
<to>
<person>Pooh Bear</person>
<dept>Honey</dept>
</to>
<order>
<quantity>1</quantity>
<item>Pooh Stick</item>
</order>
</n:purchaseOrder>
</s:Body>
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
20
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 Services 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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
21
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
22
UDDI requests are transferred via SOAP to an UDDI Registry for
receiving Web Service descriptions.
Figure 6: UDDI Registry
Access
2.3.3.2
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
23
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
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
24
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 that 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
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
25
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
26
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
27
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.
Diploma Thesis
CITeM La Salle Barcelona, last updated: 09/22/03
Application of Web Service Technologies on a B2B
Communication Platform by Means of a Pattern and UML Based
Software Development Process
28
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).
Ende der Leseprobe aus 288 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2003, Application of Web Service Technologies on a B2B Communication Platform by Means of a Pattern and UML Based Software Development Process, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/222559
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare