1 Introduction

2,033 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,033
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

1 Introduction

  1. 1. Michael Wong 151220 University of Portsmouth Computing & Mathematics Programme Area Final year project undertaken in partial fulfilment of the requirements for the BSc (Honours) Degree in Computer Science (IBM Integrated) An Investigation of the performance of Web Services for the Wimbledon Information System by Michael Wong (151220) Supervisor: Dr Mark Baker Project unit: CP.WEPT2 2003 Abstract This project investigates the performance of Web services for real time applications. In order to assess the suitability of Web services, benchmarking tests were devised and round trip times recorded and analysed. An existing web based application in the form the Wimbledon Java Scoreboard was then analysed and test cases pertinent to it devised. Round trip times were then recorded, analysed and compared with the benchmarking test cases. Findings suggested that Web services in their current form perform sufficiently well for trial implementations of real time applications. However, as the application of Web services for real time applications is still new and in a relative phase of infancy many issues remain to be explored, including further work in performance, security and Quality of Service. 1
  2. 2. Michael Wong 151220 Acknowledgements This project could not have been possible without the following people who I thank: • Mark Baker of the University of Portsmouth for his supervision and guidance in this project • Alex Phillips for his assistance in many areas particularly Wimbledon related work with Wimbledon Information System and the Java Scoreboard • Anna Withrington for her understanding about time • Andy Burns and Ian Hughes for suggesting a project in Web Services • My parents and my brother for their constant support and encouragement 2
  3. 3. Michael Wong 151220 1 INTRODUCTION.................................................................................................................5 1.1 WIMBLEDON – THE CHAMPIONSHIPS...............................................................................................6 1.2 IBM - OFFICIAL INFORMATION PROVIDER.........................................................................................7 1.3 WEB SERVICES.....................................................................................................................8 1.4 THE PROBLEM.....................................................................................................................10 1.5 AIMS AND OBJECTIVES...........................................................................................................11 1.6 CONSTRAINTS.....................................................................................................................12 1.7 PROJECT OVERVIEW...............................................................................................................13 2 REVIEW...........................................................................................................................14 2.1 WEB SERVICES...................................................................................................................15 2.1.1 ARCHITECTURE..............................................................................................................16 2.1.2 SOAP, WSDL AND UDDI..............................................................................................19 2.2 WEB SERVICE DEVELOPER KITS - HOSTING PLATFORMS...........................................................................27 2.3 QUALITY OF SERVICE – PERFORMANCE AND TESTING............................................................................30 2.4 JAVA SCOREBOARD ARCHITECTURE................................................................................................33 2.5 JAVA SCOREBOARD INTERACTION ANALYSIS......................................................................................36 2.6 BENCHMARKING WEB SERVICES..................................................................................................39 3 DESIGN............................................................................................................................41 3.1 TIME STAMPING - CODE INSERTION..............................................................................................42 3.2 DETAILED ANALYSIS OF TEST CASE SCENARIOS..................................................................................44 3.3 BENCHMARKING TEST CASES.....................................................................................................46 3.4 DETERMINING PERIODICITY OF JSB APPLICATION DATA...........................................................................47 3.5 IMPLEMENTING LOGGING AND TIMESTAMPING.....................................................................................48 3.5 TIMING ISSUES...................................................................................................................49 3.6 DEFINING TEST DATA............................................................................................................50 3.7 TEST ENVIRONMENT..............................................................................................................51 3.8 TESTING PROCEDURES............................................................................................................52 4 IMPLEMENTATION...........................................................................................................53 4.1 INTRODUCTION....................................................................................................................54 4.2 JSB INTERACTION TEST CASES..................................................................................................55 4.2.1 TEST CASE 1: ONE WAY - “A SINGLE ONE WAY MESSAGE REQUEST” ....................................................55 4.2.2 TEST CASE 2: UPDATE BY POLLING - “A REQUEST-RESPONSE COMMUNICATION, WHERE THE RESPONSE CONTAINS A PAYLOAD OF APPLICATION DATA”..............................................................................................................56 4.2.3 TEST CASE 3: CHECK/POLL AND RESPONSE/UPDATE - “REPEATED REQUEST-RESPONSE COMMUNICATION, WHERE MOST RESPONSES ARE OF A SMALL PAYLOAD AND FEWER RESPONSES CONTAINING A PAYLOAD OF APPLICATION DATA”.......................57 4.3 BENCHMARKING TEST CASES.....................................................................................................58 4.3.1 RETURNING PRIMITIVES - SIMPLE RPC....................................................................................58 4.3.2 RETURNING MULTIPLE PRIMITIVES – COMPLEX RPC.......................................................................59 4.3 DEPLOYING TEST CASES..........................................................................................................60 4.3.1 BATCH SCRIPTS AND CLASS PATHS ........................................................................................60 4.3.2 CONNECTING THE REQUESTOR TO THE PROVIDER.............................................................................60 5 ANALYSIS OF RESULTS AND EVALUATION.......................................................................62 5.1 BENCHMARKING RESULTS.........................................................................................................63 5.1.1 SIMPLE RPC PRIMITIVE DATA TYPE RESULTS.............................................................................63 5.1.2 COMPLEX RPC PRIMITIVE PAYLOAD........................................................................................67 5.2 JSB INTERACTION RESULTS......................................................................................................70 5.3 ASSESSING METHODOLOGY.......................................................................................................73 6 SUMMARY, CONCLUSIONS AND FUTURE...........................................................................76 6.1 SUCCESS OF PROJECT.............................................................................................................76 6.2 FUTURE WORK....................................................................................................................78 6.3 FINAL REMARKS..................................................................................................................79 REFERENCES.......................................................................................................................80 INTRODUCTION.........................................................................................................................80 REVIEW................................................................................................................................82 WEB SERVICES.....................................................................................................................82 WEB SERVICES DEVELOPER KITS – HOSTING PLATFORMS...............................................................................84 QUALITY OF SERVICE – PERFORMANCE AND TUNING................................................................................85 JAVA SCOREBOARD ARCHITECTURE..................................................................................................86 JAVA SCOREBOARD INTERACTION ANALYSIS ........................................................................................87 BENCHMARKING WEB SERVICES.....................................................................................................88 DESIGN................................................................................................................................89 IMPLEMENTATION.......................................................................................................................90 ANALYSIS OF RESULTS AND EVALUATION...............................................................................................91 LIST OF FIGURES................................................................................................................92 APPENDICES.......................................................................................................................93 APPENDIX A: REQUIREMENTS..........................................................................................................94 APPENDIX B: WIMBLIVE DATABASE - CURRENT VIEW DESCRIBE.....................................................................95 APPENDIX C: BACKGROUND SERVICES (RUNNING DURING TESTING)...................................................................96 APPENDIX D: COMMUNICATION - SOFTROS RE: NETWORK TIME SYSTEM LATENCY..................................................97 APPENDIX E: ERROR LOG FOR NO CHARACTER MAPPING IN AXIS....................................................................98 APPENDIX F: SAMPLE BATCH SCRIPT FOR RUNNING TEST CASES......................................................................99 3
  4. 4. Michael Wong 151220 APPENDIX G: AXIS FAULT - CONNECTION REFUSED STACK TRACE.................................................................100 APPENDIX H: SOURCE FILES........................................................................................................101 RETURN LONG - SIMPLE RPC....................................................................................................101 RETURN MULTIPLE BYTES – COMPLEX RPC......................................................................................110 ONE WAY – SIMPLE RPC........................................................................................................123 COLLECT AND UPDATE (HIGH PAYLOAD) - COMPLEXRPC4......................................................................130 APPENDIX I: COMPLEX RPC RESULTS...............................................................................................159 APPENDIX J: SIMPLE RPC RESULTS................................................................................................162 APPENDIX K : JSB INTERACTION TEST RESULTS.....................................................................................166 4
  5. 5. Michael Wong 151220 1 Introduction The first section of the project report outlines the background and the problem to be solved. 5
  6. 6. Michael Wong 151220 1.1 Wimbledon – The Championships Every June, The All England Lawn Tennis and Croquet Club is host to The Lawn Tennis Championships. The Championships first started in 1877 when the only event was the Gentlemen’s singles and was won by Spencer Gore. In 1884 Ladies’ singles was added to the list of events and by the turn of the century The Championships had become an international tournament. The Championships has continued to evolve to the status of a professional Grand Slam tournament and now attracts players from over 60 countries who compete for titles in singles, doubles, junior, senior and wheelchair events [1]. The Championships is a very popular event and over the 2 weeks attracts over 500,000 visiting spectators as well as millions of tennis fans, who track the events through TV, the Web, Radio and mobile devices. The demand for information regarding Wimbledon and the events which unroll there is high. IBM is the official information provider. [2] 6
  7. 7. Michael Wong 151220 1.2 IBM - Official Information Provider IBM is the official information provider for The Championships – Wimbledon. IBM’s offerings include the Commentator System – providing real time detailed statistics to commentators, graphics and statistics for TV broadcasters, an Intranet system and an Internet presence. Each of the systems possesses a different focus tailored to the intended end users. For example, the Commentator System is intended for use by professional commentators and as well as real time scores, has a strong emphasis on match statistics and player histories. Whereas the intranet system Wimbledon Information System (WIS) is intended for the general public and tennis fans has video content, useful information about Wimbledon, picture biographies and a real-time scoreboard. Each of the systems feed from a central backbone, which receives raw data such as rankings and biographies for men’s and ladies’ tournaments from the LTA and WTA respectively and real time scores, which are computed to form match statistics and histories, from courtside data-entry positions. The raw data that IBM provides through its own systems such as WIS, Commentator and the Web Site [1], also feeds the BBC with biographies and statistics in a graphical form. The Championships is an popular event attracting over 500,000 of attending fans, 3.2 million unique users to the wimbledon.org and nearly a billion viewers via TV, the Web and mobile devices in 2001. The Real Time Java Scoreboard represents a popular part of the Wimbledon Web site. In 2001 over 4.5 million scoreboards were launched, reflecting the demand for the real time information that IBM can provide [3]. 7
  8. 8. Michael Wong 151220 1.3 Web Services The Web is based on two core technologies TCP/IP and HTTP [4] [5] [6]. A standard HTTP get request is successfully responded to by returning the data referenced by the given URL, often an HTML document or data returned from an application such as a JSP, which may also be a HTML document. By presenting information as HTML, users can access in an open, standard fashion any document regardless of subject via a browser. The simplicity of implementation and standardisation of fundamental technologies accounts in part, for the exponential growth of the Web. As the Web continues to mature, there has been an increase in dynamic content. Information such as stock quotes, weather forecasts, banking details, stock control, and multimedia entertainment are just some of a handful of examples of commonly accessed dynamic applications. Web sites that providing dynamic content include: • BBC Weather [7], which provides detailed UK and worldwide weather reports based on town names, postcodes, UK and worldwide regions and city names. • American airlines [8] provide a dynamically generated, customised front end based on details supplied by the user. This Web site uses Broadvision one-to-one in order to generate content [9]. • O2 Online Shop – [10] provides an e-commerce front end where customers can search and assemble their desired product package. The O2 site uses JSPs in order to generate content at each stage of the purchase process [11]. Typically, e-commerce web sites deliver dynamic content to its visitors. For example, the process of searching an online product database will require an input from the user to generate a query conducted on the database and then a means of representing the results to the user. Technologies such as JSP and ASP allow connections to a database to be established, conduct queries and then display the results to via a dynamically generated web page. Real time delivery of data also falls within the definition of dynamic content. Examples include the Wimbledon Real Time scoreboard [1], which provides live scores, and statistics and Finance at Yahoo [12], which provides live streaming real time stock quotes to subscribers. Cheaper bandwidth, storage and the proliferation of new devices capable of accessing the Web from previously inaccessible geographies results in a continued growth of complexity. Despite different operating systems and devices with different requirements for presentation applications will still need to communicate with each other. The W3C states that: “The World Wide Web is more and more used for application to application communication. The programmatic interfaces made available are referred to as Web Services.” [13] Standard HTML documents possess insufficient expressiveness for supplying data necessary for application-to-application communication. For example, HTML possesses no means of representing arrays, or data types differentiating between an integer and a string. The formatting offered by HTML is intended for humans and not applications as end users. The W3C, in partnership with many major vendors including, IBM, Sun, Microsoft, BEA and Oracle, have been collaborating to establish standards in the form of Web Services that are capable of supplying data in a suitable format for application-to- application communication. So far, the fruits of their labours have resulted in three main technologies, which have been declared as the foundations of Web Services. These are SOAP, UDDI and WSDL. Work is ongoing and it is likely that Web Services standards will continue to be refined and added to. The architecture and implementation of Web Services is discussed in-depth in section 2.1. The Simple Object Access Protocol (SOAP) provides the mechanism for transporting XML data in a platform independent manner. Universal Description, Discovery and Integration (UDDI) provides a registry by which Web Services can be published, discovered and invoked. Web Services Description Language (WSDL) provides a language, again based on XML, by which Web Services can be described. In Summary, IBM’s tutorial describes Web Services as… 8
  9. 9. Michael Wong 151220 “..self-contained, self-describing, modular applications that can be published, located, and invoked across the Web.” [14] Small modular applications can be integrated to perform other functions to fulfil other higher levels needs. For example a corporation’s travel arrangements where smaller components for car, flight and hotel arrangements provided by different companies can be integrated to form a single point of access for a user within the corporation. To fulfil this requirement Web Services can exchange data in an open manner, which can be interpreted and are discoverable by other Web Services. 9
  10. 10. Michael Wong 151220 1.4 The Problem The demand for information about Wimbledon is high, with almost a billion people accessing information regarding Wimbledon via TV, the Web, radio and mobile devices. Further analysis reveals the level of demand through the Web, with which this project is primarily concerned. In 2003, Wimbledon.org recorded over 4 million unique users [15]. Despite slow global economic growth during the 2003, when compared with previous years the web usage statistics clearly indicate a continued growth of demand for Web-based access of The Championships information [16]. 2.6 million unique users were recorded in 2002, 3.2 million unique 2001 and 1.8 million users recorded in 2000 [17] [18] [19]. The number of users dropped in 2002 but increased again in 2003. The Real Time Java Scoreboard (JSB) [1] provides real time scores and statistics to the users that are running the JSB client. The JSB operates as a stand-alone application, which pushes scores point-by-point, real time to the user’s client. The Real Time Java Scoreboard (JSB) is a major focus of visiting users with 4.2 million Scoreboards downloaded in 2002, reflecting the demand for real time information [20]. Wimbledon presents a problem that is suitable for Web Services to solve. The problem faced by Wimbledon is an example of the desired application-to-application communication over the Web, which is made difficult by the absence of any existing mechanism to of discovery and delivery of information in a format that can be easily interpreted by the requesting party. Web Services have been implemented with success in non-real time applications, however real time Web Services are in a comparative phase of infancy. Considering this, the overall problem can be defined as follows: • The problem of how real time data can be packaged and distributed to other web applications. This can be subsequently divided into two smaller problems. 1) Ensuring the delivery of data within the predefined limits of ‘real time’. 2) Packaging data for distribution in a suitable format for web applications. Previous work [21] has been conducted in the problem of supplying Wimbledon data to other web sites using Web Services for non-real time data including news, photos and match reports. Building on work previously conducted the use of Web Services will be investigated to determine suitability of this architecture and its associated technologies for providing real time data for the JSB. 10
  11. 11. Michael Wong 151220 1.5 Aims and Objectives The overall aim of this project can be defined as: • To investigate and determine whether Web Services are a suitable means of packaging and distributing real time data. This overall aim being to assess the feasibility of deploying the Wimbledon Java Scoreboard as a Web Service. However, the broader context of the suitability of Web Services for real time data in distributed applications other than the wimbledon.org web site will be discussed. The primary objectives that are more specific can be defined and include: 1) To examine and assess the features of Web Services that may make them a suitable means of accessing and exchanging real time data. 2) Investigate aspects of Quality of Service, in particular response times when returning a range of data types under different conditions. 3) Analyse the results in order to gain an insight into the suitability of Web Services in delivering real time content. Secondary objectives of the project may also be defined, these constitute further research, which would be useful to undertake but not considered essential to this project. 1) Make predictions on the response times for the JSB, based on the findings from the primary objectives before converting the JSB to a Web Service. 2) Investigate the response times of the Web Service-based JSB implementation and analyse it correlation between predictions based on findings from primary objective 2, and actual results recorded. 11
  12. 12. Michael Wong 151220 1.6 Constraints Hardware The hardware available for testing includes an IBM PC 300pl and IBM Thinkpad 600x laptop spec. Although this is acceptable for small scale testing such as will be conducted in this project a more comprehensive study would include testing of Web Services upon hardware built typically used for web hosting. For example, the IBM P-Series server a Symmetric Multi-Processor server designed for use with UNIX and implemented by O2 to serve web content [11]. Software and Operating Systems The OS available for testing is Windows 2000 professional. Again, although this is acceptable for small scale testing it is unsatisfactory for the purposes of comprehensive testing. Given sufficient time, testing on a variety of OSs including Windows 2000 server, a number of Linux versions and UNIX variants would provide insights into the differences between OS performance in hosting Web Services. 12
  13. 13. Michael Wong 151220 1.7 Project Overview Chapter 2, ‘Review’ – In this section the relevant literature will be studied with the aim of better understanding of the issues, technologies and similar work related to real time Web Services. In the first section of the review, Web Services architecture and implementation will be examined in detail. In the second section analysis of the Intranet Java Scoreboard is offered and in the third section Benchmarking and Quality of Service (QoS) will be examined with particular attention to performance. Finally, a discussion regarding benchmarking and which aspects of Web Services should be measured is offered. Chapter 3, ‘Design’ – A detailed list of requirements for benchmarking is developed in this section. The decision-making processes and strategies employed in developing and implementing the test cases and procedures are documented and referenced against the requirements. Chapter 4, ‘Implementation and Testing’ – In this chapter, the main problems encountered and their resolutions are documented. Any modifications to the design are also justified and documented within this section. Chapter 5, ‘Evaluation’ – In the evaluation an assessment to the products (test cases) is given against the specification identified in chapter 3 and the aims and objectives identified in chapter 1. Analysis of the results of the test cases will also be discussed here, including findings and implications regarding real time Web Services. Finally a critique of the testing methodology will also be made. Chapter 6, ‘Summary, Conclusions and Future’ – An overall discussion of the project is offered here, including the original problem, the design and implementation and whether the project revealed any insights into the problem stated. Challenges are also discussed here and suggestions for continued future work. 13
  14. 14. Michael Wong 151220 2 Review The objective of this project is to assess the suitability of Web Services for real time applications. The motivation for this assessment arises in the form of the Java Scoreboard. Previously the JSB had been mentioned in the context of the wimbledon.org website, however, for the purposes of testing the suitability of Web Services for real time data, the Intranet version of the JSB will be considered. Considering the implementation of Web Services within an intranet environment is useful as it allows the suitability of the application of Web Services to be assessed in a contained and less visible environment. The Wimbledon Information System (WIS) is the intranet-based system, hosting the JSB. The WIS provides real time scores, statistics, biographies, video and other information for users on site during the two weeks of the Wimbledon Championships. Although less visible than the Internet site, it is visible to the general public, players, coaches and press as well as IBM employees and as such is not a company intranet, which is normally insular to employees. For this reason, the investigation of Web Services needs to be thorough, before the JSB is implemented as a Web Service. As noted before, the actual implementation of the JSB as a Web Service is not the primary focus of this project; the investigation of whether this is suitable is. 14
  15. 15. Michael Wong 151220 2.1 Web Services In the introduction, Web Services were introduced as discoverable, self-contained, self- describing modular applications that are suited for application-to-application communication. In this section an in depth discussion as to how Web Services deliver the described properties is offered. The architecture and operation of Web Services is also explored with attention to Quality of Service issues. The approach in this section will be to describe Web Services from a top down approach, first describing the roles and interactions of Web Services then drilling down to the architecture and then finally to examining the underlying technologies that implement these features. 15
  16. 16. Michael Wong 151220 2.1.1 Architecture Web Services are an example of a Service Oriented Architecture. That is, each service, which is well-formed and self-contained, makes available their resources and how to access and interact with them. Services connect with other services for the purposes of either data passing or co-ordinating an activity. Web Services operate independently of other services in fulfilling a particular function and can be integrated with other services in order to perform larger tasks. The key features of Web Services include modularity and flexibility based around industry standards that help simplify integration. The W3C Web Services Architecture Working Group (WSA WG) [1] distinguishes between a Basic and Extended Architecture [2]. The Basic Architecture is defined as the core roles and activities, without which Web Services cannot exist. The Extended Architecture is defined as the additional patterns and features, which may be important but not vital to the existence of Web Services. The Basic Architecture • The Service Provider – The Service Providers deploy Web Services on the Web. Deployed Web Services are made available by publishing their details to a Service Broker and described by Web Services Description Language (WSDL), which defines how to communicate and interact with the service. • The Service Requestor – The Service Requestor represents the party interested in accessing the Web Service. The Service Requestor queries the Service Broker for details about a required service, which then returns details about how to resolve and connect to the service. • The Service Broker – The Service Broker acts as an introduction service for the Service Requestor when locating and connecting to a particular Web Service. The Service Broker may be privately available such as through an intranet or extranet or publicly available on the Internet. Hence the availability of a Service Provider is partially limited by the visibility of the Service Broker it has published its details to. It should be noted that a Service Broker, for certain interactions may be by-passed, such as where the Service Requestor already knows the location of the Service provider, rather than discovering the Provider at run time. This requires that the Service Requestor possesses the WSDL document of the Service Provider or knows where to obtain it. However, for the purposes of an Internet wide system of service discovery, the absence of a searchable directory of Web Services available at run time would render Provider resolution extremely slow and unpractical. Therefore, the Service Broker is part of the core Web Services architecture. The roles described above and their behaviour is encapsulated by the following three named activities (see Figure 1 : Service Oriented Architecture [2]): • Publish – This describes the activity a Service Provider executes when it deploys a Web Service to a Service Broker or directory. The details of how to locate and communicate with the Web Service are also published to the service directory. • Find – This describes the process of locating a Web Service, where a Service Requestor contacts a service directory and searches for the required service. • Bind/Interact – Once the Service Requestor has obtained details of how to interact with the Service Provider, the interactions between the Service Requestor and Service Provider can occur. The coupling of requestor and provider is referred to as binding. 16
  17. 17. Michael Wong 151220 Figure 1 : Service Oriented Architecture [2] In this project, the primary area of focus is not on the finding or publishing of a Web Service but the interactions between a Service Requestor and Provider. 17
  18. 18. Michael Wong 151220 Extended Architecture The Extended Web Services architecture is defined as: “…incorporating additional features and functionality by extending the technologies and components defined within the basic Web Service architecture.” [2] Sect. 3.2 That is, features and functions that are extensions to Web Services and periphery to the Basic Architecture. The term periphery is not intended to imply that such features may be superfluous but to refer to a non-vital component of the abstract, conceptual Web Service. Some examples of features that fall within the scope of the Extended Architecture include: • Reliable Messaging – ensuring guaranteed delivery of messages between Web Services [3], • Attachments – the binding of two documents together for exchange between Web Services [4], • Message Confidentiality – transmission of messages to ensure that only the intended parties may read the contents of the messages [5], • Message Integrity – ensuring that messages can only be modified by authorised parties [5], • Message Routing – the dynamic specification and orchestration of message exchanges between Web Services [6] [7], More examples may be found in the Web Services Architecture Working Group Sect. 3.2. Parts of the extended architecture can be implemented with existing technologies. For example MQSeries [14] could be implemented as part of the underlying infrastructure supporting the Web Service to achieve reliable messaging. Attachments have been incorporated into SOAP 1.1 and can be used to bind two documents together for transport. However, development of Web Services Extended Architecture implementations is not formally regulated by w3c as the core architecture is. As a result, vendor specific implementations of some of the extended architectures, such as reliable messaging formats are possible. Web Services core architecture preserves interoperability such that extended architectures may be implemented in a modular, layered fashion, separate from the fundamental operations of the Web Service. Extended features of Web Services are relevant to the implementation of real time communication of data. Security of data is paramount, particularly where the value of data is tightly linked with the age of the data. Data must be received by the requestor within the agreed definition of real time and must also be done so securely to prevent unauthorised parties from accessing data. The implementation of additional security such as through the use of cryptographic techniques e.g. Encryption and Digital Signatures introduces an overhead. This increases the processing required to encrypt and decrypt data and thus increases the time taken to deliver data sent between Provider and Requestor. The result is an antagonism between trying to achieve low latencies and implementing sufficient security to protect the data. The impact and overhead of implementing extended features is of secondary importance in this project but is occasionally discussed as a related issue. 18
  19. 19. Michael Wong 151220 2.1.2 SOAP, WSDL and UDDI The integration of Web-based applications often faces difficulties because of non-standard means of communication. That is, the formats and mechanisms to deliver information differ, requiring additional systems to translate and reconcile how applications interact and data received and sent. Web Services greatly reduce the integration costs by standardising the formats of data presentation. Also provided is a standard means of describing how to interface and interact to the service and a means to discover the service. The technologies used to provide these defining features are XML and SOAP, WSDL and UDDI. This section explains the purpose of each of these technologies and their function within Web Services. 19
  20. 20. Michael Wong 151220 XML Xtensible Markup Language [8] is a flexible way of structuring and describing information. XML can be used to annotate, or markup, data. Its flexibility is that it allows programmers define their own tags and use them to markup the data within a document. Because of this data described in XML can be easily understood by humans, through the use of appropriate naming conventions and also easily interpreted into programming data types by applications, through the use of an XML parser. Figure 2 : Roads - XML Example <?xml version="1.0"?> <roads> <motorways> <motorway>M25</motorway> <motorway>M4</motorway> <motorway>M275</motorway> </motorways> <a-roads> <a-road>A3</a-road> <a-road>A31</a-road> <a-road>A331</a-road> </a-roads> </roads> Figure 2 shows some example XML is whereby information about roads can be categorised and tagged. The resulting structure as inferred by the in order of tagging is as follows. Figure 3: Roads – Data Structure roads Elements motorway s a-roads Data motorway motorway motorway a-road a-road a-road m25 m4 m275 a3 a31 a331 In Figure 3, the grey nodes represent the elements, the white nodes represent the data included within the tags. Thus with XML data types can be defined by the programmer and expressed in a format where structure can also be applied. Other XML classes also contain DTDs, XML Schemas and XML Namespaces. Document Type Definitions – DTDs [9] are optional in XML documents. Essentially, DTDs are a set of rules defining the elements, attributes and structure of the document. They are embedded within the XML document and validate the data contained within a given XML document. In terms of Web Services, this reduces the processing required by the application as validation can be delegated to the XML parser rather than being processed by the application. Furthermore, as DTDs are declarative rather than procedural as most application code is, DTDs make validation code easier to maintain [10]. XML Namespaces [11] – Within a single XML document it is possible to include information for multiple purposes. The problem with this is how to distinguish which elements belong to which purpose. In particular, which elements describe the document properties and 20
  21. 21. Michael Wong 151220 which elements are relevant to the application. For example, consider an eCommerce application where requests are posted using XML. Potentially information expressed as elements for message sender and recipient, timestamp, billing, posting, referencing and stock order may be packaged up within one XML document. For the purposes of book keeping and order processing it is necessary to define which pieces of information belong to which purpose of category. For example billing information may be kept separate to the message timestamp. This can be accomplished by namespaces, which takes the same approach as packages in Java. Namespaces are expressed as uniform resource identifiers – URI’s (RFC 2396) and are associated with a prefix. This prefix is combined with the element as prefix:elementName to provide a means of separating XML elements according to the programmers purposes. XML Schemas [12] – DTDs provide a means of automating the validity checks performed on a XML document but fail to address the integration of namespaces and the mapping of XML to data types. XML Schemas are an attempt to address the issues of integrating namespaces and mapping of XML to data types as well as maintaining the flexibility that the programmer has when writing plain old XML. XML Schemas have been designed with reuse and extensibility in mind. As XML Schemas are written in XML they allow the programmer freedom to define and write schemas as freely as XML documents. There are of course conventions that govern this process. For example, XML Elements should be associated with a basic data type, and elements with attributes. Complex data types may also be defined and should always be formed from compositions of basic data types. XML Schemas are complex but provide a way of integrating validity checks, XML element to data type binding and namespaces in a modular fashion. They also maintain the extensible development that plain old XML affords the programmer. XML Schemas can be reused and used in conjunction with other schemas and allow custom data types to be defined as long as they are compositions of base data types. A more detailed explanation of XML and XML Schemas is available from W3C [12]. 21
  22. 22. Michael Wong 151220 SOAP The Simple Object Access Protocol (SOAP) provides the transport mechanism for sending XML documents and attachments in Web Services. The W3C define SOAP as: “a lightweight protocol for exchange of information in a decentralized, distributed environment.” [13] In order to act as a requestor or a provider a device needs to be able to build and/or parse XML messages and have a network connection available. A primitive exchange of SOAP request/response is described below. 1) The Service Requestor creates a SOAP message. Here the SOAP message is a request. Within the body of the message, a XML document represents the request as either a Remote Procedure Call (RPC) or a document-centric call. A RPC call represents a call to application logic, such as an entry point into an application. A document-centric call presents no call to the application but merely application data only. The interpreted data determines its operation. Regardless of the request format, the message is presented to the SOAP runtime client with the network address of the Service Provider and then transmitted according to the defined lower level application layer protocol. This protocol is commonly HTTP although implementations over other protocols such as SMTP and HTTPS are also possible. 2) The SOAP message is then delivered to the Service Provider over the network infrastructure. If application specifics are defined, the SOAP runtime is then responsible for the conversion between XML and the application format. This conversion is governed by encoding schemes found within the message, as defined by the XML Schema. The result of the SOAP message processing is then passed to the Web Service. 3) The Web Service then processes a response. The response, which is also encoded as XML is passed to the SOAP runtime for transmission with the destination of the Service Requestor. As a side note, extended features such as asynchronous or synchronous messaging are governed by the underlying infrastructure. For example, MQSeries [14] could be implemented for guaranteed delivery of asynchronous messages, but the details are kept separate from the implementation of the Web Service. 4) The response message is routed through the network infrastructure to the Service Requestor. The Service Requestors’ SOAP runtime client interprets the message, converting any XML defined objects before presenting the response to the Service Requestors application. Other primitive exchanges are also possible such as a one-way request that results in no response from the recipient, a push style notification, and a publish/subscribe mechanism. Interactions that are more complex can be defined including a conversational and many- to-many communications. These can be defined by choreography language, which is part of the WSDL definition. The permutations of more complex choreographed exchanges are formed from compounds of primitive exchanges. Therefore, for the purposes of studying the suitability of Web Services for transmission of real time data, the focus of testing will be primitive exchanges between Service Requestors and Service Providers. It is hoped that the study of primitive exchanges will provide insight into the basic operations of Web Services, which can be used to make certain predictions regarding complex choreographed exchanges. Composition of SOAP Messages [13] A standard SOAP message is comprised from three main parts. They are the SOAP envelope, SOAP headers and the SOAP body. • SOAP Envelope – The SOAP envelope is relatively simple, consisting of only a few XML elements. However, it is a mandatory part of any SOAP message as it communicates fundamental information necessary for distributed processing of XML documents. Within the SOAP envelope, information regarding the contents of the message, the intended recipient and whether the data is optional or mandatory. In every SOAP message, the root element is the envelope element. 22
  23. 23. Michael Wong 151220 Within SOAP 1.1, this element falls within the http://schemas.xmlsoap.org/soap/envelope namespace. As the Envelope is uniquely identified by this namespace, it allows processing tools to immediate identification of a valid XML message as a SOAP message. • SOAP Headers – SOAP Headers are optional to a SOAP message. They are used to encode information that is not relevant to the SOAP Body, for example data relevant to the any implementations of extended Web Services architecture. Examples of data that might be carried in SOAP headers include information relevant to security mechanisms such as authentication and authorisation. • SOAP Body – The SOAP body can contain arbitrary XML. It can contain SOAP RPC calls, error messages and application data. According to the purpose of the XML document, different conventions govern the format. For example, SOAP requests, whether they are RPC or document centric will be based on conventions that will not apply to defining application data. WSDL [15] Web Services Description Language (WSDL) is also based on XML and defines a Web Service and how to communicate and exchange data. WSDL describes three fundamental aspects of a Web Service, which include: • What a service does – the operations and methods that the service provides • How to access a service – detailing the protocols and data formats necessary to access the services’ methods • Where a service is located – the network address of the service, such as a URL [16] The WSDL schema defines a set of high level elements necessary for describing the above criteria. These are defined as abstract and then bound to concrete implementations to make them available. The elements are: • portType – defines abstract interfaces to an exposed procedure, termed “operation”. Typically a Request-Response operation defines an input and an output message, but may only define an input message (one way request) or only an output message (one way notification). • message – defines abstractly, the definition of data to be communicated. A message may optionally be decomposed into parts. For example, a RPC call might define parameters, which can be expressed as parts. • types – defines all data types used in the Web Service to describe the messages exchanged. • binding – defines how the abstract representations of the portType are to be implemented. For example whether an operation is an RPC call or document centric and the encoding schemes used, such as SOAP over HTTP.. • port – defines how a binding is be expressed at a network endpoint. Basically an address, typically a URL. • Service – A named collection of ports. It is possible for a WSDL document to describe multiple ports as necessary for a multi step process, where multiple Web Services may be contacted. [15 ] The combination of these elements allows the communication end points to be described in sufficient detail such that Web Services may communicate autonomously with each other. Although WSDL can be written manually for a Web Service, many vendors development kits include tools which generate WSDL from Java or vice versa. This code can then be modified for the purposes of the particularly implementation, tweaks necessary for this project are described in Section 4: Implementation and Testing. The result is much faster development and fewer errors introduced through hand written code. In summary the WSDL document for a given Web Service is essential for communication between Web Services. The WSDL may be posted to a registry so that services may dynamically bind and connect to the service or distributed directly to the providers as a 23
  24. 24. Michael Wong 151220 static means of interacting with the service. Further details of WSDL can be obtained from W3C [15]. 24
  25. 25. Michael Wong 151220 UDDI [17] In order for a Service Requestor to contact a Service Provider a means of discovering available services is necessary. The analogy offered by Graham et al 2001 in “Building Web Services with Java” is that of a Java programmer browsing Java API documents during development. That is, a repository containing details of Web Services that can be browsed and queried is necessary for service discovery. Universal Description, Discovery and Integration is a Web based distributed directory. It acts like a phone book and provides a means to discovering Web Services. From a business perspective a business will register with one of the UDDI Operators, IBM, Microsoft or Hewlett Packard. The UDDI Operator that has been registered with will then replicate the new entry so that the other UDDI Operators registries also possess the entry. UDDI possesses two fundamental data structures; the business layers and tModel [18]. The business layers can be conceptually divided into three pages. It is worth noting that UDDI does not provide a formalized structure to represent the pages as different entities, rather it is a conceptual model of the information provided. The three pages are defined as: • White pages – containing general contact information regarding the entity represented by the Web Service. E.g. name, address, email address, telephone number etc. • Yellow pages – containing information about the types of service offered. For example, a Building Society offering mortgages. • Green pages – containing information about how to invoke the service. If a building society were to offer mortgage quotes online over the web, a URL would be supplied for this purpose. The business entity provides all the necessary information to find an appropriate Web Service, who is providing it and how to bind to it. The tModel represents an abstracted set of service definitions for a type service. The principle of this is that other similar Web Services that might be supplied can reuse the definition, substituting abstracted information into concrete specific information. For example, a banking consortium may set up a collection of standards to enable smooth integration of transactions between specific types of Web Service and publish them as a tModel. Any banking Web Service that conforms to a given tModel specification can therefore guarantee that it will supply a minimum set of information before binding occurs. This use of the tModel to define pre-arranged technical agreements is known as a Technical Fingerprint [19]. UDDI pages and tModels are both expressed using XML. XML’s extensibility allows for a platform independence that contributes to achieving the goal of an open system of locating and binding to services. 25
  26. 26. Michael Wong 151220 W3C’s View on SOAP and WSDL During the early stages of this project, it was thought that SOAP and WSDL were an integral part of Web Services design and therefore Web Services would inevitably be implemented with SOAP and WSDL. However, W3C states that: “This ‘blessing’ of SOAP and WSDL is not logically necessary… Perhaps in the long run, other technologies will supplant SOAP and WSDL…” [1] Sect. 2 That is to say that another more suitable mechanism of gathering XML documents into a form suitable for transmission may in the future replace SOAP. The W3C Web Services Architecture working document also notes that another description mechansim could be employed, such as DAML-S. [DAML-S] Upon initial discovery, the possibility of more suitable technologies replacing SOAP and WSDL could be cause for concern in that it would render studies into Quality of Service and Security of SOAP and WSDL redundant. However, the w3c article also states that, “…the WSA WG believes that a common foundation is a *practical* necessity for the industry to move forward with additional Web services functionality, including security..” [1] Sect. 2 and because of this, “WSA reference architecture builds on SOAP and WSDL as the basis for messaging and description. Specifications that conform to the WSA reference architecture MUST use SOAP and WSDL when appropriate.” [1] Sect. 2 As the Web Services Architecture Working Group (WSA WG) states, a common agreed set of foundation technologies are necessary for progress to be made. Therefore, it is a necessary for studies of current foundation technologies to take place, in order to iteratively refine and extend the Web Services stack such that it is suitable for industry use. Additional factors such as Management of Web Services, Security and Quality of Service (QoS) are viewed as “overarching” concerns. That is, they are issues that encompass the entire Web Services stack including roles and technologies of the basic and extended architecture. It is Quality of Service that this project is primarily concerned with. 26
  27. 27. Michael Wong 151220 2.2 Web Service developer kits - hosting platforms Many of the major vendors have embraced Web Services as a model to enable Web based applications to communicate and integrate with each other easily. As a result, a variety of ‘kits’ to host and develop Web Services are now freely available. These kits are often bundles of components necessary for publishing and writing Web Services along with an application server to host the Web Service. The purpose of these kits is to provide developers with tools to test and deploy Web Services small scale, rather than hosting enterprise scale applications. The JSB being considered is the Intranet version with a maximum number of concurrent clients of 56 [1] and a standard level of concurrency at 10. The relatively low number of concurrently connected clients (when compared with the Internet JSB) and the assessment purposes developer kits allow for an appropriate match between developer kit and application for investigation. As there are a variety of kits available it is prudent to investigate the available options. Potentially, differences between the kits may make a specific platform more suitable than others for the implementation of the JSB as a Web Service. It is intended that benchmarking and tests of JSB interactions will be performed across a variety of Web Services hosting platforms. 27
  28. 28. Michael Wong 151220 IBM’s Web Services Developer Kit IBM’s Web Services Developer Kit (WSDK) provides a complete Web Services infrastructure, with application server. Version 5.0.1 contains the following components [2]. • Application Server - A lightweight version of WebSphere application server (WAS) Express v5 with support for EJB’s and ORB. • Support - SOAP 1.1, WSDL 1.1, UDDI 2.0, JAX-RPC 1.0, EJB 2.0, Enterprise Web Services (JSR 109) 1.0, WSDL4J, UDDI4J, Soap with Attachments API for Java (SAAJ.jar), • Tools – To publish JavaBeans and stateless session EJBs as Web Services, creating Web Services from WSDL and publish and unpublish Web Services to UDDI. TCP Monitor to monitor Web Services messages being exchanged. SOAP Monitor to monitor SOAP messages being passed between roles and components. • WS-Security – extensions include digital signatures and XML encryption • An entry level database with JDBC connection • IBM Java SDK 1.3.1 • A variety of documentation and reference material, including samples, tutorials and concepts. Sun’s Java Web Services Developer Pack Like the WSDK, Sun’s Java Web Services Developer Pack (JWSDP) also provides a complete Web Services infrastructure, including an application server. Version 1.2 includes the following components [3]. • Application Server - Apache Jakarta Tomcat v5 application server • Support – SOAP 1.1, WSDL 1.1, UDDI 2.0, JAX-RPC 1.1, Soap with Attachments API for Java (SAAJ.jar), • Tools – Ant 1.5.2, a platform independent build tool [4]. TCP Monitoring (as in WSDK). • Security – Apache XML Digital Signatures based on W3C standard. Sample application allowing the developer to digitally sign SOAP messages. • JavaServer Faces (JSF) v1.0 EA4 for developing user interfaces. • JavaServer Pages Standard Tag Library (JSTL) v1.1 EA representing common tags used in JSP pages to simplify page development [5]. • Ws-I Supply Chain Management Sample Application 1.0 EA example Web Services application. Apache AXIS : Apache eXtensible Interaction System The Apache AXIS Web Services framework provides SOAP messaging framework from which Web Services can be implemented. The recommended application server is Jakarta Tomcat, which AXIS is then installed into with Xerces XML parser. Features of Apache AXIS [6] • Application Server – Apache Jakarta Tomcat 4.1.24 (recommended). The AXIS Web Services server is pluggable and could, in theory, plug into other servlet engines. • Support - Soap 1.1/1.2, WSDL 1.1, JAX-RPC 1.0, WSDL4J, EJB, Soap with Attachments API for Java (SAAJ.jar), session-oriented services via HTTP cookies or transport-independent SOAP headers • Tools – Java from WSDL, WSDL from Java, Ant 1.5.2, a platform independent build tool, TCP Monitoring (as in WSDK), SOAP Monitoring (as in WSDK). • Security – can be integrated with Servlet 2.2 roles and security There are also other Web Services development and test platforms available, such as Microsoft’s Web Services offerings [7]. The Microsoft offering has not been included in the list of platforms to test as it does not support Web Services development in Java, only in Visual Basic.net and C# [8]. As the JSB is implemented in Java and the Intranet Producer does not intend on porting the JSB to another implementation language, Microsoft’s Web Services offering has not been included in the list of relevant kits to be tested. Core Offerings 28
  29. 29. Michael Wong 151220 The development kits listed offer common basic functions. They all offer support of SOAP, WSDL, JAX-RPC and a Registry Server. At the time of writing the kits, all offered the same version of support for these core modules with two exceptions. Firstly, Apache AXIS notes that it supports SOAP 1.1/1.2. By this it means that full support for SOAP 1.1 is available and AXIS SOAP also implements some of the features that will comprise SOAP 1.2. Apache AXIS notes there is still much work to be done before SOAP 1.2 is complete [9]. Apache AXIS 1.0 is implementing a form of SOAP 1.2 beta. The second exception is that Suns’ JWSDP includes support for JAX-RPC 1.1 where as IBM’s WSDK and Apache AXIS support JAX-RPC 1.0. JAX-RPC 1.1 differs from JAX-RPC 1.0 in that it adds support for Web Services Interoperability Organisation (WS-I) basic profile 1.0 [10] [11]. Application Server IBM’s offering includes a lightweight version of their WebSphere Application Server (WAS) Express v5. Sun’s JWSDP comes packaged with Apache Jakarta Tomcat version 5, including the Tomcat Servlet and JSP container. Apache AXIS 1.0 recommends an installation of the latest version of Tomcat 4.1.x [12], which has been followed. Prior to testing, the difference in performance of these application servers is unknown. Amongst other improvements, Apache claims that Tomcat v5 has performance optimisations over v4 [13]. It is unclear how these optimisations will affect the performance of Web Services although it is noted as an important contributing factor. It would be interesting to study the effect on performance of different application servers with the different core offerings from each of the vendors. The possible areas for future work are discussed further in section 6: Conclusions – Suggestions for further work. Tools The WSDK implements AXIS but does not expose the programming model. That is, through IBM tools the developer code is deployed as a Web Service, however it is not possible to extend the AXIS model by using the WSDK tools. This is potentially restricting as it makes customising the Web Services engine, such as SOAP handlers difficult but affords focus on the implementation of Web Services rather than the background operation. IBM’s WSDK provides many tools for publishing and creating Web Services where as Suns JWSDP provides relatively few. This is a concern, as for accurate comparison the same test cases need to be implemented on all three platforms. If fewer tools are available it is possible that some code will need to be written on one platform that is automatically generated on another. This may introduce discrepancies in the test cases as a result of differing programmer skill between the writers of the tools and the person writing the test cases. However this also presents an opportunity to assess the degree of interoperability of Web Services, not from the perspective of end points but the portability of application code and re-use across platforms. Web Services forte is declared as ease of integration and interoperability, one of Java’s key features is platform independence. In observing the effectiveness of code re-use between the different vendors platforms it will reveal the differences between implementations of shared objectives and technology. Considering this, the implementation of test cases will attempt to re-use as much code as possible. The results of the attempted testing are discussed further in Section 6: Conclusions. In Summary, given that there are differences in tools, core libraries and the application servers offered (or recommended in the case of AXIS); it will be difficult to define the exact cause of any difference in performance without further testing. However, an overview study of the Web Services development kits available does not require that the exact same tools and libraries are tested. The most important factor is that the kits tested are equivalent in intended purpose and function. The five high level test cases defined in the JSB Interaction analysis section and the test cases outlined in the benchmarking section are intended for testing on all three listed kits, under the same conditions. In this case, all the kits are intended for testing and exploration of Web Services, rather than enterprise Web Services implementation. A primary objective of the design is to ensure that the conditions for testing are fair. 29
  30. 30. Michael Wong 151220 2.3 Quality of Service – Performance and Testing Understanding performance and what its relevance to distributed systems and in this case Web Services is vital. From this understanding, pertinent test cases can be generated in order to assess the suitability of Web Services for real time applications. Mani and Nagarajan define performance in the context of Web Services as, “…the quality aspect of Web service[s], which is measured in terms of throughput and latency. Higher throughput and lower latency values represent good performance of a Web service.” [1] Throughput means the number of requests processed within an arbitrary period of time. Latency refers to the quantity of time that has passed between the submission of a request and a response or the return of a result. In order to understand why throughput and latency are important to performance, it is useful to examine what relevance performance has in the wider scope of distributed computing. Coulouris et al. state that, “[in a distributed system]…The main non-functional properties of systems that affect the quality of service experienced by clients and users are reliability, security and performance”. [2] Although there are other factors attributed to QoS the three factors of reliability, security and performance are defined as properties that affect the level of quality of service (QoS) experienced by users. Put differently, when a user is interacting with a system, the level of QoS they experience will be most apparently affected by factors of reliability, security and performance. Reliability Reliability means how dependable the system is; in particular how dependably the system can fulfill its’ objectives. If it is known that a system will be offline on Sundays but is available 99.99% of the time, from Monday to Saturday it is still said to be reliable; the system is said to be reliably available within the defined limits. Similarly, a system that can deliver error free services to up to 100 concurrent users but above 100 users, frequently experiences failure can also said to be reliable, in the sense that it can be depended on to function within known limits. Reliability is related to failure. The more predictable the rate of failure is and the more readily it can be remedied or prevented, the more dependable the system is. A system should be designed such that technology and processes are designed to ensure the reliability of its services and not detriment reliability by introducing unmanaged complexity. More detailed discussion on the topic of Reliability is widely available examples of which are noted in the references [3]. Security From an architectural perspective of security in distributed systems, security can be achieved by securing processes and interactions and protecting the objects they encapsulate against unauthorized access. Security affects the Quality of Service experienced by the user in positive way, by protecting their information and ensuring that only authorized parties are involved in process interactions. However, ensuring security can also pose potential challenges, such as increasing performance overhead required by cryptographic techniques, such as encryption, digital signatures, hashing functions etc. Security can also impede usability, another factor of QoS [1]. For example, as noted by Nielsen, ‘secure’ passwords containing random characters should be distributed for each of the users applications. However, this impedes usability and an individual using fifty applications is unlikely to be able to recall apparently random passwords. In this situation applications become unusable, therefore users may even resort to recording passwords in a machine readable, centralized location such a plain text file on their workstation [4]. 30
  31. 31. Michael Wong 151220 More detailed discussion on the topic of security can be found from many sources, some of which are listed in the references [3] [5]. Further issues of QoS QoS involves many different aspects, not all of which are listed here. However, of the general themes mentioned, it is apparent that the different aspects of QoS are inextricably linked. For example, implementing computationally expensive encryption, such as RSA to improve security inevitably affects performance by increasing the demand for system resources. The new components introduced for increased security will require, at least server side, performance tweaks to be made to maintain the same performance of throughput and latency. This could be in the form of additional hardware or perhaps new resource management objectives to be made, regardless of how, it will require changes to be made within the system that if incorrectly managed will negatively affect reliability and performance and thus QoS. Ideally, it would be possible to produce a piece of code that could analyze a system and return a set of results detailing the circumstances when the system would fail, under go performance difficulties or crash. Although tools exist for testing and code instrumentation, such as Loadrunner [6] some eventualities cannot be predicted. One such example is the halting problem where, determining whether a program will terminate or not is undecidable; it is an incomputable problem. A thorough explanation of the proof of this can be found in Gödel, Escher, Bach: an Eternal Golden Braid by Hofstadter. In the absence of a tool to analyze fully a given application for halting, performance bottlenecks and failures, it is acceptable to test and build models of the system to be implemented. This affords an opportunity to gain insight into how the system will perform, what sort of behavior to expect and some indication of the expected QoS. To this end, this project focuses on the performance aspect of QoS, for which test cases will be designed with the aim of providing a basis for estimating the performance of real time applications implementing Web Services. Performance Throughput Returning to the factors of throughput and latency in Web Services, the test cases developed will focus on how these factors change in response to varying loads and different message exchanges. Throughput is usually defined as the number of items processed. In the context of Web Services, the items we are processing are ‘requests’, fulfilled by ‘responses’. Within the context of the tests to be considered, the System throughput would relate to the Web Service implementation of the JSB. How many requests the Web Service could process and remain within acceptable limits. The tests defined for each of the specified JSB interactions would relate to Component throughput metrics as they have been abstracted from the larger system of the JSB. Latency Latency is defined as: “The delay between the start of a message’s transmission from one process and the beginning of its receipt by another…” [2] Latency can be impacted by many other factors. Network issues are a common cause of high latency. For example, a busy Ethernet based network is more likely to experience collisions of data packets. In an effort to prevent collisions, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) will back off and delay transmission until the line is detected to be clear again. The result is an overall delay for packet transmission between the sender and receiver. As link utilization increases, higher latencies are be expected. More details on CSMA/CD can be found in Tanenbaum [8]. Further reasons for high latencies include router utilization; as router processor load approaches 100%, backlogs of packets for transmissions begin to form and some packets may be lost as backlogs become filled. The result is slower routing and for retransmission of lost packets resulting in a greater overall latency. Firewalls also undergo the same issues as routers of over utilization and malicious attacks in the form of Denial of Service attacks, which result in 31
  32. 32. Michael Wong 151220 over utilization [9]. As latency will inevitably affect the round trip time of the tests it is important that any extraneous factors are absent when testing is conducted. Considering this, testing will be conducted in an environment where firewalls and routers are absent, and network traffic is silent except for the tests being conducted. Within the context of QoS in Web Services latency is also defined as: “the round-trip time between sending a request and receiving the response.” [1] It is this round trip time that this project is primarily concerned with. Round trip times are pertinent to this study as from a user perspective fluctuations most observably impact QoS. This definition of latency encompasses the previous definition of network latency, the time taken for a message to be sent, receipt by the provider and in a request response interaction, the execution of server side processes and the return of response to the requester. The inclusion of requestor and provider processing within the measurements taken is important as it accounts for the additional overheads that Web Services impose, such as marshalling and conversion of XML and SOAP. Understanding the impact of this overhead is central to estimating the suitability of Web Services for JSB implementation and potentially other real time applications. The round trip time of an interaction is also subject to the throughput thresholds of the application. As the threshold is reached, the application will respond more slowly as requests become back logged, therefore increasing the round trip time of the request. This factor is acknowledged as a contributing factor and forms a secondary objective - to examine the impact of a heavily loaded application on the round trip time of the request/response. 32
  33. 33. Michael Wong 151220 2.4 Java Scoreboard Architecture Figure 4 shows the overall operation of the Java Scoreboard. The Java Scoreboard server operates as a stand alone application. Client-side applets are sent to the client over HTTP. The following sub-section describes the operation of each of the components of the Java Scoreboard. The Datafeed and database servers Datafeed: Tennis matches on show courts, Center Court, Courts 1, 2, 3, 14 and 18 have live data entry. This involves teams of tennis experts entering into a customised application, details of the game, including scores and statistics. Each time a point is completed the details of the point and associated statistics e.g. speed of serve, is broadcasted in a NetBIOS frame [1] across the IBM network at Wimbledon. The NetBIOS score broadcast is detected by an application known as datafeed. The datafeed takes these scores and writes them to a DB2 [2] database that feeds the Java Scoreboard server. The Trigger and UDF: Housed in the DB2 database is a trigger that detects when the database is updated. Once the database is updated, the trigger calls a User Defined Function (UDF). A UDF allows SQL to be extended to incorporate functions not present in the standard set offered by DB2. In this case, the UDF is written in Java but may also be implemented in C or C++. When the database is updated, the UDF notifies the JSB Server on port 7777. An instance of the Connection class detects and recognizes the communication on port 7777 as from the database. The retrieval of new scores from the database is then initiated. The process of datafeed writing to the database and the trigger initiating a notification from the UDF is ongoing for the duration of live matches. The JSB Server Server: The server class is a singleton class that runs throughout the life of the application. Once the server class has been instantiated, it creates instances of the Vulture, CubbyHole and IncrementalUpdate classes. The Server class is also host to a Server socket, listening for clients requesting a connection. When a client connects to the Server, it spawns a new instance of the Connection class for each client and then assigns it to a thread group. Connection: The Connection class is responsible for handling all communications from the database and for the connected client for which it has been spawned. Communications from JSB clients are always through port 6666 whereas communications from the database via the UDFs are always through port 7777. If a communication through port 7777 is detected, the Connection class does a quick check on the format of the notification to ensure it is valid, calls the IncrementalUpdate (twentyCourtA) class which returns the full, updated statistics and then stores them in the CubbyHole. If a communication arrives through port 6666 and a score has recently been updated into the CubbyHole, the Connection class retrieves the score and posts it onto the clients’ socket. If no new score has been retrieved since the client last polled, the CubbyHole returns a “NoNewScore” value, which is posted to the clients’ socket. IncrementalUpdate (twentyCourtA): The IncrementalUpdate class has be renamed for the purposes of ease of reading. In the actual application there are two classes with the same name but different functions. The “UpdateByPolling” or “twentyCourtB” class is packaged with the client side classes and is used only once when the client is first instantiated for retrieving the current scores and statistics by polling the database. The “IncrementalUpdate” or “twentyCourtA” class is maintained server side and is responsible for the ongoing task of fetching and publishing updated scores. CubbyHole: The CubbyHole acts as a repository for current up-to-date scores. It also tracks an ID of the current score. Whenever the CubbyHole is checked for a new score it 33
  34. 34. Michael Wong 151220 compares the ID of the most recent score update from the client has against the current score code. If the score codes are found to be equal, the CubbyHole returns the “NoNewData” message; otherwise it returns the new score. Vulture: On 500 ms intervals, the Vulture checks a vector of live connected clients, represented by instances of the Connection class. Any not live threads are removed from the vector, thus acting as an ongoing house keeping operation. JSB Client Twenty: When a user first navigates to the page hosting the JSB, the Twenty, StreamListener and UpdateByPolling classes are downloaded. The Twenty class is primarily responsible for drawing the scoreboard and updating the graphics. It is the first class to be instantiated and is also responsible for instantiating the StreamListener and UpdateByPolling classes. StreamListener: The StreamListeners first operation is to call the UpdateByPolling class to obtain a set of results. It then maintains a “thin” connection, polling JSB Server side application every 50 ms for updated scores. By “thin” it is meant that the connection does not transfer any considerable data when polling, but merely checks for the existence of new scores. Only when new scores are available does any transfer of data occur. UpdateByPolling (twentyCourtB): This class contains methods that are invoked only once, upon the instantiation of a new scoreboard. It connects directly to the database feeding the Java Scoreboard server and executes the necessary SQL to obtain a full set of current results. This is returned to the Twenty class where the results drawn to the applet. This is the only function of the UpdateByPolling class, after which it terminates. 34
  35. 35. Michael Wong 151220 Figure 4 : Java Scoreboard Interactions Database side operation Stats f rom data entry are updated into the database. A trigger notif ies the UDF (db2 jav a f unction) that new stats are present in the database. The UDF propagates the notif ication to the host of the JSB on port 7777, which all connection classes can see. Datafeed: Update of stats fields from DB courtside data entry f ields DB2 : Wimbliv e Dataf eed and Database serv ers Trigger UDF Serv er Side Operations g ongoin The Serv er class is responsible f or managing client connections. It is a Serv er socket which spawns a new client socket and Connection class (A). The connection class handles all client JSB Serv er communications. When an update f rom the UDF arriv es on 7777, the Connection class calls a method in the Incremental Vulture Connectionclass update class (serv er side twenty court). This f etches and returns the updated data to the CubbyHole connection class which then stores the data in the Jav a Scoreboard cubby hole until it is requested f rom the client. (see Serverclass Serv er IncrementalUpdate StreamListener "thin" connection). (twentyCourtA) 1& 2 - StreamListener "thin" connection When a new score is reciev ed it is placed in thecubby hole. (A) On startup of each new client The StreamListener polls the Jav a Scoreboard Serv er on port 6666 (1), the Connection class picks up the poll and checks the cubby hole. If a new score is detected the score is written to the ports out stream, so the streamlistener can reciev e the new score. The score is then taken pulled f rom the socket by the 1 2 streamlistener (2). terminate client side Client Side Operation When the browser nav igates to the 20 court StreamListe scoreboard page the class "Twenty " is ner instantiated. Twenty instantiates a StreamListener and the UpdateByPoll UpdateBy Pollclass. Twenty (twentyCourntB) Client Web The StreamListener on f irst operation calls the Browser UpdateBy Poll class to get a complete set of results which is then passed back to Twenty f or drawing to the scoreboard. The StreamListener continues to maintain a "thin" connection, polling the socket f or an update in scores. (1) 35
  36. 36. Michael Wong 151220 2.5 Java Scoreboard Interaction Analysis Having examined the JSB architecture it is apparent that there are a number of possible optimisations that will improve the performance. Some possible optimisations include: • Implement new socket functions to allow push style notifications. This would eliminate the need for “thin” client connections, polling the server on 50 ms intervals; an avoidable overhead [1] [2].  Possible to implement some form of messaging software e.g. JMS or Mqseries such that delivery of data is guaranteed [3] [4]. Separation of concerns away from JSB to a more modular fashion. Although there are potential optimisations to the JSB, the objective of this project is to assess the suitability of Web Services for Real Time applications using the JSB as an example. The chosen method of assessing this is to examine the JSB in its current form, i.e. architecture and operation, and to implement tests relevant to this form. It is a possible area for future study to examine the results of this project and specifically study performance-tuning applications for Web Services. The practical aspect of this project shall not be performance tuning the JSB but assessing the performance of Web Services. In considering the implementation of a Web Service JSB, the tests to be implemented shall be selected to reflect the current architecture and operation. That is, regardless of any potential future improvements, the tests must be pertinent to the existing JSB. Figure 5 abstracts from the JSB architecture the key interactions involved in initialising and updating both client and server side of the JSB. The interactions are projected into a suggested implementation of a Web Service JSB, preserving as much of the original architecture as possible. Here follows an attempt to analyse the interactions and define high-level test cases pertinent to assessing the suitability of JSB for implementation as a Web Service. Figure 5 : Java Scoreboard Web Service Interactions Dataf eed and Database Datafeed: Update of serv ers stats fields from DB2 courtside data entry 4. Collect and Update Connectionclass IncrementalUpdate Serverclass Jav a Scoreboard 2.UpdateByPolling (twentyCourtA) Serv er 1. Confirmation 3. Response 1. Request 5. terminate JSB Serv er Service 3. Check / / update Poll Client Side Client Web Browser UpdateByPoll StreamListe (twentyCourntB) ner 36

×