Master ThesisSoftware EngineeringThesis no: MSE-2007:28June 2007

Sending and Addressing Messages inWeb Services

Piotr Borkowski

School of EngineeringBlekinge Institute of TechnologyBox 520SE - 372 25 RonnebySweden

This thesis is submitted to the School of Engineering at Blekinge Institute of Technologyin partial fulfillment of the requirements for the degree of Master of Science in SoftwareEngineering. The thesis is equivalent to XXX weeks of full time studies.

Contact Information:Author(s):Piotr BorkowskiAddress: Kungsmarksvägen 31A lgh 267, 371 44 Karlskrona, SwedenE-mail: peter.borkowski@gmail.com

External advisor(s):dr Zbigniew FryzlewiczCompany/Organisation: Wroclaw University of TechnologyAddress:Phone:

University advisor(s):Håkan Grahn, Ph.D.School of Engineering, BTH

School of Engineering Internet : www.bth.se/tekBlekinge Institute of Technology Phone : +46 457 38 50 00Box 520 Fax : +46 457 271 25SE - 372 25 RonnebySweden

ABSTRACT

This thesis provides an overview of Web Ser-vices technology. The concept of Web Services andService Oriented Architecture are explained. Thethesis focuses on the mechanisms for transportingand addressing messages in web services, especiallySOAP. It presents the development history of SOAP,an overview of the SOAP 1.2 specification, andthe differences between SOAP in version 1.1 and1.2. Further, the thesis presents two web servers fordevelopment and deployment of web services usingJava and .NET technology, i.e. Bea Weblogic Server9.2 and Internet Information Services 7.0. The webserver implementations are evaluated both in termsof conformance to the SOAP specifications as wellas their performance (response time and throughput).The results showed that the servers performed verysimilar both for SOAP 1.2 and SOAP 1.1 messages.The response times and throughput are similar forboth servers in most cases. There are, however,situations when Weblogic perform significantlyworse than IIS, and when IIS is noticeable worsethan Weblogic. The thesis presents also generalsecurity aspects of sending messages.

Keywords: SOAP, Web Services, Evaluation

Contents

1 Introduction 1

2 What are Web Services? 32.1 Engaging Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Service Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.1 Loose coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Development and Standarization of SOAP 73.1 SOAP History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 SOAP 1.2 Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.1 SOAP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 SOAP Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 SOAP Message Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Message Exchange Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Binding to Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5.1 HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5.2 SOAP Over Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.6 RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.7 Addressing Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.7.1 Endpoint References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7.2 Message Information Headers . . . . . . . . . . . . . . . . . . . . . . . 15

3.8 Differences between SOAP 1.1 and 1.2 . . . . . . . . . . . . . . . . . . . . . . 173.8.1 Major Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.8.2 Minor Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.9 SOAP 1.1 or SOAP 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 SOAP Efficiency 204.1 SOAP Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 SOAP and Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 MTOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Implementation vs. Standard 295.1 BEA WebLogic Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Internet Information Services 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Experimental Methodology 366.1 Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2 Configuration for Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

ii

6.3 Evaluation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 Experimental Results 447.1 Response Time and Server Throughput . . . . . . . . . . . . . . . . . . . . . . 44

7.1.1 int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.1.2 double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.3 object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.4 string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.1.5 array of bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.1.6 array of ints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.1.7 array of doubles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.2.1 int, double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.2.2 object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.2.3 string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.2.4 array of bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.2.5 array of ints and doubles . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.3 Server resources requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.3.1 simple type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.3.2 string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.3.3 array of bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8 Related Work 73

9 Further Development Tendencies 749.1 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

10 Conclusions 77

iii

Chapter 1

Introduction

The development of Internet applications is rapidly growing nowadays. There are also variousprogramming environments and operating systems that have become popular. There is a need tocreate applications that would not be related to particular systems or programming languages.One solution is Web Services. They use messaging based on the well known XML standard.This enables communication among different platforms. The communication of Web Servicescan be performed with SOAP or XML-RPC messages. In this document I will focus on the SOAPtechnology as a mechanism for transporting messages.

The Web Services concept introduces an approach for developing applications which wouldbe accessible through the network for any client regardless of the operating system or softwaretechnology it uses. It should be possible that applications developed and deployed with one pro-gramming language on a particular platform are used by the clients that use another platform andother programming languages. The best practice is when the application does not force the clientto use a particular technology. Although it is hard to achieve, it garantees that every client whichwants to use the application will be able to do that. However, there is often used a fast method ofdeveloping the clients (e.g. Stub) which does not create independent clients. The clients are de-veloped with implementation knowledge about the applications deployed on the server. A changein the application often requires changes in the code of a client what is not really interoperable.

Web Services provide another look on applications. The application is not only something toexecute, it is a service that provides methods that can be used by a client to perform requestedtasks. The client does not have to use a particular service on a particular server. The Web Servicesallow a client to find a service which best fits its needs and use it. To enable searching of servicesa service discovery mechanism was created which looks for a service in a service registry. Theinformation about the service must be placed in the service registry for the service to be found.The information is a description of a web service written with a special language understood bothby services and clients. After finding appropriate service the client may engage it to perform therequested tasks. The engaging is done by invoking the proper method of the service. To invokethe method some informations have to be sent from the client to the service and then the resultshave to be sent back. The sending is done with XML technology and the most used mechanism isSOAP.

SOAP has been developed by several companies for several years. In 2000, version 1.1 wasintroduced the version 1.1 which started to be widely used in web services technology. Beforethat, XML-RPC was commonly used which is very simple technology compared to SOAP. TheSOAP 1.1 was posted to W3C organization as a Note. In 2003 the W3C released SOAP 1.2 as aRecommendation which should be used instead of SOAP 1.1. The 1.2 version was developed toremove ambiguities from SOAP 1.1 and to better organize the specification.

In this thesis I present the most important issues of the SOAP 1.2 specification. I also presenta comparison of SOAP 1.1 and SOAP 1.2, and provide information about the future plans ofthis protocol. In the next part I present two web servers, BEA Weblogic Server and InternetInformation Services, based on different technologies: Java and .NET. I compare them to theSOAP specifications to determine which parts of the standard they implement. I also evaluate the

1

performance of the servers in terms of response time, throughput and resources requirements, andcompare my results to the results found by other researchers.

The rest of the thesis is organized as follows. Chapter 2 provides background informationabout web sevices, what they are, and what other concepts are related to web services technology.The third chapter presents the SOAP protocols. A brief history of the protocol is presented andthe protocol is described. At the end of the chapter a comparison of two version of the protocol isprovided. The fourth chapter presents how the faulty situations are handled and how the protocolmay be used to send files as attachments. The fifth chapter starts the other part of the thesis. Itpresents two servers, BEA Weblogic Server and Internet Infromation Services, that can be usedto develop and deploy web services. The chapter includes the comparison of the servers to theSOAP specifications. The sixth chapter is the introduction to the performance evaluation. Thereare presented criteria according to which the servers were tested and the configuration of theexperimental environment. The seventh chapter includes the experimental results and is dividedinto sections regarding the criteria that were used during evaluation. The eight chapter presentsthe results of the experiments compared to other experiments described in articles. The ninethchapter presents the further development tendencies of SOAP protocol and the security issuesrelated to message sending. The tenth chapter includes conclusions and summary of the thesis.

2

Chapter 2

What are Web Services?

A simple definition of Web Services is: “communicate using open protocols, are self-containedand self-describing, can be discovered using UDDI, can be used by other applications, XML isthe basis” [1]. W3C says: “a Web service is a software system designed to support interoperablemachine-to-machine interaction over a network” [2]. A Web service is an abstract which has to beimplemented by a concrete agent. The agent represents the software and hardware that sends andreceives messages. The service is characterized by the abstract functionality that is provided. Toenable the interaction the machines have to “find out” themselves in the network. One machinehas to find out somehow where a machine it wants to interact with is. The Web services architec-ture enables localizing a machine and performing the interaction. Before interaction the machineshave to agree on the semantics and mechanics of the message exchange.

In the Web service architecture there are three major roles: service requester, service provider,and service discovery. A service provider is someone who implements a service and places it inthe network. A service requester is someone who wants to use a provider’s service [2]. A servicediscovery is a mechanism which locates requested services.

2.1 Engaging Web Services

The process of engaging web services may be presented in four steps (according to [2]):

1. The service requester and the service provider becomes known to each other. In most casesthe service requester agent is the initiator of the interaction so it must “find” the serviceprovider agent. This can be done in two ways:

• the requester obtains the address of the provider agent directly from the provider entity,

• the requester uses a service discovery to locate an appropriate service.

2. The service requester and the service provider agree on the service description (WSDL)and semantics. It is not necessary that these two entities communicate directly to determinethat. The provider may publish the information as “take-it-or-leave-it”, and the requesterhas to accept as it is without modifying the conditions. The desription and semantics of aservice may be defined as a standard by third party organization. The standard may be usedby many providers and requesters and they agree independently to conform to the standard.

3. Both the semantics and the service description must somehow be input to, or implementedin, both the requester agent and the provider agent before the two agents can interact. How-ever both agents implement only those aspects of the service description and semantics thatis relevant form their perspective (for example one agent’s input is another agent’s output).

4. The requester agent and the provider agent exchange SOAP messages.

3

Figure 2.1 presents the graphical overview of engaging a web service. The first point in thefigure is not present in the above description. In this point the service provider publishes theservice description to the service registry. In the second point (first point in the above description)the service requester looks for a service in the service registry. In the third point the requester andprovider agree on the description and semantics. In the third point on the service requester sideproxy to the service is created that enables invoking the web methods. In the fifth point the SOAPmessage exchange occurs.

Figure 2.1: Web Service engaging [3]

2.2 Service Description

When a service provider develops a service it also creates its description. It creates the de-scription (WSD) as machine-processable using WSDL (Web Service Description Language) [2].The description specifies the public interface of a specific web service. It can include informationon all publicly available functions, data type information for all XML messages, binding infor-mation about the specific transport protocol to be used, and address information for locating thespecified service [4]. The service description should only contain information that are exposed tothe public and important for the use. The description should also document, directly or indirectly,the semantics of the service.

2.3 Service Discovery

When a service requester wants to engage a web service and it does not know where thisservice is located then the service discovery is used to find an appropriate web service. It is notexactly specified how the service discovery obtains the services descriptions [2]. The servicediscovery can be implemented in several ways: registry, index, peer-to-peer.

The registry is a centrally controlled store of information. A service description is publishedby the service provider. The information is not available to others until the service provider placesthat information in the registry. This is an active type of publishing services descriptions. Acommon example of service registry is UDDI (Universal Description, Discovery, and Integration).

4

An index does not centrally control the informations. It does not include services descriptionsbut pointers, references to this descriptions. The index is created without the service providerknowledge. The service provider publishes a service description on the web and the index ownerdecides which services description he wants to collect. Descriptions are automatically collectedusing spiders. This is an passive approach to publish service description. Informations containedin an index can be out of date. UDDI can be used to implement index as well.

The main difference between registry and index is that the service provider decides what itwants to publish in a registry. In index type it is the index owner who decides what he wants topublish in his index.

Peer-to-peer discovery does not need any centralized registry. In this approach every webservice is a node in a network of peers, which may or may not be web services. When theservice requester wants to invoke a web service it “asks”its neighbour nodes about the service. Ifone of the nodes can perform the request it replies. Otherwise the neighbour nodes “ask” theirneighbours and so on. This way the query propagates until it reaches an appropriate node or ifanother termination criteria is reached. There is no guarantee that the request will spread acrossentire network, furthermore there is no guarantee that the request will reach the providers of anappropriate service [2].

The data captured within UDDI (Universal Description, Discovery, and Integration) is dividedinto three main categories: blue pages, yellow pages, and green pages. blue pages include generalinformation about a specific company (name, address, ...), yellow pages include general classifica-tion data for either the company or the service offered (industry, product, ...), green pages includetechnical information about a web service (a pointer to an external specification and an addressfor invoking the web service) [4].

2.4 Service Oriented Architecture

The Web Services are one, but very important, way of realizing the Service Oriented Ar-chitecture. Service Oriented Architecture represents an abstract architectural concept. It is anapproach to build software systems that are based on loosely coupled components (services) thathave been described in a uniform way and that can be discovered and composed [5]. The serviceis a view of the programs and other components showing what they do and typically carrying outa business-level operation. The SOA is independent of the technology used by the agents (pro-gramming languages, databases). It is not necessary to know the contruction of the agent wheninteracting with it. It allows any application or software component to interact with the agent ifonly they can send a message which is correct according to the service definition. The messagesare sent in a platform-neutral, standarized format. XML is the most obvious format that meetsthis constraint [2].

Figure 2.2 presents a simplified view on the Service Oriented Model of architecture. As shownin the figure the service is realized by an agent and used by another agent. The agents commu-nicate using messages. The service is described using meta-data which documents the aspects ofthe service such as interfaces, transport binding, semantics and used policies restrictions. A richdescription is key to successful deployment and use of the service in the Internet [2].

2.4.1 Loose coupling

Loose coupling means that the interacting software components minimize their built-in knowl-edge about each other. They discover the information when they need it. The loose couplingprovides: [6]

• Flexibility: The service can be located on any server and replaced. The client will be ableto find it as long as its information exists in the service registry.

• Scalability: The services can be added or removed.

5

Figure 2.2: Service Oriented Model, source [2]

• Replaceability: The new or updated implementation of a service can be introduced withoutdisruption to clients.

• Fault tolerance: If a server or network interface fails, or the service becomes unavailablefor other reasons a client can search the registry to find alternate services that provide similarfunctionality.

These benefits are very useful in a dynamically changing environment. However often there isused an easy and fast way of developing web services using integrated development environments(IDEs). In this case the clients of the services are created with “stub” classes that are dependendon the service implementation. If the implementation of the service changes then the stubs haveto be generated again to enable access to the service and the code of the client may need to bealtered to invoke the changed methods.

6

Chapter 3

Development and Standarization ofSOAP

SOAP (Simple Object Access Protocol) is an XML-based messaging protocol. It “providesa simple and lightweight mechanism for exchanging structured and typed information betweenpeers in a decentralized, distributed environment” [7]. SOAP does not define the semantics ofan application. Instead, it defines a mechanism for expressing application semantics. It does thatby providing a modular packaging model and encoding mechanisms for encoding data withinmodules [7]. Thanks to that SOAP can be used in different systems and different communicationmethods from messages to RPC.

SOAP does not define and does not force using any particular transport protocol for exchang-ing messages. The SOAP specification defines only opportunities in binding to particular proto-cols. Although it gives freedom in transport protocol choosing, HTTP is the most used.

3.1 SOAP History

The Simple Object Access Protocol was born as an idea for an XML-based RPC mechanism.The idea arose in 1998 in Dave Winer’s head, the worker of Userland Software. His idea turnedout to be a good solution and interested Don Box at DevelopMentor and Microsoft. Thanks totheir joint effort the idea evolved and SOAP version 0.9 was emerged in 1999 [8]. The developersreactions were mixed. Some of them thought about SOAP as a cool toy but not as something thatcan be useful. Soon after SOAP 0.9 came SOAP 1.0 with many improvements. The developersstarted to support this solution. The biggest technical issue (drawback) in this version of SOAPwas lack of metadata [9].

In May 2000 IBM joined the SOAP development. The first specification which IBM partic-ipated in was SOAP 1.1. This specification was sent to W3C (World Wide Web Consortium) asa Note. One can say that at this point it started “Web service revolution”. The developers whodid not interest in SOAP before (which were mostly developers of non-Microsoft platforms) tooknotice of SOAP this time. The major reason for that was that IBM joined the SOAP project. Thiscreated a promise of cross-platform interoperability between loosely coupled and dynamicallyintegrated applications which was the thing that Java’s developers philosophy was about [8].

From this point IBM and Microsoft started to develop products which used SOAP. IBM wasfirst in developing Java based SOAP toolkit that was passed to Apache Software Foundation forfurther development. Microsoft released its first SOAP toolkit soon thereafter and started its .NETWeb services initiative [8].

When SOAP based services started to grow rapidly IBM and Microsoft turned their attentionto filling the various holes in the Web Services Architecture. There was also needed mechanismfor describing and locating Web services. First Microsoft, IBM and Ariba in September 2000announced Universal Description, Discovery and Integration initiative that provides a set of toolsfor locating Web services on the Internet, and few weeks later they announced Web Services

7

Description Language, a XML-grammar for describing capabilities and technical restriction ofSOAP based Web services [8].

With growing popularity of Web services W3C created Web Services Activity which is “de-signing the infrastructure, defining the architecture and the core technologies for Web service”[10]. In September 2000 W3C Web Services Activity announced XML Protocol Working Groupthat works on XML based Web services communication. In June 2003 Web Services Activityreleased SOAP Version 1.2 which status is Recommendation.

3.2 SOAP 1.2 Message Structure

SOAP message is basically a “one-way transmission between SOAP nodes, from a SOAPsender to a SOAP receiver” [11]. However SOAP messages can be implemented in applicationsas more complex message exchange patterns starting from request/response to multiple conversa-tional exchanges.

The ultimate destination of a SOAP message is the service application (service provider)which is the SOAP ultimate receiver. However, a message can go to its destination through otherSOAP nodes which are named SOAP intermediaries. They can pass the message as they receivedit or modify it. The information inside the SOAP message (set of information items named in-foset) has to be serialized by sender in the way that the next node on the message path can read it.The most often used serialization method is XML 1.0 syntax.

A SOAP message can be presented as a picture as shown in Figure 3.1. All SOAP messageelements are placed within the SOAP Envelope. There are two specific sub-elements within aSOAP Envelope: SOAP Header and SOAP Body. The contents of these elements are not a partof the SOAP specification but are application defined. However, there are some rules saying howthese elements should be processed.

SOAP Envelope

SOAP Header

Header Block

...

Header Block

SOAP Body

Body Element

...

Body Element

Figure 3.1: Graphical SOAP Message representation

The SOAP Envelope element must have a name of “Envelope” and a namespace name of“http://www.w3.org/2003/05/soap-envelope”. Envelope may have defined an “encodingStyle” at-

8

tribute which determines what encoding rules will be used to serialize parts of SOAP message.The encodingStyle attribute may be also specified in the header block element and the child el-ements of Body element. The encodingStyle attribute is applied to descendants of the elementwhere it is specified. In Example 3.1 the Envelope element has encodingStyle attribute specifiedand this encoding will be applied to the whole message unless another encodingStyle attribute isfound.

The SOAP Header element is optional. It is an extension mechanism which provides a wayto convey the “control” information. The “control” information may define a way of process-ing the message. This mechanism enables extension of SOAP messages to specific applicationneeds. The child elements within the Header element are called header blocks. They divide theheader information into logical groups which may be individually addressed to different SOAPintermediary nodes encountered in a message path. The SOAP Header delivered to the SOAPultimate receiver is a result of participation of SOAP nodes that were on a message path (SOAPintermediaries). The intermediary nodes may modify, insert, delete or only forward headers. TheSOAP specification does not define elements of the header, path of a message, or how a header isprocessed by nodes. These may be defined by an application.

<env:Envelopexmlns:env=‘‘http://www.w3.org/2003/05/soap-envelope’’encodingStyle=‘‘http://www.w3.org/2003/05/soap-encoding’’>...

</env:Envelope>

Example 3.1: Envelope with encodingStyle attribute specified

The SOAP Body element is a mandatory element. This is the part of a SOAP message wherethe main information must be carried. The SOAP Body is intended to be understood by theultimate receiver. However, SOAP specification does not determine which SOAP node that is anultimate receiver. This is determined by an application. Moreover it cannot be prevented that oneof the SOAP intermediaries will not decide to be an ultimate receiver and will not process theSOAP Body. This situation may have undesirable effects, such as not processing desired headerblocks by intermediary nodes [11].

3.2.1 SOAP Header

A SOAP Header consists of header blocks. Each header block must have its own namespacequalified name and its namespace specified, see Example 3.2. The header block may have zeroor more attributes. These attributes can be: role attribute, mustUnderstand attribute and relayattribute [11]. The description of the role attributes is provided in the following paragraphs.

<env:Header><a:firstBlock xmlns:a=‘‘http://myheader.com’’>

...</a:firstBlock>

</env:Header>

Example 3.2: Header block with name of “firstBlock” and namespace specified

The role attribute determines which node that is the target of the header block. The nodewhich plays a role determined in a particular header block is required to process this header blockafter receiving a message containing it. The role attribute is defined by an URI (Uniform ResourceIdentifier) value. The SOAP specification defines three roles:

• http://www.w3.org/2003/05/soap-envelope/role/none,

• http://www.w3.org/2003/05/soap-envelope/role/next,

9

• http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver.

These are fully qualified names of the specified roles, but there can be used simple names: none,next and ultimateReceiver.

The “next” role determines that every SOAP node that receives a header block with this rolespecified should process this header block. As a result every node in a SOAP message path mayhave to process the same header block unless one of the intermediary nodes removes it as a resultof processing of the message.

The “ultimateReceiver” roles determines that the header block is targeted at a SOAP node thatplays a role of the ultimate receiver of a particular SOAP message. The ultimateReceiver role maybe declared implicitly and explicitly in a header block. Explicit declaration is when this role isspecified in a header block. When a header block does not contain declaration of a role attributethen it is an implicit declaration of the ultimateReceiver role. Therefore if a header block does notdeclare a role attribute it is targeted at a node which assumes a role of SOAP message’s ultimatereceiver.

The “none” role determines that a header block is not targeted at any specific SOAP node.However a SOAP node may need to process this header block to check if it includes relevant datareferenced by another header block.

Beside the SOAP specified roles applications may define their own roles used in SOAP mes-sages. These roles have to be proper URI values, such as: “http://www.myapplication.com/MyRole”.A SOAP node which plays this role have to process a header block with this role specified. Table1 gives a simple explanation which SOAP node should process a header block with particular roledeclared.

Table 3.1: Relations between roles decalared in header block and SOAP node roles, source: W3C,SOAP Version 1.2 Part 0

Role absent “none” “next” “ultimateReceiver”Nodeinitial sender not applicable not applicable not applicable not applicableintermediary no no yes noultimate receiver yes no yes yes

The mustUnderstand attribute determines that a SOAP node which plays a role declared ina header block must process this header block. This ensures that that a proper SOAP node willprocess a header block what can be very important for the application. The SOAP node must doeverything what is specified in a header block. This means that a SOAP node must “understand”a header block properly.

To enable mustUnderstand attribute it has to have “true” value. The “true” value of mustUn-derstand attribute obligates a SOAP node to process a header block according to its specificationand otherwise generate a SOAP fault. In a case of SOAP fault a message is not forwarded anyfurther and processing of that message is ceased. Depending on an application SOAP node maygenerate only a SOAP fault message or also generate additional messages to other SOAP nodes.

The relay attribute determines if a header block should be relayed by an intermediary SOAPnode if it is not processed. The default SOAP node behaviour is that it removes header blockswhich it does not process. This is a safety approach because in most cases SOAP node does notprocess header blocks because it does not understand them. It is safer to remove not understand-able header blocks than propagate an unknown meaning of a message. However an applicationdesigner may want to target a header block to any SOAP node that will understand it. In thissituation the SOAP nodes that do not understand the header block should relay it in an outboundmessage. To enable this the relay attribute with “true” value should be specified. A header blockshould not be marked with the mustUnderstand “true” attribute value then.

A good way to forward a SOAP message through all SOAP intermediary nodes with a chanceto process a header block for every of them is to declare the “next” role attribute and “true” valueof relay attribute. Every SOAP node will attempt to process the header block because of the “next”

10

Table 3.2: Relaying header blocks, source: W3C, SOAP Version 1.2 Part 1

Role Header blockname assumed understood & processed forwardednext yes yes if reinserted

no if relay=trueuser-defined yes yes if reinserted

no if relay=trueno n/a yes

ultimateReceiver yes yes n/ano n/a

none no n/a yes

role attribute and if it will not be able to process the header block it will relay it in an outboundmessage. Table 3.2 shows the conditions of relaying header blocks depending on role and relayattribute, and node behaviour.

3.2.2 SOAP Body

The SOAP Body is targeted at an ultimate receiver node. It does not have any role, mustUn-derstand or relay attributes. However, the SOAP Body can be treated as a specific SOAP Headerwith a role attribute declared as “ultimateReceiver” and a mustUnderstand attribute set to “true”.The SOAP Body element is processed only by the ultimate receiver node and the ultimate receivernode has to understand it to process it properly and eventually generate a response. The SOAPBody is also used to place an information about faulty situations when they appear.

3.3 SOAP Message Routing

When a SOAP message is sent it is addressed to the service application but SOAP does notspecify how a message path is determined and followed. However the specification defines howa SOAP node should behave if it gets a message that is not addressed to it (this node is not anultimate receiver of this message). There are two types of SOAP intermediaries: forwardingintermediaries and active intermediaries [11].

A forwarding intermediary is a SOAP node which forwards a received SOAP message toanother SOAP node. The information how the message should be forwarded can be either definedin SOAP message header or based on the message exchange pattern that is used. When theforwarding information is defined in the header then the header can contain a “routing” headerblock which may dictate that the message should be forwarded to a SOAP node defined in thatheader block.

An active intermediary is a SOAP node which does an additional action on a received messagebefore forwarding the message according to defined criteria. There can be different types ofactions performed on a SOAP message. For example it can be encrypting some parts of SOAPmessage and inserting the encryption key in a header block in the outbound message [11]. Theactive intermediary may insert some additional information in a header block about what actionsit has performed. If this information is necessary for other SOAP nodes to understand the messagethen subsequent intermediaries should reinsert this information to the header of the message theyare forwarding. This ensures that the message will be safely processed by further nodes.

A more complex action a SOAP node may perform is to amend a SOAP message. This actionis performed in the way the message sender did not anticipate. An intermediary node inserts aheader block which may be used by ultimate receiver (and only by this node) when processing themessage body.

11

3.4 Message Exchange Patterns

There are possible different types of exchanging messages between two SOAP nodes. Thereare two Message Exchange Patterns (MEP) defined is SOAP 1.2 specification:

• SOAP Request-Response Message Exchange Pattern

• SOAP Response Message Exchange Pattern

SOAP Request-Response MEP defines a pattern when a SOAP message is sent as a requestand is followed by a SOAP message sent as a response. The result of succesfuly performedexchange are exactly two SOAP messages. The request containing the SOAP Envelope is sentfrom the requesting SOAP node to the responding SOAP node, is processed by requesting SOAPnode and a response message containing SOAP Envelope is transferred from the responding SOAPnode to the requesting SOAP node.

SOAP Response MEP defines a pattern when a SOAP message is sent as a response for anon-SOAP request. The request does not contain a SOAP Envelope and does not require SOAPprocessing, the request is transmitted in a binding-specific manner. The response message con-tains SOAP Envelope. This exchange pattern cannot be used with features expressed in SOAPheaders blocks because the request does not have SOAP Envelope to insert them.

In both MEPs the failures in trasmitting the message either to the sender or to the receivermay be kept silent or may result in generating SOAP or binding-specific fault [12].

The request-response MEP may be used to create more complex message exchanges called“conversations”. The conversation is created by a number of request-response exchanges betweentwo SOAP nodes. To create a conversation there should be a way to correlate the responses withnew requests. It can be done by repetitively inserting the same information into following requestwhat will allow the service to correlate the response with previously sent request.

3.5 Binding to Protocols

The SOAP binding specifies how the SOAP message is transported from one SOAP nodeto another using an underlaying protocol. The task of the underlaying protocol is to providea serialized representation of the infoset that can be transported between SOAP nodes in themessage path in the manner that the infoset may be reconstructed without loss of information[11]. SOAP messages may be exchanged using varying underlaying protocols such as HTTP,HTTPS, SMTP, TCP, UDP, XMPP (Jabber) etc. The SOAP 1.2 specification defines only bindingto HTTP protocol and recommendation of transfering SOAP messages using the email bindingnamed SOAP Over Email. The bindings to other protocols are not defined but may be specifiedconforming to the SOAP Protocols Binding Framework. The framework provides general rulesfor the specification of protocol bindings [13]. The framework does not require that all binding useXML as a representation of XML Infoset, other representations such as encrypted or compressedmay be used.

3.5.1 HTTP Binding

HTTP is a connection model and a message exchange pattern. The servers are identified bythe clients using an URI. The client connects to the server using TCP/IP protocol, sends a requestand receives a response over the same TCP connection. The HTTP binding can be used withHTTP POST or HTTP GET method. The HTTP POST is used in SOAP request-response messageexchange pattern and HTTP GET in SOAP response message exchange pattern. The HTTP POSTmethod can be used to create or modify the state of the resource identified by an URI with datacarried in HTTP POST body. The HTTP POST request is a SOAP message which has to beprocessed and which contains all informations necessary to create a response. The HTTP POSTmethod is commonly used in RPC. The HTTP GET method is used to obtain the informationabout the resource without altering it and cannot contain SOAP message in the request. In both

12

cases the response contains a SOAP message with relevant informations and Content-Type in theresponse set to application/soap+xml.

Example 3.3 presents a HTTP POST request. I included the SOAPAction field which wasused in SOAP 1.1 to indicate the method that will be invoked on the server. In SOAP 1.2 the fieldbecame optional.

POST /Reservations HTTP/1.1Host: server.example.org-- SOAPAction: "http://server.example.org/webmethod" --Content-Type: application/soap+xml; charset="utf-8"Content-Length: nnnn

SOAP message

Example 3.3: HTTP POST request, source: [11]

Example 3.4 presents the response of the server. It contains HTTP status code and SOAPmessage in the body. If an error occurs when processing the SOAP message contained in HTTPPOST request the server should response with “Internal Server Error” and the response shouldcontain the SOAP message with fault indicating server-side error [11].

HTTP/1.1 200 OKContent-Type: application/soap+xml; charset="utf-8"Content-Length: nnnn

SOAP message

Example 3.4: HTTP POST response, source: [11]

3.5.2 SOAP Over Email

The SOAP 1.2 specification does not specify such binding but refers to SOAP Email Bindingdescribing email binding for SOAP. The receiver of the message has to have SOAP capabilitiesto properly process the messages. The sender should also have these capabilities to properlyprocess a SOAP message containing fault in response or to properly correlate the response withsent message. In other words both receiver and sender should behave as a proper SOAP nodes.The email is a one way message and do not guarantee delivery. The delivery notifications aresupported by Simple Mail Transfer Protocol (SMTP) but are separate from message processingat the SOAP layer. The response to an email may contain “In-Reply-To” header which providescorrelation at the SMTP level but does not necessarily offer correlation at the SOAP level [11].

3.6 RPC

SOAP encapsulates remote procedure call functionality with extensibility and flexibility ofXML. To invoke a SOAP RPC, the following information is needed [11]:

1. The address of the target SOAP node

2. A procedure or method name

3. The identities and values of the arguments that are passed to the procedure or method

4. Values for properties required by the features of a binding to be used (for example, “GET”ord “POST” for the WebMethod feature)

13

5. Optional header data

The RPC is carried in the SOAP Body element and is modeled as a struct which takes the name ofthe procedure or method and the field names of the parametres in the method. A struct is a struc-ture in the meaning as it occurs in common programming langauges. Example 3.5 presents howthe method is mapped to a structure used in RPC. The myMethod method takes two parametresof type int and String and will be represented in RPC as a struct presented in the example.

public int myMethod(int myInt, String myString){...}

struct myMethod {int myInt;String myString;

}

Example 3.5: RPC struct convention

The RPC response is also carried within the SOAP Body element and modeled as a struct.There is a convention of naming the responses by adding the word “Response” at the end of thecalled method. Applying this convention, the struct name for the response of the method presentedin Example 3.5 will be

struct myMethodResponse {int result;

}

The RPC convention offers a way to distinguish the result value of a method from the otherout parameters. The return value is identified by rpc:return element (see Example 3.6)....

<myMethodResponse><rpc:result>10</rpc:result>

</myMethodResponse>...

Example 3.6: Return value of a method in rpc:result element

3.7 Addressing Messages

SOAP specification does not provide a way to define where a message is going, how to return aresponse or where to to report an error. The transport layer bothered about these details. Althoughaddressing by transport layer is sufficient for many of existing services but became a limitationin developing others. WS-Addressing specification was accepted by W3C in August 2004 andprovides a standard for representing message addressing information in web services messagesand service descriptions [14]. WS-Addressing defines standard ways to route messages overmultiple transports or direct it to the third party. For example, the client may send a request to theweb service and ask to receive a response through e-mail or SMS. To enable such behaviour WS-Addressing incorporates delivery, reply-to, and fault handler addressing information into SOAPenvelope. WS-Addressing defines also a way of inserting service specific attributes within anaddress. These information are useful in creating stateful web services. The stateful web servicecan receive series of requests from one client and remember some state informations betweenrequests.

WS-Addressing introduces some new concepts: endpoint reference (EPR) and message infor-mation headers (called also message addressing properties). Endpoint is a destination at whicha web service can be accessed. Endpoint references convey the information needed to identity

14

web service endpoint. They may be used to access web service endpoint, but may be also use toaddress individual message to and from web services. Message addressing properties, which mayinclude one or more endpoint references, provide a context for that destination information [14].

3.7.1 Endpoint References

Endpoint reference is defined as a complex type in the WS-Addressing schema. It consists ofthe following properties: address URI, reference properties, reference parameters, selected porttype, service-port (service name), policy (described in WS-Policy).

Address is the only mandatory element, the rest of the properties are optional. The simpliestendpoint reference consists only of one URI:

<wsa:EndpointReference><wsa:Address>http://myUri.org</wsa:Address>

</wsa:EndpointReference>

The other elements may be used when needed. The port type and service name are very similarto the same elements defined in WSDL specification [15]. WSDL defines a port type as a nameattached to a set of operations. A binding specifies concrete inputs and outputs for the port type.A port of that type represents a deployment of the binding at a specific address. A service is anamed collection of ports.

With reference properties and reference parameters the data from other XML namespaces canbe attached to the endpoint reference. The difference between properties and parameters is in theintended usage.

A reference property is used to identify the endpoint at which a service is deployed. Twoendpoint references with the same URI address but with different reference property values definetwo different services. Reference properties are used to deliver a request to the appropriate service.For example, there can be deployed two versions of a service and requests have to specify theversion in their reference property.

Reference parametres are used to identify resources managed by a particular web service.Reference parameters tell a service which resources to handle. They do not identify the service.Two endpoint references with different reference parameters refer to the same service [14].

Typically, the base address and reference properties identify a given deployed service and thereference parameters are used to identify specific resources that are managed by that service [16].Example 3.7 presents the usage of reference property and paramter in a weather forecast service.The service offers access for normal and premium users. The type of access is specified byreference property. The reference parameter indicates resources that the request is interested in.

<wsa:EndpointReference><wsa:Address>http://example.com/weather</wsa:Address><wsa:ReferenceProperties>

<example:ServiceLevel>Basic</example:ServiceLevel></wsa:ReferenceProperties><wsa:ReferenceParameters>

<example:CityCode>NYC</example:CityCode></wsa:ReferenceParameters>

</wsa:EndpointReference>

Example 3.7: Usage of reference property and parameter, source: [14]

3.7.2 Message Information Headers

The message information items add to a message several properties. These properties enablethe identification and location of the endpoints involved in an interaction. The basic interactionpattern is “one way”. In this pattern a message is sent from a source to a destination and no

15

further interaction is present. The other interaction patterns are composed from this one. “RequestResponse” is a common interaction pattern. It consists of two “one way” interactions. First,the message is sent by a source endpoint (the request) and then the message is sent back fromdestination endpoint to the source (the replay). A replay can be either an application message, afault, or any other message [17].

Among all the properites only two are mandatory: To and Action. Both the fields are URI. TheTo field is the address of the indended receiver of the message, the Action field is an identifier thatuniquely identifies the semantics implied by the message. The request is delivered to the To URIand the Action indicates what action should be taken. The Action URI should represent a servicecorresponding to a WSDL port type. In short, the To URI specifies “where” and the Action URIspecifies “what”.

The rest of the properties are optional and may be used when considered useful. These are[17]:

• ReplayTo - an endpoint reference that identifies the indented receiver for replies of thismessage. If a reply is expected the message must contain this header. The sender must usethis header to formulate the reply message. If this header is present the MessageID headeris required.

• FaultTo - an endpoint reference that identifies the indended receiver for faults related to thismessage. If this header is present the sender must use this header of the message beingreplied to formulate the fault message. If the header is absent sender may use the ReplayToheader.

• From - a reference to the endpoint where the message was sent from.

• MessageID - an unique identifier of a message (in time and space).

• RelatesTo - a QName and an URI indicating how this message relates to another message.The type of relationship is identified by QName. The URI contains the value of the Mes-sageID header from the related message.

The ReplyTo, MessageID and RelatesTo headers are very useful when sending messages inrequest-response pattern. The request message should contain ReplyTo and MessageID headers.In the response message the To header value is set to the value of Address property of the endpointreference of the ReplayTo header from the request message. The RelatesTo header in the responsemessage contains MessageID of the request message and the type of relationship set to wsa:Reply.The process is presented in Figure 3.2.

Figure 3.2: Request-response with WS-Addressing

16

3.8 Differences between SOAP 1.1 and 1.2

One of the needs to create the next version of SOAP was to create a clear processing modeland remove ambiguities in interpreting some attributes. Another purpose was to enable SOAPbinding to various protocols (SOAP 1.1 defines only a binding to HTTP, SOAP 1.2 defines anabstract binding framework).

3.8.1 Major Differences

The first difference is in the organization of the documents containing the specification. TheSOAP 1.1 specification consists of one single document only. The SOAP 1.2 specification isdivided into three parts: Part 0 – Primer, Part 1 – Messaging Framework and Part 2 – Adjuncts.Part 0 is an introduction to SOAP 1.2 with a description of a proper message structure. Part 1provides a detailed specification of every part in the SOAP message with all possible attributes.The part contains also a message processing model and a description of a framework for bindingSOAP to underlying protocols. Implementations that are SOAP conformant have to implementeverything from Part 1. Part 2 contains descriptions of some add-ins to the SOAP core like datamodeling and encoding styles, and also RPC conventions. Conformant SOAP implementationsmay include this optional component but do not have to. If they do they have to conform torelevant parts of the specification.

The namespaces for the envelope and encoding schemas changed in SOAP 1.2. This gives anopportunity for units processing SOAP messages to recognize if it is SOAP 1.1 or SOAP 1.2 mes-sages. The envelope namespace for SOAP 1.1 message was: http://schemas.xmlsoap.org/soap/envelope,and for SOAP 1.2 messages it is: http://www.w3.org/2003/05/soap-envelope. The third differenceis that SOAP 1.2 is based on XML Infoset and SOAP 1.1 is based on XML 1.0. SOAP 1.2 putsno restriction on how the infoset is transported. It is left to the specification of an underlayingprotocol binding which XML serialization method to use in the underlaying protocol data units(for example XML 1.0 in HTTP).

XML Infoset

XML Information Set (Infoset) is an abstract data set representation of an XML document. AnXML document can be divided into several information items that represent an information set.Every well formed XML document has at least one document information item. An informationitem is an abstract representation of a part of an XML document [18]. For clarity and simplicitythe XML Infoset can be represented as a tree of related informations. However it does not haveto be available through that structure. Other structures that are capable of providing XML Infosetinformation also may be used. The XML Infoset describes the document with reference entitiesalready expanded, that is, represented by information items coresponding to their replacementtext [18].

XML Infoset is also an attempt to define which elements within an XML document that arerelevant and important. XML Infoset specification describes a conception of synthetic infosets.Synthetic infosets introduces a way for processing data not stored as XML. This data may beprocessed by XML techniques if it is possible to represent it as an XML infoset. There are eleveninformation items defined in the XML Infoset specification. Among others there is a documentinformation item which may occur only once in an XML document, character information itemfor each data character in XML document, comment information items for each XML comment,namespace information items for each namespace in each element in the XML document. TwoXML documents that look different and use different conventions (such as double and singlequotes, empty element representation <tag></tag> and <tag/>, order of the attributes within start-tag) may be equivalent in terms of XML Infoset. This is because the XML Infoset does not careabout the syntax of the XML document. It treats the XML document as a set of information itemsand if two documents have the same information they are equal.

17

3.8.2 Minor Differences

There is a lot of minor differences between SOAP 1.1 and SOAP 1.2. I will provide the mostsignificant changes according to [11].

Envelope

SOAP 1.2 disallows additional elements to appear after the SOAP Body element within theSOAP Envelope (see Example 3.8).

<s:Envelope><s:Header/><s:Body>

...</s:Body><other elements> !disallowed in SOAP 1.2... !disallowed in SOAP 1.2

</s:Envelope>

Example 3.8: Envelope structure disallowed in SOAP 1.2

Role attribute

SOAP 1.2 replaces the actor attribute from SOAP 1.1 with the role attribute. The semantic ofthe attribute is the same. SOAP 1.2 introduces two new roles: “none” and “ultimateReceiver”.

Fault codes

SOAP 1.2 adds several new fault codes and renames the fault codes of “Client” to “Sender”and of “Server” to “Receiver”. The fault codes extension mechanism from SOAP 1.1 with dotnotation is disallowed in SOAP 1.2 and replaced with structured fault codes. SOAP 1.2 addsalso the fault MustUnderstand for reporting not understood mandatory header blocks. The faultfor dealing with messages from different versions of SOAP was added as VersionMismatch andUpgrade header block (see Section 4.1).

Binding

SOAP 1.2 defines an abstract binding framework to define bindings to other protocols thanHTTP. For HTTP binding the mandatory SOAPAction HTTP header in SOAP 1.1 became optionalin SOAP 1.2. However the servers may require this header if they need it. SOAP 1.2 provides finegrained mapping between SOAP errors and HTTP status codes. The Content-Type for SOAP 1.2changed from “text/xml” to “application/soap+xml”.

RPC

SOAP 1.2 defines a new convention for representing RPC return values. The return value ofRPC has to be placed inside <rpc:result></rpc:result> tags as in Example 3.9.

<s:Body><m:CallResponse><rpc:result>result</rpc:result>

</m:CallResponse></s:Body>

Example 3.9: RPC return value

18

3.9 SOAP 1.1 or SOAP 1.2

There is a question whether is it worth changing services implemented with 1.1 standard to beconformant with 1.2 standard. The second thing related to this question is how much work doesit requires to make the change.

The implementations that are evaluated in the thesis allow to easy change from 1.1 to 1.2standard. The BEA Weblogic requires to add one annotation tag to the file implementing theservice to make it conformant to SOAP 1.2 (see Example 5.6 and its description on page 33).With Internet Information Services 7.0 there is no work required because when developing webservices the server automatically generates their description that they are conformant to SOAP 1.1and 1.2.

I think it is worth to change the services to be conformant to SOAP 1.2. That does not givebetter performance but gives better fault handling and benefits from MTOM (Message Trans-mision Optimization Mechanism) when transporting messages with attachments (described inSection 4.2).

19

Chapter 4

SOAP Efficiency

4.1 SOAP Faults

SOAP gives a model for handling fault situations while processing a message. SOAP createsan opportunity to signal a fault to the originator of a faulty message or another node. However,this opportunity depends on a transfer mechanism that is used for transporting messages.

The information about the faulty situation is placed in the SOAP Body element within a Faultsub-element. The Fault element has two mandatory sub-elements: Code and Reason and optionalsub-elements: Details, Node and Role. The mandatory Code element consists of mandatory Valuesub-element and optional Subcode sub-element. The Value element determines one of five SOAPFaults defined in the SOAP specification. The Subcode element is used to give information aboutfaults specific to the application. The Subcode element consists of mandatory Value and optionalSubcode sub-elements. With this manner a fault trees can be built to give more specific informa-tion about faults. The Value sub-elements within Subcode elements must be namespace qualifiedand must not use env namespace which is reserved for SOAP specified faults.

The mandatory Reason elements is destined for human understanding and not for algorithmicprocessing. This is a reason why a faulty situation appeared and it can give a short explanation.There must be a Text sub-element within Reason and it has to have a unique xml:lang attributewhich enables the application to give information in multiple languages.

The optional Detail element is application specific. The optional Node element determineswhich node generated a fault. If this element is absent then this is the ultimate receiver thatgenerated a fault. The optional Role element determines what is the role of a node which generateda fault.

The Fault in Example 4.1 has two mandatory elements: Code and Reason. The Value withinCode is a one of five specified SOAP faults and determines that the sender of a message generatedan inappropriate message. The fault will be received by the sender and it can take an action tocorrect further messages. The Value within the Subcode element has different namespace thanenv and it provides an application specific fault code. In the Subcode element there can be nestedmore Subcode elements. The Reason element consists of two Text sub-elements that gives ahuman understandable information in English and Polish languages about the fault.

There is a specific manner for presenting faulty situations which are results of not understand-ing mandatory header elements. These faults occur when a node does not understand a headerblock with mustUnderstand attribute set to “true”. Information about these faults are placed inthe Body element with MustUndestand value, and in the Header element as a additional headerblock named NotUnderstood. NotUnderstood header block indicates by qname attribute whichmandatory header block was not understood (see Example 4.2).

There can occur one more faulty situation when a SOAP node gets another version of SOAPmessage than it expected. This is a VersionMismatch fault and is handled by inserting an Upgradeheader block with SupportedEnvelope sub-element which indicates what SOAP message versionsa particular node is able to process. The versions are ordered from least to most preferred, asshown in Example 4.3. Additionally a VersionMismatch value is inserted into the Fault sub-

20

...<env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value><env:Subcode><env:Value>app:aFault</env:Value><env:Subcode>...</env:Subcode>

</env:Subcode></env:Code><env:Reason><env:Text xml:lang=‘‘en’’>A Reason</env:Text><env:Text xml:lang=‘‘pl’’>Powod</env:Text></env:Reason></env:Fault>

</env:Body>...

Example 4.1: Fault example...<env:Header><env:NotUnderstood qname=‘‘a:firstBlock’’

xmlns:a=‘‘http://myheader.com’’</env:Header><env:Body><env:Fault><env:Code><env:Value>env:mustUnderstand</env:Value></env:Code><env:Reason>...</env:Reason></env:Fault>

</env:Body>...

Example 4.2: NotUnderstood fault

elements within the Body element. In Example 4.3 the SOAP node prefers SOAP 1.2 messagesbut can also process messages of SOAP 1.1 what indicates the second SupportedEnveloped entry.The Body contents are omitted in this example because are analogous to NotUnderstood fault.

4.2 SOAP and Attachments

A SOAP message may need to be transferred together with data of different types. The datamay represent images, drawings or documents and is mostly in a binary format (for example gif,jpeg). The additional data may be transported with a SOAP message using Multipart/RelatedMIME structure.

A SOAP message package contains SOAP message and may also contain additional entitiesthat contain data which is in another format than XML [19]. The SOAP message may referencethe additional entities. The additional entities are often called “attachments”. The SOAP messagepackage is constructed with Multipart/Related media type. The root body of MIME structure must

21

<env:Header><env:Upgrade><env:SupportedEnvelope qname=‘‘ns1:Envelope’’xmlns:ns1=‘‘http://www.w3.org/2003/05/soap-envelope’’/><env:SupportedEnvelope qname=‘‘ns2:Envelope’’

xmlns:ns2=‘‘http://schemas.xmlsoap.org/soap/envelope/’’/></env:Upgrade>

</env:Header>

Example 4.3: Upgrade header block, source: [13]

contain a SOAP message. Additionally the type parameter defined in MIME header must be ofthe same type as the SOAP message, that is: text/xml. The MIME parts that are referenced inother parts of SOAP message package must have Content-ID or Content-Location header. At thebeginning of MIME message there is provided a separator string. The separator string is used todivide the message into data records. While processing a message the processing unit determinesthe end of each data record when it finds the separator string.

Example 4.4 presents a SOAP 1.1 message with one attached Tiff file. The whole message isof the same type as SOAP message, that is text/xml. The boundary “MIME_boundary” definedat the beginning of the message is used to separate parts of the message. The end of the messageis marked with two additinal ’-’s after the boundary string. The main part of the MIME is SOAPmessage which reference to the Tiff image. The MIME parts do not have Content-Location headerbut Content-ID. The Tiff image is referenced in the Body of the SOAP message using Content-IDheader (cid prefix).

MIME-Version: 1.0Content-Type: Multipart/Related;

boundary=MIME_boundary; type=text/xml;start="<claim061400a.xml@claiming-it.com>"

Content-Description: This is the optional message description.

--MIME_boundaryContent-Type: text/xml; charset=UTF-8Content-Transfer-Encoding: 8bitContent-ID: <claim061400a.xml@claiming-it.com>

<?xml version=’1.0’ ?><SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body>..<theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/>..</SOAP-ENV:Body></SOAP-ENV:Envelope>

--MIME_boundaryContent-Type: image/tiffContent-Transfer-Encoding: binaryContent-ID: <claim061400a.tiff@claiming-it.com>...binary TIFF image...--MIME_boundary--

Example 4.4: MIME message, source: [19]

22

Although MIME is a flexible and easy to use mechanism for transporting attachments withSOAP message, it can be less efficient. The MIME protocol requires the message receiver to readthe whole message to determine such things as number of attachments or attachments size. Thereis another protocol created to incorporate all best practices from MIME and to make sendingattachment more efficient. The protocol is called DIME (Direct Internet Message Encapsulation).The DIME message consists of data records which every has a efficient binary header. First recordcontains Message Begin flag in the header and the last record contains Message End flag. DIMEsupports also dividing large data records into multiple pieces what is called record chunk. Everyrecord which contains a part of large record has Chunk Flag in the header. This indicates thatmore data of the same record will follow. A big advantage of DIME is that every data recordheader contains information about length of the record. This is very useful and simplify movingfrom one data record to another.

Figure 4.2 presents the fields in a DIME message. The Version field determines the versionof DIME which is used in the message. The parser starts to parse the message with checking theVersion. If the parser determines that it is able to process this version of the message it startsreading it. If the parser is not compliant or cannot recognize the version it should reject themessage. All records in the message must have the same version number.

Figure 4.1: Fields in DIME message [20]

The next field is the Message Begin (MB) field and should be set only in the first record of themessage. The Message End (ME) field should be set only in the last part of the message. If theMB field is set in another record than first then the message is considered malformed. Similarlyif ME field is set in another record than last then the message also is considered as malformed. IfMB and ME fields are set in the same record then the message should consist only of one record.

The Chunk flag indicates that the message contains chunked content. A big attachment doesnot have to be in one record but can be divided into several records what is called chunking.The first record of such divided message has to contain set CF. The CF has to be set also in thefollowing records that contain a divided attachment except the record containing the last part ofthe attachment. If the parser finds a CF flag set in a record it expects that the rest of the data fromthis record could be found in the next record.

The TYPE_T field indicates how to read the TYPE field. The type 1 indicates to read theTYPE as MIME type and the type value 2 indicates that the TYPE is specified with an URI. If themessage is chunked then the TYPE_T field and the remaining fields are set only in the first part ofchunked message, int the following parts these fields are set to 0 (except DATA_LENGTH field).

The fields OPTIONS_LENGTH, ID_LENGTH, TYPE_LENGTH and DATA_LENGTH de-termine the lengths of corresponding data fields in the message. After reading these fields the

23

parser move to read the corresponding fields: OPTIONS, ID, TYPE and DATA. The OPTIONSfield can be used to add some extensibility for DIME messages. The ID field specifies an URIthat uniqely identifies the record. The TYPE field is specified according to the TYPE_T field anddetermines the type of DATA field. The DATA field contains the payload of the record.

Example 4.2 presents an exemplary DIME message. The DIME headers are written as bytevalues. First field indicates that the Version of the message is 1. The second field is set to 1 onlyin first record of the message and indicates the beginning of the message. Third field is specifiedas 1 only is the last record and indicates the end of the message. Fourth field (CF) is specifiedin the second record and indicates that the data is continued in the next record. The next recorddoes not contain CF field set what indicates that the chunked data ends in that record. Fifth field(TYPE_T)of the first record is set to 2 (10 in binary) and indicates that the type in this record willbe specified as an URI. Instead of the URI the type of this record could be also specified as anMIME type and would be then “application/soap+xml”. The second record has TYPE_T field setto 1 what indicates that the type of this record will be specified with MIME type. The third recorddoes not have TYPE_T record specified because it contains the continuation of data from secondrecord. The OPTIONS_LENGTH field is unset in all records. The ID_LENGTH is specified inthe second record and indicates the length of the ID of this record. The TYPE_LENGTH specifiedin the first and second record indicates the length of type of the records. The third record doesnot contain ID and TYPE fields because it contains the chunked data from the second record.The DATA_LENGTH field specifies the length of data included in the record. The attachment isreferenced with its ID inside the BODY of the SOAP message.

00001 1 0 0 0010 000000000000000000000000000000000000 000000000010100000000000000000000000000110110101http://schemas.xmlsoap.org/soap/envelope<soap-env:Envelopexmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"xmlns:msg="http://example.com/DimeExample/Messages/"xmlns:ref= "http://schemas.xmlsoap.org/ws/2002/04/reference/"><soap-env:Body>

<msg:GetMediaFile><msg:fileName>myMediaFile.mpg</msg:fileName><msg:file ref:location=

"uuid:F2DA3C9C-74D3-4A46-B925-B150D62D9483" /></msg:GetMediaFile>

</soap-env:Body></soap-env:Envelope>-----------------------------------------------------------------00001 0 0 1 0001 000000000000000000000000000000101001 000000000000101000000000000101011010101011100000uuid:F2DA3C9C-74D3-4A46-B925-B150D62D9483video/mpeg...First 1.42 MB of binary data for myMediaFile.mpg...-----------------------------------------------------------------00001 0 1 0 0000 000000000000000000000000000000000000 000000000000000000000000000010000110110001000000...Remaining 552 KB of binary data for myMediaFile.mpg...

Example 4.5: DIME message, source [20]

SOAP 1.2 introduces an abstraction for transporting attachments with SOAP messages. This

24

Compound SOAP Structure

SOAP Message

clip.avi

URI

SOAPMessageSecondaryPartBag image.png

����1

PPPPq

������

��:

Figure 4.2: Compound SOAP Structure, source: [21]

abstraction is presented as Attachment Feature [21]. The Compound SOAP Structure Modelconsists of a primary SOAP message part and zero or more secondary parts that are distinct fromSOAP message. The secondary parts are called “attachments” and mostly contain binary datasuch as clips, images or documents. Therefore Attachment Feature defines two properties thatare included in Compound SOAP Structure: SOAPMessage, an abstract structure which containsprimary SOAP message, and SecondaryPartBag, an abstract structure which contains secondaryparts. The secondary part may be represented by an URI referencing this secondary part or by astructure representing the secondary part itself (see Figure 4.2). The compound SOAP structuremodel does not define how a receiver of this structure should process the secondary parts. TheSOAP receiver determines, based on processing context of primary SOAP message part, whichactions should be performed on secondary parts.

The compound SOAP structure may travel through zero or more SOAP intermediaries. Eachintermediary must be able to access any secondary part. A forwarding SOAP intermediary mustgenerally forward all secondary parts. The secondary part may be removed or changed if it isspecified in a SOAP header block. A SOAP intermediary may insert new secondary parts. TheSOAP intermediaries must also maintain the integrity of references to secondary parts. Thatmeans that an URI which reference to a secondary part in an incoming message must reference tothe same secondary part in an outbound message if that part was not removed.

4.2.1 MTOM

Another approach of sending attachments with SOAP 1.2 messages is MTOM (MessageTransmission Optimization Mechanism). It uses an Abstract SOAP Transmission OptimizationFeature which is a concept for optimizing the transmission of a SOAP message by selectivelyencoding portions of the message and still presenting the XML Infoset of a SOAP message [22].The optimization can be done only for those parts of the message that are represented as base64data in canonical lexical form of the base64Binary. The SOAP nodes treat the message as a nor-mal SOAP message. The receving node should recontruct an Envelope Infoset from the optimizedSOAP message and perform SOAP processing. The reconstructed Infoset must be the same as theone transmitted by the sender. Implementations may decide to reconstruct only the appropriatepart of the message needed for processing. The SOAP intermediaries should behave the same wayas for ordinary SOAP messages.

The Abstract SOAP Transmission Optimization Feature is expanded by Optimized MIMEMultipart/Related Serialization which uses XML-binary Optimized Packaging (XOP). XOP de-scribes how serialize the SOAP envelope in an optimized way. The main concept is to remove thebinary data from the envelope and place them in XOP Package. The binary occurences inside theenvelope are replaced with xop:Include information items that include references to binary dataremoved from the XML Infoset and placed in the XOP Package. XOP defines some terms usedduring processing [23]:

• Original XML Infoset - an XML Infoset to be optimized

25

• Optimized Content - content which was removed from XML Infoset

• XOP Infoset - the Original Infoset with removed Optimized Content and replaced by xop:Includeelement information items

• XOP Document - a serialization of the XOP Infoset using XML

• XOP Package - a package which contains XOP Document and Optimized Content

• Reconstituted XML Infoset - an XML Infoset that was reconstructed from XOP Package

Figure 4.3 presents the overview of XOP process. The XML Infoset of a SOAP message istransformed into XOP Package. The package contains XOP document as the root element. Inthe document there are references to the binary parts that were removed during processing. TheOptimized Content is named on the picture Extracted Content.

Figure 4.3: XOP processing, source: [23]

The process of creating XOP Packages consists of the following steps [23]:

1. Ensure that the original XML Infoset is not already a XOP Package.

2. Create an empty package

3. Identify the element information items to be optimized inside the original XML Infoset

4. Create a XOP Infoset which is a copy of the Original XML Infoset by replacing the itemsidentified in the previous step with xop:Include element information item as follows:

• Transfer the replaced data characters into binary data by processing them as base64encoded data.

• Serialize the encoded data to the new part of the package and add appropriate metadatacoresponding to href attribute information item of the xop:Include element informa-tion item

• If the element iformation item which is optimized contains xmlmime:contentTypeattribute information item then the value of the attribute should be included appropri-ately in the metadata for the part

5. Serialize the XOP Infoset using XML and set it as a root of the package and labeling withthe application/xop+xml media type.

26

Example 4.6 presents the message before processing with XOP mechanism. The messagecontains a picture and a kind of signature. Both data are binary so it should be removed from theXML Infoset and replaced with xop:Include information items with appropriate attributes.

<soap:Envelopexmlns:soap=’http://www.w3.org/2003/05/soap-envelope’xmlns:xmlmime=’http://www.w3.org/2004/11/xmlmime’><soap:Body>

<m:data xmlns:m=’http://example.org/stuff’><m:photo xmlmime:contentType=’image/png’>/aWKKapGGyQ=</m:photo>

<m:sig xmlmime:contentType=’application/pkcs7-signature’>Faa7vROi2VQ=</m:sig>

</m:data></soap:Body>

</soap:Envelope>

Example 4.6: A SOAP message before XOP processing, source: [23]

The message processed by XOP is presented in Example 4.7. The message is placed in XOPPackage which is a MIME message. The Content-Type is set to Multipart/Related what indicatedthat the message contains different types of data. The type attribute which specifies the type ofthe message is set to application/xop+xml in case of MTOM. The package contains three parts.First part is the XOP Document that is a SOAP message with removed binary data and insertedxop:Include element information items. The xop:Include items appear in places where were bi-nary data. Each item contains a reference (href=“cid:URI”) to the binary data that was removedfrom the message and placed somewhere in the XOP Package.

The next two parts of the package are the binary data that were removed from the XMLInfoset. They have specified Content-Type fields with the values taken from xmlmime attributesinfromation item and Content-ID field by which they are referenced with href attribute informationitem.

27

MIME-Version: 1.0Content-Type: Multipart/Related;boundary=MIME_boundary;

type="application/xop+xml";start="<mymessage.xml@example.org>";startinfo="application/soap+xml; action=\"ProcessData\""

Content-Description: A SOAP message with a pic and sig in it

--MIME_boundaryContent-Type: application/xop+xml;

charset=UTF-8;type="application/soap+xml; action=\"ProcessData\""

Content-Transfer-Encoding: 8bitContent-ID: <mymessage.xml@example.org>

<soap:Envelopexmlns:soap=’http://www.w3.org/2003/05/soap-envelope’xmlns:xmlmime=’http://www.w3.org/2004/11/xmlmime’><soap:Body>

<m:data xmlns:m=’http://example.org/stuff’><m:photo xmlmime:contentType=’image/png’><xop:Includexmlns:xop=’http://www.w3.org/2004/08/xop/include’href=’cid:http://example.org/me.png’/></m:photo>

<m:sig xmlmime:contentType=’application/pkcs7-signature’><xop:Includexmlns:xop=’http://www.w3.org/2004/08/xop/include’href=’cid:http://example.org/my.hsh’/></m:sig>

</m:data></soap:Body>

</soap:Envelope>

--MIME_boundaryContent-Type: image/pngContent-Transfer-Encoding: binaryContent-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundaryContent-Type: application/pkcs7-signatureContent-Transfer-Encoding: binaryContent-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--

Example 4.7: The SOAP message after XOP processing, source [23]

28

Chapter 5

Implementation vs. Standard

There are two implementation that will be used during evaluation: BEA WebLogic Server 9.2and Internet Information Services 7.0 on Windows Vista. First implementation is based on Javaand the second one is written in .NET.

BEA WebLogic Server is a Java Two Enterprise Edition (J2EE) application server. It supportsdeployment of many types of distributed application and can be used to develop applications basedon Services Oriented Architecture (SOA). During the evaluation BEA WebLogic Server 9.2 willbe used. This version provides complete support for the J2EE 1.4 specification.

The Internet Information Services 7.0 are embedded in Windows Vista Business and supportsdeployment of distributed applications. The IIS 7.0 supports .NET Framework 3.0.

There are also other implementations such as IBM WebSphere Application Server based onJava or Apache Axis based on Java too. I decided to choose the implementation of differenttechnologies. The .NET choice was naturally IIS 7.0 because it is delivered with a quite newoperating system. To chose Java implementation two application were considered: BEA Weblogicand IBM WebSphere. The BEA Weblogic was chosen because it allows to develop and deployweb services in an easy way. With IBM WebSphere I had problems deploying web services onthe server so I abandoned this implementation.

5.1 BEA WebLogic Server

BEA WebLogic Server 9.2 implements the Java 2 Platform, Enterprise Edition (J2EE) version1.4 technologies. The Web Services are implemented using standard J2EE components, accordingto Implementing Enterprise Web Services 1.1 specification [24], which defines the standard J2EEruntime architecture for implementing Web Services in Java. WebLogic Server is used to hostWebLogic Web Services. A Web Service module may include either Java classes or EnterpriseJavaBean (EJB) that implement the Web Service. WebLogic Server uses Web Services Descrip-tion Language (WSDL) 1.1 to describe Web Services and Universal Description, Discovery andIntegration (UDDI) for finding and registering Web Services, and supports JAX-RPC (Java APIfor XML-based RPC) – a standard to invoke Web Services.

WebLogic Server uses SOAP as a standard for formatting messages that are used for transmit-ting data and Web service invocation calls between Web service and the user of the Web service.WebLogic Server implements both SOAP 1.1 and SOAP 1.2 version when accepting and sendingSOAP messages. By default WebLogic Server uses SOAP version 1.1 To use SOAP 1.2 messag-ing it is necessary to specify the weblogic.jws.Binding JWS Annotation Tag. WebLogic Serversupport also SOAP with Attachments API for Java (SAAJ) 1.2 specification which describes howdevelopers can produce and consume messages conforming to SOAP 1.1 and SOAP with Attach-ments notes.

As said in [25] BEA does not conform exactly to all possible Web Services specifications butconsider Web Services platforms interoperability to be more important. Therefore BEA compliesto Basic Profile 1.1 specification [26] from the Web Services Interoperability Organization (WS-I)and treats it as the baseline for Web Services interoperability.

29

When using SOAP 1.1 messaging BEA introduces some changes according to Basic Profile1.1 which puts some restrictions on SOAP 1.1 messages and adopts some features from SOAP1.2 specification to SOAP 1.1 messaging. Significant changes according to the Basic Profile 1.1(henceforth called Profile) specification are given in following paragraphs.

SOAP Envelope

• SOAP 1.1 allows additional subelements following SOAP Body element but does not sayclearly how to interpret these elements. Therefore the Profile puts a restriction that theremust not be any element after SOAP Body element in SOAP Envelope.

• According to SOAP 1.1, when SOAP application receives a message where SOAP Envelopeelement is associated with another namespace than “http://schemas.xmlsoap.org/soap/envelope”the application must discard the message. The Profile adds restriction that the applicationmust generate a fault to assure unambiguous situation.

• The Profile says also that the child elements of SOAP Body element must be namespacequalified to avoid name conflicts, SOAP 1.1 says that they may be namespace qualified.

SOAP Processing ModelThe Processing Model Profile adopts several features from SOAP 1.2

• A receiver must generate a MustUnderstand fault when it receives a message with manda-tory header block (mustUnderstand attribute set to “1”) that it does not understand.

• A receiver must handle envelopes in such way that any checking of mandatory header blocksis performed before starting processing the message. SOAP 1.1 does not say explicit what isthe order of processing a message which contains mandatory header block. This restrictionensures that there will not be any undesirable site effects that could occur if some part ofthe message would be processed before noticing of a mandatory header block.

• When a SOAP Message receiver generates fault it should not process further message con-tent. It is only allowed to perform operations that are needed to rollback any effects ofprocessing the envelope before generating the fault.

SOAP Faults

• The Profile restricts the content of a Fault element within a SOAP Body when there isa faulty situation. A Fault element must not have other child elements than faultcode,faultstring, faultactor and detail as in Example 5.1. SOAP 1.1 allows other subelements toappear within the Fault element (see Example 5.2).

<soap:Fault xmlns:soap=‘‘http://schemas.xmlsoap.org/soap/envelope/’’><faultcode>soap:Client</faultcode><faultstring>Invalid message format</faultstring><faultactor>http://example.org/someactor</faultactor><detail>

<m:msg xmlns:m=‘‘http://example.org/faults/exceptions’’>There were elements in the message that I did not understand

</m:msg><m:Exception xmlns:m=‘‘http://example.org/faults/exceptions’’><m:ExceptionType>Severe</m:ExceptionType>

</m:Exception></detail>

</soap:Fault>

Example 5.1: Correct Fault according to Basic Profile 1.1; source [26]

30

<soap:Fault xmlns:soap=‘‘http://schemas.xmlsoap.org/soap/envelope/’’><faultcode>soap:Client</faultcode><faultstring>Invalid message format</faultstring><faultactor>http://example.org/someactor</faultactor><detail>

There were elements in the message that I did not understand</detail><m:Exception xmlns:m=‘‘http://example.org/faults/exceptions’’>

<m:ExceptionType>Severe</m:ExceptionType></m:Exception>

</soap:Fault>

Example 5.2: Correct Fault according to SOAP 1.1, but incorrect according to Basic Profile 1.1;source [26]

• Profile does not allow subelements of Fault element to be namespace qualified. Thesesubelements must be unqualified as in Example 5.1. The Fault subelements with qualifiednames are treated incorrect although they are correct according to SOAP 1.1 (see Exam-ple 5.3.

<soap:Fault xmlns:soap=‘‘http://schemas.xmlsoap.org/soap/envelope/’’><soap:faultcode>soap:Client</soap:faultcode><soap:faultstring>Invalid message format</soap:faultstring><soap:faultactor>http://example.org/someactor</soap:faultactor><soap:detail>...</soap:detail>

</soap:Fault>

Example 5.3: Qualified Fault subelements, correct according to SOAP 1.1 but incorrect afterBasic Profile 1.1; source [26]

• Faultstring subelements within Fault element are used to provide human understandabledescriptions of faults. The Profile adds the xml:lang attribute which may be used to indicatethe language of the particular faultstring. The Profile also puts restriction that the receviermust accept faults that have xml:lang specified in faultstring element.

• SOAP 1.1 allows to define and insert own fault within faultcode element using standardSOAP faultcodes and “dot” notation as in Example 5.4. Profiles states that “dot” notationshould be avoided because using it may cause iteroperability issues when using the samenames in the right side of “.” to convey different meaning.Profile encourages to use standard faultcodes defined in SOAP 1.1 and specify the nature offault by inserting additional information into the detail element. The second way of usingcustom faultcodes is to define them in a specific namespace (Example 5.5).

<soap:Fault xmlns:soap=‘‘http://schemas.xmlsoap.org/soap/envelope/’’xmlns:c=‘‘http://example.org/faultcodes’’>

<faultcode>soap:Server.ProcessingError</faultcode><faultstring>An error occurred while processing the message</faultstring>

</soap:Fault>

Example 5.4: Custom faultcode with “dot” notation; source [26]

SOAP and HTTP

• SOAP 1.1 allows to send SOAP messages using HTTP POST method and HTTP ExtensionFramework M-POST method. Profile restricts that SOAP Message may be only send as

31

<soap:Fault xmlns:soap=’http://schemas.xmlsoap.org/soap/envelope/’xmlns:c=’http://example.org/faultcodes’ >

<faultcode>c:ProcessingError</faultcode><faultstring>An error occured while processing the message</faultstring>

</soap:Fault>

Example 5.5: Custom faultcode defined in namespace; source [26]

an HTTP POST method. The Extenstion Framework cannot be used for sending SOAPmessages.

• SOAP 1.1 defines a HTTP SOAPAction header which can be used to indicate the intent ofthe SOAP HTTP request. Profile adopts a restriction from SOAP 1.2 stating that a messageReceiver must not rely on the SOAPAction HTTP header to correctly process the message.

Table 5.1 presents a quick summary of differences in BEA implementation of SOAP 1.1 andSOAP 1.1 specification presented in preceding paragraphs. In the first column there are presentedfeatures that differ, in the second column there is written how BEA implements that feature and inthe third column there is written the type of difference. The type of difference can be: restriction,when implementation of a feature is restricted; extension, when implementation adds a featurethat is not present in SOAP 1.1 specification; SOAP1.2, when a feature is adopted from SOAP1.2.

Table 5.1: BEA implementation of SOAP 1.1 and SOAP 1.1 spec-ification differences

Feature BEA Type of differenceAdditional elements after SOAPBody element in SOAP Envelope

not allowed restriction

Child elements of SOAP Bodymay be namespace qualified

Child elements of SOAP Bodymust be namespace qualified

restriction

Order of processing mandatoryheader blocks

Receiver must handle the messagein a way that all mandatory headerblocks are checked before startingprocessing the message

SOAP1.2

Processing the message whengenerating fault

Recevier should not process fur-ther message content

SOAP1.2

Additional child elements otherthan faultcode, faultstring, fault-actor and detail in SOAP Fault el-ement

not allowed restriction

Namespace qualified child ele-ments of SOAP Fault element

Child elements of SOAP Faultelement must not be namespacequalified

restriction

Faultstring subelement in SOAPFault element

Adds xml:lang attribute that indi-cates the language of faultstring

extension

Receiver must accept faults withxml:lang attribute specified

extension

Custom faultcodes Does not use “dot” notation butuses standard SOAP faultcodeswith additional information insidedetail element

32

Feature BEA Type of differenceHTTP Extension Framework M-POST method of sending SOAPmessages

not allowed restriction

HTTP SOAPAction header Receiver must not rely on thisheader to correctly process themessage

SOAP1.2

As written above BEA documentation states that the product implements also SOAP 1.2 mes-saging. To use it instead of SOAP 1.1 it is necessary to specify weblogic.jws.Binding JWS Anno-tation Tag. Default value of this Tag is Type.SOAP11 which indicates using SOAP 1.1 messagetype for the request and response messages. Changing the value of this Tag to Type.SOAP12enables using SOAP 1.2 version messages (see Example 5.6)....import javax.jws.WebMethod;import javax.jws.WebService;

import weblogic.jws.Binding;

@WebService(name="SOAP12PortType",serviceName="SOAP12Service",targetNamespace="http://example.org")

@Binding(Binding.Type.SOAP12)

public class SOAP12Impl {

@WebMethod()public String sayHello(String message) {

...}

}

Example 5.6: Specifying SOAP 1.2, source [25]

5.2 Internet Information Services 7.0

Internet Information Services 7.0 uses .NET Framework 3.0. The framework supports bothSOAP 1.1 and SOAP 1.2 messages. Implementation of SOAP 1.1 is done according to BasicProfile 1.1 document published by Web Service Interoperability Organization. This is the samedocument as in BEA Weblogic Server and it was described in preceding section (Section 5.1..NET Framework 3.0 supports also SOAP 1.2 specification. Messages conforming to both speci-fications may be supported by the same service (in BEA the service supports either SOAP 1.1 orSOAP 1.2 messages). When deploying a Web service, the WSDL document contains definitionof ports for both SOAP 1.1 and SOAP 1.2 messages (in BEA it was necessary to add appropriatebinding in the implementation of the service). The support may be disabled by modifying theconfiguration in web.config file (see Example 5.7).

The remove name tag specifies which message types are disabled. The “HttpSiao12” valuedisables support for SOAP 1.2 messages and “HttPSoap” – for SOAP 1.1 messages. I includedboth values in the example but of course only one should be used in accordance to the needs.

33

<configuration><system.web>

<webServices><protocols>

<remove name="HttpSoap12"/><remove name="HttpSoap"/>

</protocols></webServices>

</system.web></configuration>

Example 5.7: Disabling support for particular message types

5.3 Request Processing

The scenario of request processing on Bea Weblogic Server is presented in Figure 5.1. Whenusing Java sockets the Socket Reader thread is created for every incoming request. By defaultthe Weblogic Server is configured with one Requeat Queue [27]. The additional queues may becreated to process different types of requests (e.g. HTTP and non-HTTP requests). After therequest is taken from the queue it is processed by the Worker Thread.

Figure 5.1: Bea Weblogic Request Processing [27]

In Internet Information Services there are protocol listeners that listen for protocol-specificrequests [28], send them for processing and then send the response to the requestor (e.g. HTTP.sysis responsible for HTTP requests). The requests are processed by Worker Processes that arecreated within Application Pools. The Worker Processes and Application Pools are managed byWindows Process Activation Service (WAS).

Figure 5.2 presents two application pools on Internet Information Services. The first applica-tion pool is created for Web Garden application, the second for another application. Within theapplication pools the worker processes exist. When a protocol listener gets a request it passes itto WAS. WAS determines if a worker process is running within the application pool. If the appli-cation pool has already a worker process running then the request is passed to the worker processfor processing. If the application pool does not contain a worker process yet, WAS will start aworker process for processing the requests.

.

.

34

.

Figure 5.2: IIS Application Pools [29]

35

Chapter 6

Experimental Methodology

This chapter presents the criteria defined and used during the experiments. In further partthere is presented the configuration of the computers that were used in the experiments.

6.1 Evaluation Criteria

During the experiments I wanted to test the performance of the servers and how they deal whenchanging the number of clients sending requests. I defined the criteria which should allow me totest the performance by measuring behaviour of the servers under different load. In the experimentthe response time will be measured as well as server throughput, the size of transported messagesand the resource usage of the server. Every kind of test will be performed with the changingnumber of clients, different types of messages and different data types transported within themessages. The defined criteria are presented below:

1. Response time.The response time is the time that elapses between sending a request from the client com-puter and receiving the response from the server by this client. The measurement will bedone for messages containing data of different complexity. Messages will contain data ofsimple types, arrays of simple types, strings, arrays of bytes and user defines data typeswhich will be sent as objects. The measurement will be performed with varying size ofarrays and strings:

• size of array will be 0 elements at the beginning and will increase with 1000 elementsfor each test up to 10000 elements.

• size (length) of string will be 0 characters at the beginning and will increase with 100characters for each test up to 1000 characters.

All clients will send messages with the same data types during one test. Each Client willperform 100 request and then will read the time that elapsed from the beginning of the test.The response time will be the average time of the performed 100 requests. The measurementwill be performed with different number of clients. It will start with one client and willincrease up to 100 clients. The response time when using multiple clients will be the averagetime of all average clients’ times.

2. Server throughput.The server throughput will show how many request per time unit the server can handle.The measurement will be performed with the same types as in response time measurementand clients will send messages with the same data types during test one. The number ofclients will also change in successive tests starting with 1 client and increasing up to 100clients. A request will be sent 100 times and then the number of request will be divided bythe overall time what will result in the number of request per time unit.

36

3. Network traffic.The network traffic will show the size of messages transported through the network whensending a request from the client and receiving a response from the server. This measure-ment will also show what the overhead is when sending different types of data using SOAP.The data types used in this measurement will be the same as in preceding criteria. The sizesof arrays and strings will vary as well:

• size of array will be 0 elements at the beginning and will increase with 1000 elementsfor each test up to 50000 elements,

• size (length) of string will be 0 characters at the beginning and will increase with 100characters up to 10000 characters.

The sizes are greater than in the response time measurement because each size will be testedonly once, without repetition, and will not delay tests. Large sizes in the response time testwould cause long response times and test might last too long.A request will be performed once by only one client because the size of a transported mes-sage does not depend neither on the number of clients performing the request nor on thenumber of repetitions of a request. The size of message depends only on the encoding rulesused when serialising the message.The network traffic will be monitored using Ethereal - network protocol analyser, www.ethereal.com.

4. Server memory requirements.During this measurement clients will behave in the same manner as in response time mea-surement. The measurement will show how the memory requirements of the server varieswhen processing requests containing different data types from varying number of clients.

The user defined data type is a simple class with three fields representing data of a person (seeListing 6.1).

public class UserClass{

String firstName;String lastName;int number;

...}

Listing 6.1: User defined class

6.2 Configuration for Evaluation

During the evaluation I used one computer as a server and two computers as clients. Theirconfiguration is presented below.

Server

• Hardware

– CPU: Intel Pentium 4 HT 2,80 GHz

– Memory: 1024 MB

– Network card: 3Com Etherlink 100 MBit

• Software

37

– Operating System 1: Windows XP Professional with Service Pack 2

– Operating System 2: Windows Vista Business

Clients

• Hardware

– CPU: Intel Pentium 4 HT 2,80 GHz

– Memory: 512 MB

– Network card: 3Com Etherlink 100 MBit

• Software

– Operating System: Windows XP Professional with Service Pack 2

– .NET Framework 2.0

– Java Runtime Environment 1.5.04

The computers were in the same local area network although they were not connected directlybut using the university’s network. There were two operating systems installed on the servercomputer depending which web service server software was tested. Internet Information Services7 is embedded in Windows Vista and it was necessary that this operating system was installed. Ihad also to install the Windows XP Professional operating system to test BEA Weblogic Server9.2 because it does not run in Windows Vista.

Client computers with high performance processors allowed to run up to fifty threads on eachof them during the evaluation. When running fifty threads in the most demanding tests proces-sor usage was not greater than eighty percent and memory usage did not raise more than 300megabytes when running Java clients and 100 megabytes when running .NET clients. Looking atthe system monitor showing processor and memory usage of the client computers during testingallowed me to determine that their configuration should not be a bottleneck in the evaluation andshould not influence the results.

6.2.1 Server

For the evaluation I developed web services for each of the servers. The web services had webmethods necessary to perform the required tests. The web methods were simple, one can say thatthese were echo methods because they had only one parameter which was passed by the clientsand responded with the same data that they received. One web method is presented in Listing 6.2.This is a web method written in Java for Bea Weblogic web service. As you can see there is usedthe WebMethod annotation (annotations are with @ symbol). It indicates that this method will bepublished on the server with the web service and will be accessible for clients to invoke. The restof the method looks like a typical Java method.

@WebMethod()public byte[] echoByteArray(byte[] value){

return value;}

Listing 6.2: echoByteArray method in Bea Weblogic Server

Web methods for Internet Information Services are implemented in C# and look similarly.There is also WebMethod annotation but the annotation tag here is composed of two square brack-ets. The rest of the method is the same as in typical C# method.

Listing 6.4 presents the skeleton of a web service written for Bea Weblogic Server. Whendeveloping a web service for Bea Weblogic it is necessary to include several annotations in the

38

[WebMethod] public byte[] echoByteArray(byte[] value) {return value;

}

Listing 6.3: echoByteArray method in Internet Information Services

beginning of a Java file. The WLHttpTransport annotation is used to determine how a web servicecan be found on the server. The contextPath and serviceUri attributes define the path to the webservice. For example, if the server URI is http://myserver.org then the URI of the web service ishttp://myserver.org/test/TestService. The portName attribute defines the name of the port throughwhich the web service is accessible. The SOAPBinding annotation defines how the requestsand responses are encapsulated in a SOAP message (how the names of invoked methods andparameters are passed). The WebService annotation is mandatory in the web service file. Itincludes all necessary attributes to define the web service. The serviceName attribute defines thename of a web service and the targetNamespace attribute defines the namespace that will be usedin SOAP messages. The name attribute defines the port which is used to invoke the web service.Usage of the attributes will be presented further when describing the code of the client.

import javax.jws.WebMethod;import javax.jws.WebService;import javax.jws.soap.SOAPBinding;import weblogic.jws.WLHttpTransport;import weblogic.jws.Binding;

@WLHttpTransport(contextPath="test", serviceUri="TestService",portName="TestServicePort")

@WebService(serviceName="TestService", name="TestPortType",targetNamespace="http://testing.org")

@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,use=SOAPBinding.Use.LITERAL,parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)

public class TestImpl {@WebMethod()//implementation of a web method here

@WebMethod()...

}

Listing 6.4: Annotations used in the file defining a web service for Bea Weblogic Server

The skeleton of a web service implementation written in C# is presented in Listing 6.5. Theweb service for Internet Information Services was implemented in an asmx file. The first entry inthe file determines in which language the web service is written. There is a WebService annotationwith one attribute determining the namespace which will be used in SOAP messages. The nameof the web service will be the same as the class name. The path to the web service will be thename of this service, if the server URI is http://myserver.org then the URI of the web service willbe http://myserver.org/firstservice.

39

<%@ WebService Language="C#" Class="FirstService" %>

using System;using System.Web.Services;

[WebService(Namespace="http://localhost/FirstService/")]

public class FirstService : WebService {

[WebMethod]//implementation of a web method here

[WebMethod]...

}

Listing 6.5: Annotations used in the file defining a web service for Internet Information Services

6.2.2 Clients

The clients were implemented in Java to invoke web services deployed on Bea WeblogicServer and in C# to invoke web services deployed on Internet Information Services. To invokeweb services on both servers I used the Stub method. In this method the wsdl file describing theweb services is read from the server and the stubs are generated on the client side.

The Stub method is implementation dependent and when the service deployed on the serverchanges this requires to generate new stubs. There are also dynamic methods which are notdependent on the implementation. I used Stub method because it was the easiest to invoke webservices this way. Using this method I could focus on testing and the results not on spendingtime implementing test cases. The services on the server were the same during the tests so oncegenerated stubs were used all the time.

The stubs are classes and interfaces that contain all web methods provided by the web service.When a web method is to be invoked, the method of the local stub is invoked which gets allnecessary parameters, transfers the data into a request which is passed to the web service.

For Java implementation the JAX-RPC technology was used. There were generated 4 Javaclasses representing the Bea Weblogic’s web service: TestPortType, TestPortType_Stub, TestSer-vice and TestService_Impl. The TestPort and TestService are interfaces, and TestPortType_Stuband TestService_Impl are implementation of these interfaces. The names of the classes are takenfrom the attributes of the WebService annotation (see previous subsection). All web methods areinvoked through a proxy which is a port of type TestPortType. The access to this port is grantedby the method inside the TestService class (see Listing 6.6). This class contains only one usefulmethod, which is necessary to get the access to the port.

public interface TestService extends javax.xml.rpc.Service {...testing.webservices.client.TestPortType getTestServicePort()

throws javax.xml.rpc.ServiceException;...

}

Listing 6.6: Method inside TestService class needed to get access to the proxy

The implementations of all web methods are in the TestPortType class. Beside these fourclasses there was also generated a wsdl file and two xml files that describe the relations betweenthe Java types and types used in SOAP messages. In short they describe how the Java types shouldbe written into SOAP messages.

40

To invoke a method from the web service, the Java client first has to connect to the webservice and get access to the proxy. Listing 6.7 shows the piece of code responsible for gettingaccess to the web service. First, the TestService instance is created by calling the contructor witha parameter that is the URI to the wsdl file of the web service. After connecting to the webservice the access to the port is created, and through this port all web methods will be invoked.The third row shows an exemplary invocation of a web method. It looks like an invocation of anordinary Java method. All processing needed to create, send and get the proper SOAP message isperformed by JAX-RPC and I do not bother about that in the application code.

TestService service = new TestService_Impl(wsdlURL);TestPortType port = service.getTestServicePort();result = port.echoDouble(value);

Listing 6.7: Getting access to the web service proxy in Java client

In C# there was generated only one class which contained all web methods from the webservice and the mechanisms to connect to the web service. There was also generated a local copyof the wsdl file of the web service. Listing 6.8 shows the code responsible for connecting to theweb service. Here only the instance of the FirstService class needed to be created. The webmethods are invoked through this class.

FirstService service = new FirstService();result = service.echoDouble(value);

Listing 6.8: Getting access to the web service in C# client

There is one important thing when generating the classes for both implementations. The Javaimplementation additionaly generated the classes to keep the array of ints and the array of doubles.These are ArrayOfint_Literal and ArrayOfdouble_Literal classes. They contain one attribute tokeep the particular array and two methods to store the array in this attribute and to read it. Thisbehaviour has a significant impact on the results presented in further chapter. The results ofthe Java implementation are affected by additional operations of serializing and deserializing thearrays in the objects.

The client applications were command line programs which got three arguments: the numberof the test to run, the number of clients and the size in case of arrays and strings. The applicationcreated the number of threads specified as the number of clients and every thread played a role of aclient. The threads were started and the application waited until all the threads ended. Listing 6.9presents the piece of code responsible for this. This is a pseudo code because the threads werecreated in the same manner in Java and C# so I only want to present the idea.

static void methodPreparingThreads(){

Thread threads[] = new Thread[threadsnumber];for (int i=0; i<threadsnumber; i++)

threads[i] = new Thread(new TestThread(whichTestToRun));for (int i=0; i<threadsnumber; i++)

threads[i].start();for (int i=0; i<threadsnumber; i++)

threads[i].join();}

Listing 6.9: Creating and running threads

The threads are kept in the array and every created thread gets the number of tests that shouldbe run. The test is repeated 100 times and the thread reads the time of the system before startingthe test and after finishing the test. The interval is added to the overall time of all threads. The

41

overall time and the times of the start and the finish are then displayed on the screen. Listing 6.10presents the pseudo code executed by the thread.

void testWebMethodName(){

time1 = readTheTime;for (int i = 0; i < 100; i++)

invokeTheWebMethod(randomValue);time2 = readTheTime;duration = time2 - time1;blockAccess(overallTime);overallTime.add(duration);giveAccess(overallTime);Display time1 and time2;

}

Listing 6.10: Running test for particular web method

The web method is invoked with random values. The int and double types are generated forevery method invocation. The larger types, i.e. string and arrays, are generated randomly beforethe loop and the web method is invoked with the generated value. The generation of the arraysand strings is done outside the loop and before reading the time of start to prevent the time of thegeneration to affect the real time of the execution (especially the generation of larger arrays andstrings would affect the results significantly).

The duration of the execution is added to the overallTime variable which is common for allthreads and has to be blocked by one thread to prevent access from different threads at the sametime. At the end the time of the start and the time of the finish are printed on the screen. I neededboth the overall time of the execution and the times of start and finish to measure performanceaccording to different criteria. The overall time was needed to calculate the response times andthe times of start and finish to calculate the server throughput.

6.3 Evaluation Process

To automate the evaluation process I created the batch files which was executed instead ofwriting each time the execution path with all arguments in the command line. The C# applica-tion was an exe file which executes ’normally’. The Java application was executed with the Antproduct delivered together with Bea Weblogic. To execute Java clients I had to create, beside thebatch files, the xml files which were read by Ant. With all the files created the applications wereexecuted using only the batch files. All results printed by the application were redirected to a file.The example of a batch file is presented in Listing 6.11.

@echo offecho Testing with 1 Thread..\wsclient.exe 1 1 0 > result\001.txt

Listing 6.11: Batch file example

The batch file prints with an echo command a status message which informs what is currentlytested. In the next line the application is executed with proper arguments. The first argumentindicates that the test with number 1 (echoInt) will be performed. The second argument indicatesto run the test with 1 client and the third argument indicates to use the data of size 0. In thiscase the third argument is useless it is only taken into consideration when arrays and strings aretested. The “>” sign indicates that all results printed by the application will be redirected to thefile 001.txt in the folder with name “result”.

As I wrote in Subsection 6.2.2 the overall time of the execution was stored in one variable andthe times of start and end of the execution were printed on the screen (stored in a file in fact). The

42

overall time was used to measure the response times. The response time I calculated dividing theoverall time by the number of requests sent to the server.

Timeresponse =OverallExecutionT ime

NumberOfRequests

The NumberOfRequests includes the number of requests performed by all clients. If the numberof clients is 10 then the number of the requests will be 1000 (every client repeats the test 100times which means it sends 100 requests).

To calculate the throughput I needed the real time of the server while it was executing therequests. The real time of the server is the duration between the start of the first thread and theend of the last thread. In other words this is the duration between the earliest and the latest timereported by the threads.

Throughput =NumberOfRequests

RealT imeOfTheServer

Depending on the time unit used in the denominator the throughput will show the number ofrequest that server is able to process in this time unit.

Monitoring the network was done with the Ethereal product downloaded for free from www.ethereal.com.The Ethereal was configured to listen to the traffic from and to the computer which was sendingthe messages.

Consumption of the resources on the server was monitored with Windows Performance Mon-itor in Administrative Tasks. The monitored resources were CPU and memory.

43

Chapter 7

Experimental Results

In this chapter I present the results of my experiments. The chapter is divided regarding thecriteria defined in Section 6.1. The simple types used in the evaluation were: int, double andstring. The evaluation with string data type is performed for various sizes of the transportedstring. The abbreviations used when presenting the results are:BWS11 - Bea Weblogic Server 9.2, evaluated using messages conforming to SOAP 1.1,BWS12 - Bea Weblogic Server 9.2, evaluated using messages conforming to SOAP 1.2,IIS11 - Internet Information Services 7, evaluated using messages conforming to SOAP 1.1,IIS12 - Internet Information Services 7, evaluated using messages conforming to SOAP 1.2.

7.1 Response Time and Server Throughput

This section presents the results of the response time and server throughput tests. Each sub-section presents results for a specific data type. In each subsection there is presented result ofresponse time test and server throughput test.

7.1.1 int

Figure 7.1 shows how the response times differ when the number of clients sending requestswith int data type increases over time. Response times of the same server parsing SOAP 1.1 andSOAP 1.2 messages are almost the same. The biggest difference is about 10 ms and takes placesporadically (for example for 50 clients of Weblogic). The response times are also very similarfor two servers. The biggest difference is about 30 ms in the range of 40 and 50 clients for SOAP1.2 messages. During the whole test the difference between servers is 10-20 ms. Most of the timeWeblogic has quicker responses than IIS and in the end for 100 clients this tendency is kept.

Figure 7.2 presents the throughput of the servers when processing messages containing intvalues. The results of Bea Weblogic for both types of messages are very similar through wholetest. The throughput of BWS starts from 0,1 messages per milisecond. It increases as the numberof clients increases but starting from 25 clients for SOAP 1.1 messages the results are staying atthe same level of about 0,58 - 0,6 messages per ms. For 25 clients with SOAP 1.2 messages thethroughput is even worse than for 20 but from 30 the results return to the slight growth tendency.The throughput of BWS12 starting from 50 clients is better than of BWS11 which is better at theend for 100 clients. The throughput for 100 clients is about 6 times greater than for 1 client forboth types of messages.

The throughput of Internet Information Services starts at higher level than BWS. For SOAP1.1 messages it starts with 3,5 times greater value and for SOAP 1.2 messages – 2 times greaterthan the results of the same types of messages in BWS. However, the throughput of IIS increasesslower and for 3 clients the IIS12 becomes worse than BWS12, and for 10 clients – IIS11 worsethan BWS11. At the beginning the difference between IIS11 and IIS12 is quite big but decreasesand from 25 clients the results are very similar. The difference between the throughput for 100clients and 1 client is less for IIS than for BWS. This indicates that IIS for int type reaches his

44

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

20

40

60

80

100

120

140

160

180

int

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.1: Response times for messages containing int type

maximum throughput earlier than BWS. The throughput of IIS for small number of clients forSOAP 1.1 messages is closer to the maximum throughput than for SOAP 1.2 messages.

The difference between the servers from the point where they reach their constant throughputlevel is about 0,15 messages per ms with the advantage of BWS. The difference decreases and atthe end is about 0,05 messages per second with BWS still leading.

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

0,5

0,55

0,6

0,65

int

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.2: Server throughput for messages containing int type

45

7.1.2 double

Figure 7.3 shows how the response time differs when the number of clients sending requestswith double data type increases. The response times for SOAP 1.1 and SOAP 1.2 messages arevery close during the whole test and the biggest difference occurs only for 20 clients in Weblogicevaluation. However it is only a single event of such behaviour. The average difference betweentwo servers during the test is about 20 ms. Again Weblogic is the server which has quickerresponses during the test.

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

20

40

60

80

100

120

140

160

180

200

double

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.3: Response times for messages containing double type

The response times for messages containing the double data type are slightly worse than formessages containing int data type. This may be caused by longer messages to parse. Messagescontaining double values contain also longer xml tags (<double> tag is longer than <int> tag).The double values were also longer than int values when treating the value as a text, which it isdone when sending it in xml format. The average int value was 10 bytes long and the averagedouble value was 18 bytes long. The second reason is that the values were parsed and convertedfrom string to the proper data types in programming environments. It is faster to convert string toint than string to double.

The results of throughput test for messages containing doubles is presented in Figure 7.4. Theresults of both servers starts at the same level. From 2 clients IIS becomes better than BWS andthe advantage for SOAP 1.1 messages is more noticeable than for SOAP 1.2 messages. However,BWS throughput increases quicker and becomes better for 20 clients for SOAP 1.1 messages andfor 30 clients for SOAP 1.2 messages. The advantage of BWS is kept to the end of the test. Thethroughput of IIS for two types of messages is very similar through whole test. The differences aregreater for BWS. This time it is hard to determine where the constant throughput for the serversstarts. The throughputs of both servers increase through whole test but the changes for BWS aregreater.

7.1.3 object

Server response times for messages containing user defined data type are presented in Fig-ure 7.5. During the whole test the results are very similar for both IIS and Bea Weblogic. How-ever, it is noticeable that IIS respons slightly faster starting from 50 clients. The results of IIS

46

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

0,5

0,55

0,6

0,65

double

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.4: Server throughput for messages containing double type

for object data type are even better than for double data type which is quite interesting becauseobject data type is more complex and should last longer. Bea Weblogic times are worse than formessages with double data type which is understandable.

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

20

40

60

80

100

120

140

160

180

200

object

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.5: Response times for messages containing user defined type

Figure 7.6 presents the throughput of the servers. The results for two types of messages arevery similar for BWS through whole test and for IIS from 10 clients. For less than 10 clientsthe IIS results for two types of messages differ significanlty. At the range from 10 to 60 clientsthe results of both servers are similar. The IIS is has better throughput for the number of clientsless than 10 and greater than 70. At the point of 15 clients for IIS and 20 clients for BWS thethroughput stays at the same level slightly growing. The throughput of IIS at the beginning is

47

closer to the result at the end than in case of BWS. This is similar as in for int type and mayindicate than IIS reaches his maximum throughput faster than BWS also for messages containingobjects.

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

0,5

0,55

0,6

object

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.6: Server throughput for message containing user defined type

7.1.4 string

The tests with messages sending string data were performed for several lengths of the string.The length of the string started with zero characters and was increased by 100 characters up to1000 characters. In Figure 7.7 are presented results for string with 500 characters length andFigure 7.8 shows results for string with 1000 characters. I have also included charts that presentan overview of testing servers with messages containing string data. Figure 7.11 presents resultsfor Bea Weblogic Server and Figure 7.12 presents results for Internet Information Services.

For string with 500 characters the difference in performance between two tested servers iseasy to see. Bea Weblogic has better performance starting from very beginning and keeps thistendency through the whole test. The response times in the test are worse than in the precedingtests what is a normal tendency because message with 500 characters is longer than message withint or double and requires more time to process.

For strings with 1000 characters the advantage in performance of Bea Weblogic is kept. Thedifferences between IIS and Weblogic became greater than in 500 characters. This show that We-blogic handles messages with strings better than Internet Information Services and the degradationof Bea Weblogic Server is better.

Figure 7.9 and Figure 7.10 present how the throughput of the server changes when the numberof clients sending the requests increases. Bea Weblogic Server has better performance for bothlengths of the string. For string with 1000 characters the difference between BWS and IIS iseven greater than for string with 500 characters. The advantage for string with 500 charactersis about 0,1 – 0,15 messages per second and for 1000 characters – 0,15 to 0,25. The IIS hasvery similar results for both message types for string with 500 as well as 1000 characters. ForBWS the difference for string with 500 characters is quite small but is greater for string with 1000characters. In the second case the maximum difference is about 0,1 message per second.

In Figure 7.11 and Figure 7.12 I gathered results for all string lengths to create an overviewof how the response time changes when there is the same number of clients and the string length

48

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

20

40

60

80

100

120

140

160

180

200

220

string with 500 characters

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.7: Response times for messages containing string type with 500 characters

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

20

40

60

80

100

120

140

160

180

200

220

240

260

280

300

string with 1000 characters

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.8: Response times for messages containing string type with 1000 characters

changes. I decided to choose results for 5, 25, 50, 80 and 100 clients to keep the chart clear.Figure 7.11 presents the results for Bea Weblogic Server and Figure 7.12 for Internet InformationServices.

The response times of Bea Weblogic for 5, 25 and 50 clients are changing a little when thestring size is changing but this changes do not create any characteristic tendency but they arestaying on the same level. Only the result for the largest string size is going significantly up. Inthe case of 80 and 100 clients the changing tendency is observable. The response times for thesenumbers of clients are increasing as the string size increases. For 80 clients the response timefor the largest string is smaller than for preceding sizes nevertheless the tendency of growth is

49

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

0,5

0,55

0,6

string with 500 characters

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.9: Server throughput for message containing string type with 500 characters

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

0,5

0,55

string with 1000 characters

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.10: Server throughput for message containing string type with 1000 characters

present.In the IIS results chart the results of 5 clients are staying on the same level through whole test.

For the rest of client numbers the response times are increasing together with string size and forthe largest string size the response time differs significantly from the rest of results.

7.1.5 array of bytes

The tests with messages containing arrays of bytes were performed with varying sizes of thearrays. The array was empty in the beginning and was increasing until 10000 elements withinterval of 1000 elements. I included charts presenting results for messages with arrays of 1000

50

0 100 200 300 400 500 600 700 800 900 10000

20

40

60

80

100

120

140

160

180

200

220

string

Weblogic 5

Weblogic 25

Weblogic 50

Weblogic 80

Weblogic 100

string size

ms

Figure 7.11: Overview of Bea Weblogic Server performance when processing messages withstring data

and 10000 bytes and the charts that present an overview of the server behaviour when size of thearray changes.

The results presented in Figure 7.13 show that Bea Weblogic has quicker responses startingfrom 10 clients. This advantage is present through the rest of the test and for 100 clients comes to80 ms for SOAP 1.2 and to 75 ms for SOAP 1.1 messages. The IIS has very similar performancefor messages conforming to SOAP 1.1 and SOAP 1.2. The response times of BWS for SOAP 1.2messages become better starting from 60 clients and the difference is about 25 ms in the end ofthe test.

Now we can take a look at Figure 7.8 presenting response times for messages with string with1000 characters and Figure 7.13 presenting results for arrays with 1000 bytes. The response timefor maximum number of clients is at the same level both for IIS and BWS in this two tests andis about 280 ms for IIS and 200 ms for BWS. The results of BWS for string also split during thetest but in the end they come to one point. The results of these two tests are so similar becausethe representation of data is similar in an XML file. The string data is inserted into XML filebetween <string></string> tags and after opening an XML file is readable. The data from bytearray is transported within an XML file as a base64encoding. It means that the array of bytes isnot represented within an XML file as an array but as a stream of data. Every value from the arrayof bytes is not tagged with <byte></byte> but the whole array is inserted into an XML file as onevalue.

Figure 7.14 presents the results of response time test for messages containing array of byteswith 10000 elements. This time the IIS has better performance starting from 25 clients and thedifference is about 70 ms for maximum number of clients. This is interesting that IIS has worseperformance for array of 1000 bytes and is now better for 10000 bytes. It indicates that IIS hassmaller differences in response time when the size of an array containing bytes changes. Theoverview of how the response times change when the size of the array increases is presented inFigure 7.17 for Bea Weblogic Server and in Figure 7.18 for Internet Information Services.

Figure 7.15 and Figure 7.16 present the results of the throughput test of both servers. For bytearray with 1000 elements IIS starts with better throughput but from 10 clients becomes worsethan BWS. The advantage of BWS over IIS is about 0,1 (for 100 clients) to 0,2 (for 20, 25 clients)messages per second. The differences for two types of messages are easy noticeable for both

51

0 100 200 300 400 500 600 700 800 900 10000

25

50

75

100

125

150

175

200

225

250

275

300

string

IIS 5

IIS 25

IIS 50

IIS 80

IIS 100

string size

ms

Figure 7.12: Overview of Internet Information Services performance when processing messageswith string data

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

25

50

75

100

125

150

175

200

225

250

275

300

byte array, size 1000

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.13: Response times for messages containing byte array with 1000 bytes

servers. The differences are greater for BWS and are present through whole test. The biggestdifferences are for less than 10 clients. For IIS the differences are big at the beginning but from35 clients the results become very similar.

For 10000 bytes the difference between the servers are smaller than for 1000 bytes. The differ-ences between two types of messages are also smaller. In this case the IIS has better throughputthan BWS. The results are worse than for 1000 bytes because the data which is processed isgreater. For IIS the throughput for 10000 bytes is about 2 times worse than for 1000 bytes andfor BWS the throughput is about 3 times worse. It indicates that the performance of IIS decreases

52

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

50

100

150

200

250

300

350

400

450

500

550

600

650

byte array, size 10000

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.14: Response times for messages containing byte array with 10000 bytes

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

0,5

byte array, size 1000

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.15: Server throughput for messages containing byte array with 1000 bytes

slower than the performance of BWS when the size of an array with bytes increases.In Figures 7.17 and 7.18 there are presented overviews of both server behaviours when the

size of arrays is changing for the same number of clients. Similarly to the string results I presentthe results for 5, 25, 50, 80 and 100 clients for the same reason (chart clearness).

In both figures the response times are significantly changing when the size of array increases.The figures explain how it happened that the response times for IIS were worse than the results ofBWS for array of 1000 bytes and became better for array of 10000 bytes. The results of BWS arestarting from lower positions than the results of IIS. For array of 2000 BWS the results becomevery similar and from this point the results of IIS are becoming better than BWS. For the largest

53

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,02

0,04

0,06

0,08

0,1

0,12

0,14

0,16

0,18

0,2

byte array, size 10000

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.16: Server throughput for messages containing byte array with 10000 bytes

0 500 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000

50

100

150

200

250

300

350

400

450

500

550

600

650

byte array

Weblogic 5

Weblogic 25

Weblogic 50

Weblogic 80

Weblogic 100

byte array size

ms

Figure 7.17: Overview of Bea Weblogic Server performance when processing messages contain-ing arrays of bytes

array IIS has 1000 ms advantage for 100 clients, 70 ms – for 80 clients and 40 ms for 50 clients.The differences for 5 and 25 clients are not so significant but are noticeable though.

The behaviour of the servers indicates that IIS has better degradation than BWS for data sentas array of bytes. Table 7.1 presents the degredation of both servers. The table is divided intotwo parts. The first (upper) part presents the average differences in ms between responses whenthe size of the array changes. The second (lower) part presents the percentage difference betweenresponses when the size of the array changes. The values in the first part are lesser for IIS than forBWS for all numbers of clients. In the second part the IIS has also lesser values than BWS. This

54

0 500 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000

50

100

150

200

250

300

350

400

450

500

550

600

byte array

IIS 5

IIS 25

IIS 50

IIS 80

IIS 100

byte array size

ms

Figure 7.18: Overview of Internet Information Services performance when processing messagescontaining arrays of bytes

explains why the IIS had worse response time than BWS at the beginning of the test and finishedwith better response time than BWS at the end of the test. The lesser values for IIS shows that itloses performance slower than BWS.

Table 7.1: Differences in response times when the size of array changesClients 5 25 50 80 100

ServerBWS 5,27 13,36 25,09 38,64 48,18IIS 3,91 9,64 19 30,27 39,91

BWS % 20,85 15,19 13,22 13,8 14,41IIS % 13,88 9,05 8,87 11,12 11,49

7.1.6 array of ints

This test was performed with arrays containing int values. The size of arrays was changingduring the test from 0 to 10000 elements with interval of 1000. I included the results for the arrayof 1000 elements and the overview of behaviour of both servers when the size of array changedfor the same number of clients.

Figure 7.19 presents the response time for an array of 1000 elements. It is very easy to seethat there is a big gap between the results of the servers. The results of IIS are far better than theresults of BWS through whole test. The results of BWS are multiple of the results of IIS withthe factor 2.5. The difference between the response time of two types messages (SOAP 1.1 andSOAP 1.2) is greater for BWS than for IIS. For both servers the messages conforming to SOAP1.1 are responsed quicker than SOAP 1.2 messages.

The response times for arrays of ints are about 5 times longer than for ararys of bytes for IISand about 9 times longer for BWS. This is because the messages containing these types of dataare differently build. As I wrote in Subsection 7.1.5 the array of bytes is inserted into XML fileas a stream of data not as an array. The array containing int values is treated differently. It is

55

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

250

500

750

1000

1250

1500

1750

2000

2250

2500

2750

int array, size 1000

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.19: Response times for messages containing int array with 1000 elements

inserted into XML file as an array with all necessary structures required to create proper XMLstructure. Every int value form an array is tagged with <int></int> what produces quite largepayload. The int values in tested arrays were greater than byte values from byte array what hadalso effect in larger transported messages (see listings and explanations in Section 7.2). Largermessages required longer time to parse what significantly affected the response times and serverthroughput.

The reason why the response times of BWS are so much worse than of IIS lays in the mannerhow the parametres are passed to the web method. This is explained in Subsection 6.2.2 where Iexplained how the web methods are invoked.

As the results of the response times the results of server throughput (see Figure 7.20) are alsobetter for IIS than for BWS. For 1 client the IIS is 4 times quicker for SOAP 1.1 messages and3.5 times quicker for SOAP 1.2 messages. The difference is then decreasing and comes to 2.5for 15 clients and is on this level to the end of the test. The difference in performance for twotypes of messages is greater for IIS especially for the number of clients less than 10. BWS resultsare very similar through whole test. However both servers perform better (sometimes slightly)for messages conforming to SOAP 1.1. The maximum throughput is reached by IIS processingSOAP 1.1 already for 2 clients and for 10 clients for SOAP 1.2 messages. BWS reaches maximumthroughput for 15 clients. Charts of both servers are very gently. The throughput for 100 clients is2 times greater for BWS and about 1,3 times – for IIS. This shows that the data which is processedcauses high load on the server even for small number of clients.

Figure 7.21 and Figure 7.22 present the overviews of both servers. The tendency of the serverslooks similar but this is caused by different scales of the Y axis. If the Y axis for IIS would bescaled the same as for BWS then the lines on the chart presenting the results of IIS would goup more gently. The Y axis for BWS has maximum in 15000 and the Y axis for IIS in 5000.This suggests that IIS has response times 3 times faster than BWS. The response time for eachnumber of clients is about 3-3,5 times longer for BWS than for IIS. This is a big difference butit results from the way the parameteres are passed to web methods in BWS. It was explained inSubsection 6.2.2.

56

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

0,01

0,02

0,03

0,04

0,05

0,06

0,07

0,08

0,09

0,1

0,11

int array, size 1000

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.20: Server throughput for messages containing int array with 1000 elements

0 500 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

11000

12000

13000

14000

15000

int array

Weblogic 5

Weblogic 25

Weblogic 50

Weblogic 80

Weblogic 100

int array size

ms

Figure 7.21: Overview of Bea Weblogic Server performance when processing messages contain-ing arrays of ints

7.1.7 array of doubles

In this test I used messages containing arrays of doubles. The size of arrays was changingfrom 0 to 10000 elements with 1000 elements interval. The results of response times and servertoughput are presented for arrays of 1000 elements. There is also included a figure presentinghow the response times of the server change for 5, 25, 50, 80 and 100 clients when the size of thedouble array increases.

Figure 7.23 presents the results of response time test. IIS has very big advantage over BWS,

57

0 500 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

int array

IIS 5

IIS 25

IIS 50

IIS 80

IIS 100

int array size

ms

Figure 7.22: Overview of Internet Information Services performance when processing messagescontaining arrays of ints

IIS response times are about 3,5 times quicker than the response times of BWS. The differencesin processing SOAP 1.1 and SOAP 1.2 messages are bigger in BWS results. For both servers themessages conforming to SOAP 1.1 are processed quicker than SOAP 1.2 messages. The reasonwhy the response times of BWS are so much worse than the respnse times of IIS is the same as inthe int array test and was explained in Subsection 6.2.2.

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

5500

double array, size 1000

BWS11

BWS12

IIS11

IIS12

n. of clients

ms

Figure 7.23: Response times for messages containing double array with 1000 elements

The response times for double array are worse than for byte array and int array. The responsetimes for arrays containing doubles are 2 times worse than for arrays containing ints in case of

58

BWS and about 1,5 worse in case of IIS. The response time in this test are about 10 times worsethan for byte arrays for BWS and 6 times worse for IIS. They are worse than byte array becausethe data of double array and byte array is differently inserted into XML file before sending. Thebyte array is inserted into XML file as a stream of data and array of doubles as an array. Thedouble array in XML file has a great payload because every double value has to be tagged with<double></double>. The double values used in the test were also longer than byte and int valuesin preceding tests. This results in larger messages and requires more time to process the messagecontaining the array of doubles than the array of ints.

Similar as for the arrays of ints the reason why the results of response times of BWS are worsethan IIS is explained in Subsection 6.2.2. There is described how the web methods are invoked.

In figure presenting results of server throughput test (Figure 7.24) the result of IIS for SOAP1.1 messages for 1 client is over 2 times better and for SOAP 1.2 messages over 2,5 better than theresult of BWS for the same message types. For 2 clients the IIS is 4 and 5 times better respectivelyand this is the biggest advantage of IIS over BWS. For 20 clients the advantage comes to 3 timesand is at this level to the end of the test. The results of two types of messages are almost the samefor BWS and differ significanlty for IIS especially for the number of clients less than 30. Thethroughputs of the servers are about 2 times worse than for messages containing arrays of ints.

1 2 3 4 5 10 15 20 25 30 35 40 45 50 60 70 80 90 1000,010

0,015

0,020

0,025

0,030

0,035

0,040

0,045

0,050

0,055

0,060

0,065

0,070

double array, size 1000

BWS11

BWS12

IIS11

IIS12

n. of clients

requ

ests

/ms

Figure 7.24: Server throughput for messages containing double array with 1000 elements

In Figure 7.25 and Figure 7.26 are presented overviews of the behaviour of the servers whenthe size of the array of bytes increases. The tendency is similar as for arrays of ints but this timethe maximum value of Y axis is 4 times greater for BWS than for IIS. Results for 50 and moreclients are 4 times worse for BWS than for IIS. The interesting thing is for 25 clients where theresponse time for BWS is about 2,5 times longer than for 5 clients, the response time for IIS isabout 6 times longer than for 5 clients. The relations between other numbers of clients are similarfor both servers.

59

0 500 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000

2500

5000

7500

10000

12500

15000

17500

20000

22500

25000

27500

30000

double array

Weblogic 5

Weblogic 25

Weblogic 50

Weblogic 80

Weblogic 100

double array size

ms

Figure 7.25: Overview of Bea Weblogic Server performance when processing messages contain-ing arrays of doubles

0 500 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

5500

6000

6500

7000

7500

double array

IIS 5

IIS 25

IIS 50

IIS 80

IIS 100

double array size

ms

Figure 7.26: Overview of Internet Information Services performance when processing messagescontaining arrays of doubles

60

7.2 Network Traffic

In this section there are presented results of monitoring the network while the web methodswere invoked. I included the charts presenting the overhead and the payload parts in a transportedmessage. There are also included some listings presenting parts of messages for better explana-tion. In listings I used SOAP 1.2 messages sent while invoking web methods on Bea WeblogicServer. I chose only one type of message for only one server because the messages are almostthe same. The SOAP 1.1 and SOAP 1.2 messages sent by one of the servers vary only in the partdetermining usage of proper soap envelope. SOAP 1.1 messages refer to other namespace thanSOAP 1.2 messages. The overhead difference results from the length of the URI for the names-pace. The namespace used in SOAP 1.1 messages is “http://schemas.xmlsoap.org/soap/envelope/”and in SOAP 1.2 messages: “http://www.w3.org/2003/05/soap-envelope”. The namespace usedin SOAP 1.1 message is 2 bytes longer so these messages have 2 bytes more overhead for thesame web method than SOAP 1.2 messages.

The messages sent between clients and Bea Weblogic Server has only one namespace insertedwhich determines the type of message used. The message sent in Internet Information Servicesenvironment has three namespaces inserted. First determining the type of message which is thesame as for BWS. Second and third namespaces refer to XML schemas which the message con-forms to. These two namespaces are the same for SOAP 1.1 and SOAP 1.2 messages in IIS andcause that the overhead of messages for this server is greater than in BWS.

The Listing 7.1 presents a skeleton of a SOAP 1.2 message sent to the Bea Weblogic Server.The message contains always the SOAP Header element even if it is empty as in this listing. Thechild elements of the SOAP Body element are namespace qualified.

<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header/><soapenv:Body>

<m:MethodName xmlns:m="http://testing.org"><m:value>Value passed to the web method as a parameter

</m:value></m:MethodName>

</soapenv:Body></soapenv:Envelope>

Listing 7.1: The skeleton of a SOAP 1.2 message sent to the Bea Weblogic server

In the Listing 7.2 there is presented a skeleton of a SOAP 1.2 message used when invokinga web method on Internet Information Services. There are two additional namespaces at thebeginning of the file that were not present in message sent to BWS. The message does not containSOAP Header element if it is empty. The child elements of the SOAP Body element are notnamespace qualified.

Analysing the listings for BWS and IIS messages we can find a regularity of how the sizeof message vary when invoking different web methods and sending different payload. There isconstant part of the message in both cases that never changes. This part for BWS has 196 bytesand for IIS – 265 bytes, the rest depends on web method name length and length of a transportedvalue. The constant never changing part and the name of the method create the overhead of themessage. We can write a formula for calculating the size of messages:

Msize = Moverhead + Mpayload

where

Moverhead = Serverspecificconstantvalue + 2 ∗ Length (MethodName)

61

<soap:Envelopexmlns:soap="http://www.w3.org/2003/05/soap-envelope"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body>

<MethodName xmlns="http://localhost/FirstService/"><value>Value passed to the web method as a parameter

</value></MethodName>

</soap:Body></soap:Envelope>

Listing 7.2: The skeleton of a SOAP 1.2 message sent to the Internet Information Services

The name of the web method is multiplied by 2 because it is used twice in the message, oncein opening and once in closing tag. After inserting appropriate values for each server we getformulas for calculating the size of messages used in both servers. Formula 7.1 is adequate formessages sent to BWS and Formula 7.2 – for IIS.

Msize = (196 + 2 ∗ Length (MethodName))overhead + (Length (V alue))payload (7.1)

Msize = (265 + 2 ∗ Length (MethodName))overhead + (Length (V alue))payload (7.2)

After determining which method is invoked we can replace MethodName variable with con-crete method name. After calculating length and making rest of available operation we get to thepoint where the formula depends only on Value variable. In this situation the number that wehave in the formula is a constant overhead value for particular method name. For example if themethod name is “echoInt” and we use Formula 7.1 we will get:

Msize = 196 + 2 ∗ Length (echoInt) + Length (V alue) = 196 + 2 ∗ 7 + Length (V alue)

Msize = 210 + Length (V alue)

The last formula depends only on the length of Value variable. The constant overhead value forechoInt method is 210 bytes. Similarly we can determine the constant overhead values for othermethod names for BWS. To determine constant overhead values for IIS we use Formula 7.2.

When describing the structures and sizes of messages in the following subsections I will useSOAP 1.2 messages sent to BWS unless the other messages have significant differences.

7.2.1 int, double

I present int and doule in one section because the messages with payload of these typesare almost the same, only name of the web method is different. In case of int the name ofthe web method is echoInt as presented in Listing 7.3) and the int parameter is passed within<m:value></m:value> tags. In case of double the name changes to echoDouble (see Listing 7.4and the parameter within value tags is a double value.

The overhead for messages invoking echoInt method was calculated at the beginning of thissection and is 210 bytes. The overhead for echoDouble method we will calculate using For-mula 7.1.

Moverhead = 196 + 2 ∗ Length (echoDouble) = 216

The overhead for echoDouble method is 216 bytes. In presented listings the int value has lengthof 11 bytes what makes 5% of whole message. The double value is longer and has 19 bytes and

62

<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header/><soapenv:Body>

<m:echoInt xmlns:m="http://testing.org"><m:value>-2128954131</m:value>

</m:echoInt></soapenv:Body>

</soapenv:Envelope>

Listing 7.3: The SOAP 1.2 message invoking echoInt method with int value as parameter...

<m:echoDouble xmlns:m="http://testing.org"><m:value>0.22777210150770255</m:value>

</m:echoDouble>...

Listing 7.4: Changes in message when invoking echoDouble method and sending double valueinstead of int

it is 8% of the message. The values in Table 7.2 present what part of a message is made frompayload if the payload length is the same as in listings presented in this subsection.

The values for the same type of payload and for the same server but for different messagetypes are very small. It could not be differently because there is only 2 bytes of difference inoverhead between SOAP 1.1 and SOAP 1.2 messages.

The percentage part of a message which constitutes the payload part in case of int and doubletypes depends on the length of the int or double value. In Table 7.2 this part is about 5 and 8percent. However if we use greater values that are longer then the percentage value will increase.Figure 7.27 presents how the percentage content of payload part in a message changes when thevalue becomes longer and longer. In the first part of the chart there are results for the value lengthfrom 1 to 400. For the length of 400 the message contains payload in 65 percents. The jump isin place where length changes from 400 to 1800. I created the chart with this jump to show thatit is possible that the message containing int or double value may consist in over 90 percents ofpayload. However I did it only experimentaly because I do not think that such long int or doublesare sent. I think that int and double values in messages mostly have lengths as in listings presentedat the beginning of this subsection.

7.2.2 object

For user defined payload type the structure of the message changes (see Listing 7.5). Inmessages sent to BWS appears an extra namespace which was always present in messages sent toIIS. The namespace refers to an XML Schema which is necessary to use a “nil” attribute. In theBody element there are used two namespaces. The first is the default namespace of the web service(“http://testing.org”) and it contains the name of user defined type userClass. Inside the objectthere is used another namespace where the structure of the object is defined. This namespacerefers to the java package where the object is implemented (“testing.webservices.test”). In one ofthe object properties the nil attribute set to true is present. It indicates that this property was not

Table 7.2: Percentage part of message that contains payloadServer BWS11 BWS12 IIS11 IIS12

payloadint 4,93 4,98 3,77 3,79double 8,02 8,08 6,38 6,42

63

1 100200 300400500600700800900 1100 1300 1500 1700 1900 2100 2300 25000,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

overhead

payload

length of the value

Figure 7.27: Percentage content of payload and overhead in the message

defined and it matches java null value.Due to the change of the message structure the Formula 7.1 cannot be used. The overhead is

greater than for int and double values because the additional namespace is used and every propertywithin the object refers to java package. The overhead for the object is 504 bytes if there is nonull value. With null value, as in listing, there is no closing tab for the property so the overheadis less. After calculating the overhead it is constant and the size of the messages will depend onlyon the length of particular property of the object. So the relationship is the same as for int anddouble values. The percentage content of payload in message for Number of length 11 and twostrings (FirstName and LastName) of length 15 each will be 8%. The percentage payload contentwill reach 90% when the overall length of values is 4500. It is more than for int and double where2000 was enough.

7.2.3 string

Messages containing string payload have the same structure as for int and double (see List-ing 7.6). The overhead can be calculated using Formula 7.1 and we get 216 bytes of overhead.The overhead is the same as for double because the lengths of the web methods are the same andthere are no other differences in the message structure.

The test was performed for different sizes of string from 100 to 10000 characters with aninterval of 100. Figure 7.28 presents the size of payload and overhead when the string length isincreased. The chart on the figure is stacked what means that the overhead is put on the payloadand they together make the size of the message. As shown on the chart the overhead does notchange and the size of the message changes only if the length of string changes. The relationbetween size of the message and size of the payload part is linear. It fulfils the formula for liney = ax + b In this case the overhead is the constant b, the size of payload part is x, and the sizeof the message is y. The a factor is equal to 1.

Figure 7.29 what is the percentage content of payload and overhead in the message when thelength of string increases. The relation is the same as for int and double and it reaches 90% alsowhen length of the value comes to 2000.

64

<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Header/><soapenv:Body>

<m:echoUserClass xmlns:m="http://testing.org"><m:userClass><java:Numberxmlns:java="java:testing.webservices.test">1

</java:Number><java:FirstNamexmlns:java="java:testing.webservices.test"xsi:nil="true"/><java:LastNamexmlns:java="java:testing.webservices.test">A_Lastname

</java:LastName></m:userClass>

</m:echoUserClass></soapenv:Body>

</soapenv:Envelope>

Listing 7.5: Structure of the message containing user defined payload type

<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header/><soapenv:Body>

<m:echoString xmlns:m="http://testing.org"><m:value>CVDGUSORZKAXBFHRNV...XQJPDYVSMNNPMGASDNBVSD

</m:value></m:echoString>

</soapenv:Body></soapenv:Envelope>

Listing 7.6: Message containing string payload and invoking echoString web method

7.2.4 array of bytes

For array of bytes the message structure looks the same as for string, int and double (seeListing 7.7). Using the Formula 7.1 we calculate the size of overhead which is constatnt for thistype of payload. The overhead is 222 bytes. The payload inserted into the message does not havea structure typical for arrays in XML files. The array of bytes is inserted into an XML file asa stream of bytes. Each value from the array is not tagged with opening and closing tag but thevalues are “put” one after another. When the XML file containing array of bytes is opened it looksas a string because bytes placed one by one create some values that are interpreted as ASCII codesand displayed as characters.

The size of the message is directly proportional to the size of payload part and the chartpresenting how the size of message changes when the size of payload part changes would lookthe same as for string so I did not include it. Due to the same reason I did not include chartpresenting percentage content of payload and overhead parts in the message.

65

0 200 400 600 800 1100 1400 1700 2000 2300 2600 2900 3200 3500 3800 4100 4400 4700 50000

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

5500

string

overhead

payload

Figure 7.28: payload and overhead sizes in a message containing string

0 200400 600800 1100 1400 1700 2000 2300 2600 2900 3200 3500 3800 4100 4400 4700 50000,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

string

overhead

payload

Figure 7.29: The percentage content of payload and overhead in a message containing string

7.2.5 array of ints and doubles

The message containing array of ints or doubles has different structure in the value part (seeListing 7.8 and Listing 7.9). The array of ints and doubles is inserted into XML file as an ar-ray with all necessary tags and structures. Every int or double item from an array is taggedwith <int></int> or <double></double> respectively. This tags for each item create additionaloverhead inside the value part. Unlike the preceding types here the overhead is not constant butincreases with every additional item in the array.

To calculate overhead of the messages containing array of ints or doubles we have to modify

66

<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header/><soapenv:Body>

<m:echoByteArrayxmlns:m="http://testing.org"><m:value>

zbrKQLChWpaYVFR...N75y7jG+mtio8LYvtEx8tP8A=</m:value>

</m:echoByteArray></soapenv:Body>

</soapenv:Envelope>

Listing 7.7: Message containing payload from byte array and invoking echoByteArray webmethod

the Formulas 7.1 and 7.2. The modification applies to the value part of the formulas (Length (V alue))because for other tested payload types the value part consisted only from payload and here the pay-load is mixed with overhead. Therefore this part of the formulas has to be divided into two parts.One counting the overhead inside value part of the message and the second counting payload. Theoverhead is the sum of length of the tags around each item from the array. It can be written asFormula 7.3. The size of payload is the sum of length of each item from the array (Formula 7.4)

Overhead (V alue) =arraylength∑

i=1

Length (Tags) (7.3)

Payload (V alue) =arraylength∑

i=1

Length (array[i]) (7.4)

In Formula 7.4 I used the convention from programming languages for getting an item fromthe array. However I assumed that items in an array are counted from 1 not from 0. Now I canwrite the formulas for counting whole message size for Bea Weblogic (Formula 7.5) and InternetInformation Services (Formula 7.6).

Msize = 196+2∗Length (MethodName)+arraylength∑

i=1

(Length (Tags) + Length (array[i]))

(7.5)

Msize = 265+2∗Length (MethodName)+arraylength∑

i=1

(Length (Tags) + Length (array[i]))

(7.6)For message containing array of ints sent to BWS the overhead for each item from the array

is 15 bytes. After inserting this number and counting the overhead using Formula 7.5 for an arraywith 1000 elements we get:

Msize = 196 + 2 ∗ 12 +1000∑i=1

(15 + Length (array[i]))

Msize = 220 + 15000 +1000∑i=1

Length (array[i]) = 15220 +1000∑i=1

Length (array[i])

67

The overhead in the message with array of 1000 ints is 15220 bytes. Now I count the size ofpayload inside that message assuming that average length of the int is 10 bytes.

Mpayload =1000∑i=1

10 = 10000

The size of payload is 10000 bytes what equals to 40% of the message. The percentage content ofpayload strongly depends on the length of particular items in the arrays. For example, if averagelength of item in an array is 2 bytes the percentage content of payload will be only 12% and foraverage length of 8 bytes – 34%.

<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header/><soapenv:Body>

<m:echoIntArray xmlns:m="http://testing.org"><m:value><m:int>1536278833</m:int><m:int>1398410729</m:int>...<m:int>-1728741910</m:int><m:int>-333230690</m:int>

</m:value></m:echoIntArray>

</soapenv:Body></soapenv:Envelope>

Listing 7.8: Message containing array of ints and invoking echoIntArray web method

The overhead in the message containing array of doubles is greater than for message contain-ing array of ints due to longer tags around each item from the array. The length of tags for eachitem is 21 bytes. Using the Formula 7.5 I calculated the overhead for array of 1000 elements andit is 21226 bytes. The size of payload for this array for average length of item in the array of 10bytes is 32%. The percentage content of payload for average item length of 2 bytes would be 9%and for average length of 8 bytes – 27%. The results are lower than for the same average sizes ofitems in the array of ints due to longer tags that create greater overhead....

<m:echoDoubleArray xmlns:m="http://testing.org"><m:value><m:double>0.4075427369381309</m:double><m:double>0.8264754423392978</m:double>...<m:double>0.5199761152646059</m:double><m:double>0.04911040208540507</m:double>

</m:value></m:echoDoubleArray>

...

Listing 7.9: Message containing array of doubles and invoking echoDoubleArray web method

Figure 7.30 presents the relations between the number of items in an array of ints and the sizeof the message, and particular parts of the message. It is assumed that the average size of the itemin the array is 10 bytes. Both overhead part and payload part are increasing when the number ofitems in the array increases. The size of the message is growing much faster than for string andarray of bytes where the overhead was constant regardless the number of items (characters) in thearray (string).

68

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000

25000

50000

75000

100000

125000

150000

175000

200000

225000

250000

275000

overhead

payload

Figure 7.30: Changes of the message size when the array of ints increases

Figure 7.31 presents how the percentage content of payload and overhead parts in the messagechanges when the number of items in the array increases. The chart is made for average size of10 bytes of an item in the array. For empty array there is no payload so the percentage contentof the payload part is 0%. For the array of 10 elements the payload part is about 22%, for 50elements – 36% and grows up to 38% for 250 elements. The next point on the chart is for 500elements and the percentage content of payload is about 40%. Through the rest of the chart thepercentage content of payload is at the same level with slight differences around 1%. It is becausethe overhead in the message changes proportionaly to the number of items in the array. Forparticular average length of the item in the array the percentage content of payload in the messageis always the same.

I did not include charts for messages containing array of doubles because the tendency onthe charts is the same as for messages containing array of ints. The only difference in the chartpresenting the size of the messages would be that the overhead grows faster for messages witharray of doubles. In the chart presenting the percentage participation of the payload and overheadpart the level of the line would be lower for the same average size of items in the array becausethe overhead for double items is greater than for int values.

7.3 Server resources requirements

In this section there are presented results of server resources evaluation. The tested resourceswere: memory, CPU and network traffic. In the memory evaluation the number of availablememory megabytes was monitored while the server was getting and processing requests. Alsonetwork traffic and CPU were monitored in the same manner. The network traffic evaluationshows how many bytes were transmitted through the network by the client and the server. Theservers bahaved similarily so I decided to include only results of Bea Weblogic processing SOAP1.2 messages. The results for two types of messages were also very similar so only one type ispresented. The results are presented on charts which were made in Windows performance monitortool. The charts are in colours and all are kept in the same convention. Red color presents thememory usage, blue – processor usage, and green – network traffic. On every chart there is appliedthe same scale for the results. The memory usage is presented with scale 0,1 (e.g. 30 on the chartmeanse 300 megabytes), the network traffic – scale 0,00001 (30 on the chart means 3000000 bytes

69

0 10 20 50 100 250 500 1000 2000 3000 4000 5000 6000 7000 8000 9000 100000,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

overhead

payload

Figure 7.31: The percentage content of payload and overhead in a message containing array ofints

what is about 3 megabytes), and the processor usage – with scale 1.

7.3.1 simple type

Figure 7.32 present the results for messages containing simple data type. These are results forint but the results for double were almost the same so the results of one data type should give anoverview of the server behaviour. The memory usage is staying at the same level through wholetest regardless the number of clients sending requests. The network usage and proccesor time areincreasing as the number of clients increases. The maximum network traffic is not greater than1000000 bytes (about 1 megabyte). Starting from 20 clients, the processor usage reaches 100%.

Figure 7.32: Results for simple type

7.3.2 string

The results of evaluation of the server resources usage when processing strings are presentedin Figure 7.33. In the evaluation the string with 1000 characters was used.

70

The memory usage stays at the same level similar as for simple types. The network trafficis greater than for simple types because the messages carry more payload. The maximum trafficcomes to 2000000 bytes (about 2 megabytes). The processor usage reaches high level later thanfor simple types. It may be because for string the server only needs to read the data from xml file,and for int or double it needs to do additionally type casting.

Figure 7.33: Results for string with 1000 characters

7.3.3 array of bytes

For arrays of bytes I included results of two array sizes, 1000 elements and 10000 elements,to show how the usage of the resources on the server differs for varying amount of data trans-fered. Figure 7.34 presents the resources usage for messages containing arrays of bytes with 1000elements, and Figure 7.35 – with 10000 elements.

In both cases the memory usage stays at the same level through whole test. The network trafficfor arrays with 1000 elements is similar to string with 1000 characters and is in maximum about2000000 bytes (2 megabytes). The processor usage for array with 1000 elements is at lower levelthan for string with 1000 elements. I think it is because the server treats the payload within themessage as a stream of bytes and does not cast it to a particular type.

For arrays of bytes with 10000 elements the processor usage starts to be at the high level verysoon. The server has to parse and stream big messages. The network traffic increased significantlyfrom the level where it was for arrays with 1000 elements. Now the network traffic comes to about5 megabytes (5000000 bytes).

Figure 7.34: Results for byte array with 1000 elements

It is worth noticing that memory usage in all the tests is staying at the same level. It may meanthat the server reserves some memory at the moment when it starts and then does not requireadditional resources. The need of additional resources is not visible in the tests I performed.

71

Figure 7.35: Results for byte array with 10000 elements

However, it is possible that for very large number of clients the server will have to use morememory.

72

Chapter 8

Related Work

In this chapter I compare the results of my experiments to the results found by other re-searchers [30–34]. In the article [30] the authors are comparing several implementations of SOAPand other methods of web services invocation: JavaRMI, SoapRMI, SOAP:Lite, Microsoft SOAPToolkit, Apache SOAP, CORBA. The most interesting implementations are Microsoft SOAPToolkit which is used with Internet Information Services as the server, and Apache SOAP withApache Tomcat used as the server. The authors implemented three methods similar to my echoInt,echoString and echoIntArray. They performed the tests running client and server on the same hostand on separate machines. I only made the experiments for separate computers because I wantedto simulate the real environment of web services. The authors measured only latency, I measuredadditionaly the servers throughput and size of messages transported between clients and servers.Relations between the latency results of both servers are similar to my results.

In [31] author presents another apporach to present data in XML format. This is Table DrivenXML which serialize the data into tabular format. The author measured latency, network trafficand server throughput for normal XML and TDXML, and compared the results. The experimentwas done with web services implemented in C# and deployed on IIS and a client implemented inC#. The results are generaly better for TDXML.

The article [32] presents the experiments for three popular web servers. The authors measuremessage sizes, latency, throughput and time spent on serialization and deserialization. They eval-uated the same aspects as I. However, they do not provide the names of the servers but call theservers: Product A, Product B, Product C. This makes the evaluation only an overview of what ison the market. The evaluation does not provide information how the performance of a particularserver relates to another.

In the master thesis [33] the authors are evaluating different middlewares for distrbuted ob-jects. The middlewares are: CORBA, RMI, RMI-IIOP, DCOM, .NET Remoting. The most rele-vant technology to my work is .NET Remoting using HTTP which uses SOAP to communicate.The authors measure network traffic, latency and throughput same as I. Additionaly I did the eval-uation of the resources that server uses during processing the messages. The tendencies in theresults got by the authors are similar to these that I got.

The article [34] presents the evaluation in terms of message size, latency and throughputof different protocols. The protocols are: SOAP, CDR and FIX. The tendencies in the resultspresented in the article are similar to the results I presented in my thesis. The authors presentCompact XMl Tags and compare it to SOAP. The compact tags reduce message size and seem toimprove the performance by reducing the time needed to decode the message.

The documents [30] and [33] include results for other technologies than SOAP. The technolo-gies are RMI (Remote Method Invocation) used in Java and CORBA (Common Object RequestBroker Architecture). The messages size for primitive types is about 4 times smaller for CORBAand 2 times smaller for RMI than for SOAP. For arrays the SOAP messages are about 10 timeslonger than in RMI or CORBA. The response times are about 5 to 10 times worse when usingprimitive types and even about 100 worse when using arrays in SOAP than in RMI or CORBA.

73

Chapter 9

Further Development Tendencies

Web services make it easier and more productive to build connected interoperable applica-tions. The development of Web services is quite easy today but it is necessary to go beyondsimple and relatively synchronous applications. To solve more complex integration problemscritical for the buisiness, the extensions of SOAP messages are needed. The extensions shouldguarantee message delivery, eliminate message duplication and enable message ordering . TheWeb services should converse in an asynchronous manner [35]. The answer for these needs isa new standard Web Services Reliable Messaging (WS-RM). The standard provides an essentialguarantee that a message sent by the sender is delivered to the receiver and delivered only once.The WS-RM ensures also that when messages are sent in a specific order they will be deliveredin the correct order.

Every potential XML application’s use may be extended via messaging with mechanismsprovided by SOAP [36]. This mechanisms are used very rarely because the common use ofRPC. Web service can be composed with SOAP but without RPC. [36] presents several examplesof interesting SOAP usage. The SOAP envelope may contain an XSLT transform what gives amechanism to perform the XML transformation on a remote machine. A SOAP message mayalso contain a VML (Vector Markup Language) document what could be used to insert graphicalelements into a diagram that exists on another machine. There are many other possibilities thathave to be discovered to truly benefit from SOAP and Web services.

In [37] author presents Semantic Web as the next generation of Web architecture. The objec-tive of Semantic Web Architecture is to provide a knowledge representation of linked data in orderto allow machine processing on a global scale [37]. The semantic web is a vision of informationthat is understandable by computers to allow them perform the tasks without human directions.For Semantic Web services the markup language must be descriptive enough to allow computer toautomatically determine its meaning. The author states that WSDL and UDDI are ideally suitedto be implemented using Semantic Web technology and SOAP could use Resource DescriptionFramework (RDF) and be a foundation for Semantic Web Services.

9.1 Security Considerations

Security is a fundamental aspect of computer systems especially in distributed environmentlike Web services. Security should be robust, effective and flexible enough to support securitypolicies required by different organizations. The Web services may use transport-level securitysuch as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). However, these mecha-nisms support security for point-to-point messaging. When intermediaries are present, the ulti-mate receiver must trust these intermediaries to provide end-to-end security because the messageis transported through the intermediaries with point-to-point security. End-to-end security mustbe provided if the communicating endpoints do not trust the intermediaries. The end-to-end secu-rity is also better than point-to-point transport-level security because it supports loosely coupled,multi transform, and extensible environment of SOAP-based Web services [16].

74

Web services security is complex and requires new mechanisms to satisfy the SOAP-basedmessaging. New mechanisms use existing approaches such as security tokens, public key encryp-tion, X.509 cerificates and others. New mechanism were necessary only to adopt these existingsolutions to SOAP and are designed in extensibility in mind to allow adopting new apporaches inthe future. WS-Security is one of the mechanisms. It allows to selectively encrypt the parts ofmessages. For example, this allows firewalls to inspect the unencrypted portion [38]. Since WSSoperates at the SOAP layer, it can travel with the message throughout the network and even persistwhen the message is queued or stored.

Web services security is based on the requirement that incoming messages prove a set ofassertions made about a sender, a service or other resource [16]. In WSS these assertions areencoded in security tokens wrapped in XML. WSS uses also signatures to verify message originand integrity. Signatures are also used by message producers to demonstrate knowledge of thekey, typically form a third party [39].

A message content should be protected from being disclosed (confidentiality) or modifiedwithout detection (integrity). Message integrity is provided by XML Signature in conjuction withsecurity tokens to ensure that modifications to message are detected. Message confidentiality isensured by XML Encryption in conjuction with security tokens to keep portion of SOAP messageconfidential [39].

WSS uses the XML Signature and XML Encryption standards. WSS inserts a Securiy XMLelements into the SOAP header. This contains all the information about authentification, digitalsignatures, and encryption that are applied to the message [38]. With this information the receiveris able to decrypt and validate the message. The keys and authorization information may bespecified using X.509 certificates, Kerberos tickets, SAML assertions (Security Assertion MarkupLanguage), XML-based tokens or simple passwords.

Example 9.1 present the SOAP message with Security header. There can be more than one se-curity header and each may be targeted at another SOAP role. If security header contains the mus-tUnderstand=“true” attribute, the receiving must result a fault if it does not support WSS:SOAPMessage Security. The Security header in the example contains a token UsernameToken which isused to provide a username.

<S12:Envelope><S12:Header>

...<wsse:Security S12:role="..." S12:mustUnderstand="..."><wsse:UsernameToken><wsse:Username>Zoe</wsse:Username>

</wsse:UsernameToken>...

</wsse:Security>...

</S12:Header>...

</S12:Envelope>

Example 9.1: WSS Security header with one token, source: [39]

The messages being transported are exposed to different attacks. Table 9.1 presents commonattacks with short description and a solution that can be used to prevent the attack.

75

Table 9.1: Types of atttacks

Attack Description SolutionMessage alteration an attacker modifies the messages sent

in a conversationincluding signatures of the message in-formation using WSS

Message disclosure an attacker wants to capture informa-tion from the message

encrypting sensitive data using WSS

Message forgery an attacker attempts to inject messagesinto a conversation

including signatures of the message us-ing WSS

Message replay an attacker inject previously sent (andhence correctly authenticated) mes-sages into a conversation

mechanisms should be used to identifyreplayed messages such as the times-tamp outlined in WSS; the other tech-nique may be usage of sequence num-bers

Address spoofing an attacker attempts to obtains autho-rization for various actions by assum-ing the identity of a different, autho-rized party, and acting accordingly

ensuring that all addresses are signedby a party authorized to speak for theaddress

76

Chapter 10

Conclusions

Web Service is a way that allows the applications developed with different technologies andon different platforms to work together. To provide such interoperability it is necessary to usea technique for communication which will make the messages understandable for every applica-tion. The technique may be SOAP which uses XML for serializing messages. SOAP standarizesmessaging to remove ambiguities and to ensure that a message created by one application willbe understood by another. The latest SOAP version is 1.2 and it is recommended to use in webservices. There are also other standards created with interoperability in mind that extend SOAPin some way. One is WS-Addressing which provides a way to indicate destination of the mes-sage and supports exchanging the messages. The second standard mentioned in this thesis isWS-Security which gives the mechanisms for securing the messages to ensure that they are safelydelivered from a sender to a receiver.

There is a lot of products that implement SOAP and support development and deployment ofWeb services. I have evaluated two representatives of these products. Bea Weblogic Server 9.2and Internet Information Services were chosen because they use different technologies: Java and.NET respectively. Both servers implement SOAP 1.2 specification. They support also SOAP 1.1according to Basic Profile 1.1 created by Web Services Interoperability Organization. The Profileremoves some ambiguities from SOAP 1.1 specification and adopts some SOAP 1.2 solutions toprovide interoperability and prevent different developers from creating their own interpretation ofSOAP.

The servers were evaluated in terms of response time, throughput and resource requirements.There were also measured sizes of transported messages but it is independent of the server. SOAP1.1 and 1.2 messages where used during the evaluation. The results show that both servers havevery similar performance for two types of messages. Therefore the loss of the server performanceshould not be an argument when deciding which type of messaging to choose when developing aweb service. The response time and throughput of both servers were similar in general. However,sending arrays with ints and doubles showed that Weblogic performs significantly worse than IISdue to another way of dealing with arrays. On the other side, Weblogic performs better for largestrings. The evaluation of the resource requirements show that the usage of the resources is similarfor both servers. The interesting thing is that they deal very well with memory.

The servers performed very similarily so when choosing a server for web service deploymentit should be considered what data will be used at most. With this knowledge the performanceof the servers should be analyzed and the best solution for particular situation chosen. However,there are situations when the performance is not so important. It is when an organization is usinga technology and it uses the server which best fits and supports this technology.

77

List of Figures

2.1 Web Service engaging [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Service Oriented Model, source [2] . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Graphical SOAP Message representation . . . . . . . . . . . . . . . . . . . . . . 83.2 Request-response with WS-Addressing . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Fields in DIME message [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Compound SOAP Structure, source: [21] . . . . . . . . . . . . . . . . . . . . . 254.3 XOP processing, source: [23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Bea Weblogic Request Processing [27] . . . . . . . . . . . . . . . . . . . . . . . 345.2 IIS Application Pools [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.1 Response times for messages containing int type . . . . . . . . . . . . . . . . . 457.2 Server throughput for messages containing int type . . . . . . . . . . . . . . . . 457.3 Response times for messages containing double type . . . . . . . . . . . . . . . 467.4 Server throughput for messages containing double type . . . . . . . . . . . . . . 477.5 Response times for messages containing user defined type . . . . . . . . . . . . 477.6 Server throughput for message containing user defined type . . . . . . . . . . . . 487.7 Response times for messages containing string type with 500 characters . . . . . 497.8 Response times for messages containing string type with 1000 characters . . . . 497.9 Server throughput for message containing string type with 500 characters . . . . 507.10 Server throughput for message containing string type with 1000 characters . . . . 507.11 Overview of Bea Weblogic Server performance when processing messages with

string data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.12 Overview of Internet Information Services performance when processing mes-

sages with string data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.13 Response times for messages containing byte array with 1000 bytes . . . . . . . 527.14 Response times for messages containing byte array with 10000 bytes . . . . . . . 537.15 Server throughput for messages containing byte array with 1000 bytes . . . . . . 537.16 Server throughput for messages containing byte array with 10000 bytes . . . . . 547.17 Overview of Bea Weblogic Server performance when processing messages con-

taining arrays of bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.18 Overview of Internet Information Services performance when processing mes-

sages containing arrays of bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 557.19 Response times for messages containing int array with 1000 elements . . . . . . 567.20 Server throughput for messages containing int array with 1000 elements . . . . . 577.21 Overview of Bea Weblogic Server performance when processing messages con-

taining arrays of ints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.22 Overview of Internet Information Services performance when processing mes-

sages containing arrays of ints . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.23 Response times for messages containing double array with 1000 elements . . . . 587.24 Server throughput for messages containing double array with 1000 elements . . . 59

78

7.25 Overview of Bea Weblogic Server performance when processing messages con-taining arrays of doubles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.26 Overview of Internet Information Services performance when processing mes-sages containing arrays of doubles . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.27 Percentage content of payload and overhead in the message . . . . . . . . . . . . 647.28 payload and overhead sizes in a message containing string . . . . . . . . . . . . 667.29 The percentage content of payload and overhead in a message containing string . 667.30 Changes of the message size when the array of ints increases . . . . . . . . . . . 697.31 The percentage content of payload and overhead in a message containing array of

ints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.32 Results for simple type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.33 Results for string with 1000 characters . . . . . . . . . . . . . . . . . . . . . . . 717.34 Results for byte array with 1000 elements . . . . . . . . . . . . . . . . . . . . . 717.35 Results for byte array with 10000 elements . . . . . . . . . . . . . . . . . . . . 72

79

List of Tables

3.1 Relations between roles decalared in header block and SOAP node roles, source:W3C, SOAP Version 1.2 Part 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Relaying header blocks, source: W3C, SOAP Version 1.2 Part 1 . . . . . . . . . 11

5.1 BEA implementation of SOAP 1.1 and SOAP 1.1 specification differences . . . . 32

7.1 Differences in response times when the size of array changes . . . . . . . . . . . 557.2 Percentage part of message that contains payload . . . . . . . . . . . . . . . . . 63

9.1 Types of atttacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

80

Bibliography

[1] W3Schools. Web Services Tutorial. http://www.w3schools.com/webservices/no_intro.asp.

[2] W3C Working Group Note. Web Services Architecture. W3C, February 2004.http://www.w3.org/TR/ws-arch/.

[3] Rahul Gupta. Wsrp: Dynamic and real-time integration. SOA World Magazine, 2005.

[4] Ethan Cerami. Web Services Essentials. O’Reilly & Associates, 2002.

[5] Sanjiva Weerawarana; Francisco Curbera; Frank Leymann; Tony Storey; Donald F. Fergu-son. Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More. Prentice Hall, 2005.

[6] Latha Srinivasan and Jem Treadwell. An overview of service-oriented architecture, webservices and grid computing. Technical report, HP, November 2005.

[7] W3C. Simple Object Access Protocol 1.1. http://www.w3.org/TR/2000/NOTE-SOAP-20000508.

[8] James Snell. Web services insider, Part 1. O’Reilly & Associates, 2001.

[9] Don Box. A brief history of soap. April 2001.

[10] Web Services Activity Statements. W3C. http://www.w3.org/2002/ws/Activity.

[11] W3C. SOAP Version 1.2 Part 0: Primer. http://www.w3.org/TR/2003/REC-soap12-part0-20030624.

[12] W3C. SOAP Version 1.2 Part 2: Adjuncts. http://www.w3.org/TR/2003/REC-soap12-part2-20030624.

[13] W3C. SOAP Version 1.2 Part 1: Messaging Framework. http://www.w3.org/TR/2003/REC-soap12-part1-20030624.

[14] Beth Linker. Introduction to ws-addressing. In Dev2Dev; By Developers, for Developers.dev2dev.bea.com, January 2005.

[15] W3C. Web Services Description Language (WSDL) 1.1, March 2001.http://www.w3.org/TR/2001/NOTE-wsdl-20010315.

[16] Luis Felipe Cabrera; Christopher Kurt; Don Box. An introduction to the web services archi-tecture and its specifications. In Web Services Technical Articles. October 2004.

[17] W3C. Web Services Addressing (WS-Addressing), August 2004.

[18] W3C. XML Information Set. http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.

[19] W3C. SOAP Messages with Attachments. http://www.w3.org/TR/SOAP-attachments.

81

[20] Jeannine Hall Gailey. Sending files, attachments, and soap messages via direct internetmessage encapsulation. MSDN Magazine, December 2002.

[21] W3C. SOAP 1.2 Attachment Feature. http://www.w3.org/TR/soap12-af/.

[22] W3C. SOAP Message Transmision Optimization Mechanism, January 2005.http://www.w3.org/TR/soap12-mtom/.

[23] W3C. XML-binary Optimized Packaging, January 2005. http://www.w3.org/TR/2005/REC-xop10-20050125/.

[24] JSRs: Java Specification Requests, JSR 921: Implementing Enterprise Web Services 1.1.

[25] BEA. Weblogic Server 9.2 Documentation.

[26] WS-I. Basic Profile Version 1.1.

[27] Bob Hensle. Application architecture for applications built on bea weblogic platform 8.1. InDev2Dev; By Developers, for Developers. dev2dev.bea.com, February 2005.

[28] Reagan Templin. Introduction to iis 7 architecture. In IIS; TechCenter. www.iis.net, April2007.

[29] Overview of IIS 6.0 Architecture, August 2005.

[30] Dan Davis; Manish P. Parashar. Latency performance of soap implementations. ClusterComputing and the Grid 2nd IEEE/ACM International Symposium CCGRID2002, pages377–382, 2002.

[31] Alex Ng. Optimising web services performance with table driven xml. Software EngineeringConference, 2006. Australian, pages 100–112, 2006.

[32] Alex Ng; Shiping Chen; Paul Greenfield. An evaluation of contemporary commercial soapimplementations. Fifth Australasian Workshop on Software and System Architectures, 2004.

[33] Richard Bladh & Per Arneng. Performance analysis of distributed object middleware tech-nologies. Master’s thesis, Blekinge Institue of Technology, 2003.

[34] Christopher Kohlhoff; Robert Steele. Evaluating soap for high performance business appli-cations: RealâAStime trading systems. In WWW2003.

[35] Roman Stanek. Future of web services. In Web services expert predictions. SearchWebSer-vices.com, January 2004.

[36] Chris Dix. Proffesional XML Web Services, chapter SOAP Services. Wrox Press Limited,September 2001.

[37] H. Peter Alesso. Preparing for semantic web services. In XML, XSLT & Web Services.sitepoint.com, May 2004.

[38] Harold Lockhart. Demystifying security standards. In Arch2Arch; By Architects, for Archi-tects. dev2dev.bea.com, October 2005.

[39] OASIS. Web Services Security: SOAP Message Security 1.1, January 2006.

82