Network Protocol Analysis - Essay Example

?Network Protocol Analysis By Institute Table of Contents List of figures Figure 1components Of SOA Architecture, Image Source: (Rotem-Gal-Oz,2012) 6 Abstract In the past few years, the field of information technology has experienced an amazing pace of advancement. In fact, these developments and advancements of information technology have caused a considerable transformation in the understanding, thoughts and ways of thinking of the people. It is an admitted fact that computer technology has affected many parts of our life by playing a vital role. In addition, business organizations are adopting modern and innovative tools and technologies in order to survive in this ever-increasing competitive world. In fact, with the developments in information technologies, organizations are adopting the trend of building their IT infrastructure using already developed services rather than re-inventing the wheel. In view of the fact that it helps organizations reduce development costs and provide the system with greater adaptability as new services can be composed and existing services can be discarded in case of any change in business requirements or market conditions. In this regard, organizations are increasingly adopting Service Oriented Architecture (SOA) to build their IT infrastructure by dynamically composing loosely coupled services to perform their business operations. This research is aimed at exploring SOA and web service technology, focusing on its significance as compared to traditional distributed computing paradigms. In this paper, the significance of different protocols that form the basis of SOA and web services is also revealed and different frameworks and tools are discussed that provide the capabilities of development and integration. Keywords: Service-Oriented Architecture, XML, Web Service Description Language, Web services Introduction Service-oriented architectures (SOA) is a rising approach, promising, efficient and effective system that is loosely coupled, based on open standards, and is not bound to a special type of protocols. In this scenario, the operation of the organization, adopting SOA is run by invoking loosely coupled services often in an asynchronous or event driven style according to the requirements of the underlying business process (Papazoglou & Heuvel, 2007). Basically, the Web services have been very popular since 1999 and the most significant factor that forms the basis of success and popularity of web services is the truth that its backbone is XML (Suda, 2003). In addition, the Web Services work by defining web interfaces all the way through the usage of XML schema and a machine-readable specification called Web Services Description Language (WSDL) to describe the configuration of the input and output messages that are exchanged to invoke and consume the service (Wilkinson et al., 2009). This paper will provide a brief description of SOA, web services and the advantages of web service technology over other traditional technologies. Basically, this research is aimed at exploring SOA and web service technology, focusing on its significance as compared to traditional distributed computing paradigms. In this paper, the importance of a wide variety of protocols that form the basis of SOA and web services is also revealed and different frameworks and tools are discussed that provide the capabilities of development and integration. Service Oriented Architecture (SOA) Service-oriented architecture (SOA) is an influential distributed computing architecture that facilitates a higher degree of abstraction in the development, deployment and operation of platform independent IT infrastructure. Additionally, the SOA involves the communication between service providers and service consumers for the consumption of hosted services. SOA provides with a scheme of architecting, implementing, installing, and administering the IT infrastructures, in which, business functionality is provided by reusable services with the help of interfaces which are defined separately from the service implementation. SOA infrastructure facilitates discovery, invocation and composition of services by means of certain protocols and standards which are mostly message based exchange of documents (Lewis, 2010; Gronosky et al., 2010). Basically, an SOA facilitates an adaptive and agile architecture that simplifies the business processes by promoting the use of reusable services in order to perform different tasks of a business process so modularizing large applications into services. A consumer can access an SOA services from any device in any working environment and platform to create a new business process. As an Application, an SOA based solution consists of a group of services that can exchange messages with each other using well defined interfaces to communicate with each other, or to synchronize an activity between one or more services (Papazoglou & Heuvel, 2007). (Rotem-Gal-Oz, 2012) describes several components of a Service oriented Architecture. SOA is an architectural style that allows the development of systems based on abstract and autonomous components called services that communicate with each other. Each service reveals its functionality or methods by means contracts, which are exchanged in the form of messages at discoverable addresses called endpoints. To govern the behavior of services, policies are specified which are external to the service itself (Rotem-Gal-Oz, 2012). In this scenario, the figure 1 shows the SOA components and their relations: Figure 1components Of SOA Architecture, Image Source: (Rotem-Gal-Oz, 2012) Service is the base of Service Oriented Architecture and it must be composed with other services in a ways that the SOA application should provide with high cohesion and loose coupling. A Service should autonomous and must provide with all the functionality exposed by its contracts which are basically the set of all the messages supported by the Service. The contract is like an interface of the service similar to the interfaces of objects in object oriented languages (Rotem-Gal-Oz, 2012). The Endpoint is a URI, which points the location from where service can be accessed and consumed. A service contract can be found at a specific endpoint (Rotem-Gal-Oz, 2012). Services communicate by means of messages and there are various forms are messages that are valid for communication between services such as HTTP GET messages, SOAP messages, JMS messages and even SMTP message. A message that is communicated has a header and a body. The header part can be interpreted by the components of infrastructure without understanding every message type. So header is usually generic and it contains information which allows for infrastructure components to route reply messages (Rotem-Gal-Oz, 2012). One significant factor that differentiates object orientation with component orientation is existence of service policy. Service policy exposes the assertions that express the conditions of service availability for service consumers. Policy is specified externally to business logic and can be updated at runtime in case of any changing requirement related to different properties such as service’s performance, security (encryption, authentication, Id etc.) , auditing, SLA etc. (Rotem-Gal-Oz, 2012). The service consumer consumes the service to perform different business related activities it can be any software or artificial agent that communicates with a service by exchanging messages. Services can be consumed by a client application or other services that need the output of the consumed service but it is required that they are bound to an SOA contract (Rotem-Gal-Oz, 2012). Web Services Web services have come into sight as an efficient and extensible technology that facilitates application-to-application interaction, using open standards and protocols. Web services are relatively new class of Web based software applications that are autonomous, self- governed, loosely coupled, modular applications that are utilized by publishing in a registry, and then are located and invoked by the consumer. Different web services are available now across the web that can perform simple as well as complex functions such as performing the simple task of information processing as well as executing complex business processes. After a web service is published in a registry or hosted on a server it can be accessed and invoked by different clients, devices or applications that interact with the web service to perform different operations. Basically, the Web services technology has three components, communication protocols for the exchange of messages, service description, describing methods exposed by the service and its inputs and outputs and discovery of service. Different standards and protocols that are introduced by web services technology are simple object access protocol (SOAP) that enables exchange of messages between Web services, Web Services Description Language (WSDL) that presents machine-readable information of Web services; a Universal Description, Discovery and Integration (UDDI) registry which is a directory of Web services WSDLs (Wang et al., 2004). In this scenario, SOA is used over other distributed computing paradigms such as CORBA, RMI, JAVA, COM/DCOM. The most important advantage of SOA is that the above mentioned paradigms are tightly coupled with respect to end points e.g. CORBA requires compatible ORBs at each endpoint, similarly COM/DCOM requires Windows on each point for the functioning of this paradigm. But SOA supports platform heterogeneity and allows communication as well as access of services in language and platform independent manner (Phu, 2005). The main theme behind the emergence of Web services was basically to efficiently deal with the challenge of interoperability and integration of applications developed in diverse platforms. Different distributed computing paradigms such as CORBA, RPC, and COM/DCOM were emerged with similar objectives, but each paradigm came with its own inherent infrastructure. As a result, these technologies proved to be quite expensive for integrating applications developed on heterogeneous platforms. A typical challenge that is faced while using the technologies such as CORBA and COM/DCOM is dealing with different languages. CORBA tackles this problem by using an intermediary language, Interface Definition Language (IDL) thus keeping other languages in the background. It requires developer to get an understanding of IDL in order to use CORBA which is an additional overhead and communications would have been simplified if there could be a way to replace IDL with some higher level language. Web services, which are autonomous, reusable components, have achieved the aim of application integration and interoperability, through the use of open standards such as XML etc., Over a wider scope of internet as compared to CORBA that was mainly used for enterprise-wide application integration. Web services facilitate with a higher degree of loose coupling and cohesion as compared to CORBA and COM/DCOM that were more appropriate for intra organization environments, whereas the technological characteristics of Web services allow greater reusability even for Web-wide environments. So in comparison with other distributed paradigms, web services can be seen as providing maximal decoupling ensuing reusability and ease of composibility and can be accessed over the open economic infrastructure such as internet. The strength of this technology lies in the use of open standards and communication protocols such as SOAP, XML,WSDL,UDDI etc., which simplifies the use of this technology and reduces costs and overheads for application integration (Wang et al., 2004). Existing Web Service Protocols The emergence of web services technology has introduced a variety of standards and protocols that have enabled this technology to ensure transparent and simplified integration of applications over an extensive web-wide scope. This section provides a brief literature review of some of these standards and protocols and their pros and cons are highlighted: REST (Representational State Transfer) Representational State Transfer (REST), can be defined as a standard or an architectural style prescribing certain principles for the design of web services and distributed hypermedia systems. REST basically does not provide with the implementation details of web services rather it provides the principles to achieve maximum capacity of distributed hypermedia systems over the Internet. The REST was introduced to define some architectural principles that may determine the directions for design and further advancement of Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI) that form the basis for communication over the internet in general and with the web services in particular. Furthermore, design principles introduced by REST have turned out to be a significant component of the common architecture of the internet. REST principles enforce caching of requests following a stateless and layered client/server pattern. It requires a standardized interface between different web services and code-on-demand aid, if it is required (Fielding & Taylor, 2000). In addition, REST considers data and functionality to be the resources that are accessed by means of Uniform Resource Identifiers (URIs), which are usually linked on the Internet. In this scenario, different operations are defined to manipulate and utilize these resources as manipulated and utilized. The REST is fundamentally an architectural style based client-server interaction, and it uses the HTTP protocol to ensure a stateless communication. REST principles promote the use of well defined interfaces and protocols to exchange the representation of the aforementioned resources between client and server which ensures that REST promises simple and lightweight web services with high performance (Sun Microsystems, Inc., 2009). The principles defined by the REST command that the server is not allowed to hold the state of the session as it is supposed to be a stateless entity. In order to understand the requests from the clients, those requests must be holding all the necessary information; consequently, a stateless server can understand a request without maintaining previous sessions. Moreover, it enhances the scalability of server as resources held by the server can be released after serving every single request. To dispatch the messages and provide supplementary services REST principles allow putting in intermediary components between client and server. The layers are only accessible to very next neighbors and cannot be accessed by other neighbors that are not immediate which enhance decoupling between the layers and providing with greater flexibility for deployment and evolvement of components. Reverse-proxy servers are an example of an intermediary component (Fielding & Taylor, 2000). The main advantage provided by the REST Web Services is the simplicity of operation as the request is sent from a client in the form of a simple HTTP operation and the answer is also an HTTP response with embedded XML. In addition, the REST is very advantageous in the environments that provide with a Limited bandwidth and resources. The structure of response over HTTP is really simple and does not require intensive efforts of the developers to understand it as it is developer defined. And also, REST web services are accessible through any browser as it uses the standard GET, PUT, POST, and DELETE verbs and also REST uses the XMLHttpRequest object that is supported by almost every modern browser so it adds an additional support of AJAX controls. On the other hand, REST also has a disadvantage that there are no principles that may enforce the adherence to quality attributes, other than the basic security such as transport-level security using HTTPS but it may not be suitable for the operating environments that require the adherence to high level quality attribute requirements (Lewis, 2010; Rozlog, 2010). SOAP (Sample Object Access Protocol) For the exchange of information in distributed technology, particularly web services, Sample Object Access Protocol (SOAP) is most commonly used messaging protocol that is based on XML. The purpose of SOAP protocol is basically to define different mechanism for communication of messages between different web services and processes of remote procedure call (RPC). As SOAP is an XML based protocol so it promotes interoperability and is compatible with the application developed in diverse platforms and programming languages. In a communication between a client and service provider SOAP just serves as a protocol, defining the messages that are communicated to access the service. As compared to HTTP, which is not a safe protocol for the communication of messages, SOAP ensures a secure communication of messages. Three main components of SOAP protocol include a messaging framework that describes the way to specify what a message contains, the message is intended for whom and id the message is optional or mandatory. The second component of SOAP protocol is standard for and encoding/serialization which deals with serialization mechanism to serialize instances of application-defined data-types. The third component is the mechanism to make a Remote procedure call (RPC) which is used to request the invocation of a service published in the registry (Jucyte et al., 2006). In addition, the SOAP plays a critical role in establishing trust by ensuring secure message transfer among the service providers and consumers in a collaborative environment. In an environment where different web services are interacting and being consumed, the establishment of trust between providers and consumers play an important role for healthy operation in such environment. So, SOAP can be used to bridge the gap of trust between service providers and consumers by ensuring safe, static or a dynamic Interaction among service, through SOAP message exchanges (Rahaman & Schaad, 2007). Moreover, the use of SOAP is advantageous in different situations such as where Asynchronous processing and invocation of services is needed such as SOAP supports WSRM (WS-Reliable Messaging) where an application needs reliability and security in a particular environment. SOAP also provides the way for service providers and consumer to follow formal contracts; if they agree to adopt a specific format for exchange of messages. If it is needed to maintain contextual information then SOAP guarantees such stateful operations by adhering to the WS* structure to support those requirements such as Security, Transactions, Coordination (Rozlog, 2010). On the other hand, there are some aspects because of which SOAP is disadvantageous in certain situations. The applications that were built based on older versions of SOAP, has to maintain a new connection every time with other applications if it is needed to interact with those applications again. SOAP adopts the method of serializing by value rather than by reference that may harm the actual contents of the SOAP message that is being serialized. The communication protocol initially supported by SOAP was HTTP so the performance was not up to the mark because HTTP is a relatively slow protocol for communication (SHNE et al., 2009). WSDL (Web Service Description Language) Web Service Description Language (WSDL) provides an XML based description of web services. To get to know about the location and operations of a web service, clients must understand and interpret its WSDL file. Thus, the WSDL of a service can be taken as the opening interface of the corresponding service that facilitates clients with all the information necessary to invoke and communicate with the service. WSDL of a service provides the client with the information such as the location of the service, operations provided by the services, the communication protocols under which the service can communicate, and the information about the format of messages that can be sent to the service for the sake of communication. A WSDL file provides an XML based syntax to describe a service using six main elements that are ’Port type’ that perform the grouping of the operations of the service that can be accessed through its interface. ‘Port ‘defines the communication ports for binding purposes. In this scenario, the message describes the names and format of the messages supported by the service. ‘Types’ is used to describe the data types supported by the service to send and receive messages from the consumers. ‘Binding‘element provides information about the communication protocols supported by the operation of the services and ‘Service’ element provides a URL where the service can be invoked (Cavanaugh, 2006). The WSDL file of a service is only limited to providing the information related to its functionality and syntactic features. However, it does not provide a way to reveal non-functional information about the service such as describing the quality attributes supported by the service. There is also lack of supporting tools to access the WSDL file of the service first to access that service (Yu et al., 2010). In addition the use of WSDL file supported by web service technology is advantageous in several ways. As WSDL is based on standards, so developers do not need to include language specific construct for the invocation of the service as the WSDL file and building the web service based on this file serves this purpose. In this way, the use of WSDL file enhances interoperability and supports platform heterogeneity as client from any operating environment and platform can access and invoke the service. Although the preliminary steps of accessing a WSDL file and then invoking service based on available information may seem to be an addition overhead but the resulting interoperability is the main reason behind the success of web service technology the WSDL contract-first approach may seem more rigorous at first, the resulting benefits make the service more effective by ensuring interoperability, which, after all, is the rationale behind using Web services in the first place (Cavanaugh, 2006). UDDI (Universal Description Discovery and Integration) Universal Description Discovery and Integration (UDDI) is basically a directory where web service can be published and information about different web service can be found. The central part of the UDDI project is the UDDI business registration, which is an XML file used for the purpose of defining a business entity and the web services it offers. Abstractly, the information about any business and its web services is made available by dividing it into three types of pages. ‘White pages’ contain the information about address, contact, and known identifiers of the business. ‘Yellow pages’ contains the information about the categorization of businesses according to industry types based on standard taxonomies for instance, purchasing, shipping, etc. and ‘green pages’ provide with the technical details about the services that are offered by different businesses. It also includes URLs to access and discover different files and references to the specifications of web services (Accenture, Ariba, Inc., 2002). Two types of clients interact with a UDDI registry first are the service providers wanting to publish the interfaces and description of service and other are the clients who want to consume a specific service and want to get the description of that particular service and they want to programmatically bind the services with their application (Wang et al., 2004). There are certain limitations of UDDI registry as well. The most dominating limitation that somehow degrades the utilization of UDDI is its dependence on a WSDL file for description of services. WSDL files describe the details about Service contracts, but it does not provide with certain document-levels details that are required by certain businesses wanting to consume the service. Moreover, UDDI does not track the associations between businesses that are published in its directory so it cannot provide information based on the association between business entities when a client is searching for a particular service. For instance, a business of rental car service might publish its information under ‘Car Rental Services’ in same category but if a client is searching for car rental services under ‘Passenger Transport’ category it would not get any results even though ‘Car Rental Services’ is a secondary category under ‘Road Transport’, which is a sub category of ‘Passenger Transport’. So, UDDI only supports searching with the direct match. In cases where no direct matches are available but a set of services can be composed to fulfill a request, UDDI fails to provide any search results because it does not look beyond direct matches (Yu et al., 2010; Bloomberg, 2004). (Spencer, 2008) have described various advantages than can be achieved by utilizing UDDI registry: UDDI is available free of cost with any version of windows server and is compatible with the specifications governed by OASIS. So it’s an open and widely adopted standard For the connection with Databases UDDI is provided with built in support for storing data in SQL Server. Its development environment is based on .NET which provides the client programmers with the relief to use SOAP or Web services. The location of the UDDI registry is published in Active Directory, so it helps client finding it without depending upon configuration. The management of UDDI is done using a Microsoft Management Console (MMC) snap-in and a web based user interface that that provide the users with a great easy to manage, view or search through UDDI. UDDI is secured with integrated windows authentication which provides with the facility of user authentication and authorization. UDDI comes with well design pre-made graphical user interface tool allows user to define customized taxonomies for the categorization of business entities making discovery process more easier (available in Windows 2003 Server Resource Kit). For registering WSDL documents UDDI contains a wizard that is supportive of pushing the service’s description to a developer registry before deployment. Tools/frameworks for the development and integration of web services There are several tools and development frameworks that have been proposed and are available in the market which serve for the integration and development of web services. Enterprise service bus (ESB) is an integration tool to facilitate the integration of services in an SOA environment. It provides with application programming interfaces (API) that can be utilized to develop web services and integrate them reliably. Basically ESB performs the functions of protocol adaptation, transformation of message formats, routing of messages, acknowledge messages from various services and application thus, an ESB can be seen as a messaging backbone. There can be confusion between the purpose of ESB’s and bus based implementations that are in the market for a long time. In fact there is not much dissimilarity between ESB and proprietary buses but the cost of ESB is significantly low as compared to bus implementations. There is a twofold reason behind this reduced cost of ESB’s, firstly proprietary bus provides with many built in functionalities which need to be separately developed for ESB implementations based on business requirements, secondly the cost increases if bus implementation is adopted of integration because most proprietary buses exploit some proprietary formats to improve the performance. On the other hand, ESB does not use proprietary formats but is based on standards, so performance may be degraded as well as the cost is reduced. So there is a tradeoff between performance and cost between (Goel, 2010). There are several Java based API’s that can be used for the development and consumption of web services and to enhance the performance.’Axis2’ is a total re-architecture of its older version Axis1. X and is based on the StAX which is a Streaming API for XML and because of pull parsing based on StaX API its performance is supposed to be better than Axis1. x. This reliance on StAX does not require serializing or storing all the contents of XML in object forms in memory, and it supports the use of either SOAP or Java transport mechanisms. Yet, the limitation of Axis2 is that it also does not provide with the mechanism to dynamically invoke the web services in a transparent and efficient manner. Similarly ‘SAAJ1.3’ is an API developed by Sun for reliable SOAP messaging. Still, it is not compatible with other Java-based transport mechanisms like JMS, RPC, etc., as Axis2 does. ‘XFire’  that is developed by Codehaus team is a substitute to Axis1.x. The goal is to enhance the performance, along with the the compatibility with SOAP1.2 and adherence to WS-I 1.1. It can be easily used to expose the methods developed in JAVA as a web service endpoint as it has an embedded HTTP server (Embedded XFire HTTP Service) which provide ease of integration. Like Axis2 It also supports pull parsers and integrate StAX. Although, encoded RPC-style services are not supported by XFire, and it is planned to make it compatible with dynamic clients (which might be featured in the next release) (Revoor, 2007). In addition, the Java Web Service Development Pack (Java WSDP) is a set of development tools and technologies for easier and simplified development and building of web services using the Java 2 Platform. In addition WCF (Windows Communication Framework) presented by .Net framework provides with modern and up to date technologies to develop and build web services. Conclusion In recent research, service-oriented architecture has been given considerable importance. The main reasons are its support for important non-functional requirements such as reusability and adaptability. SOA contributes to corporate agility by promoting the use of consistent and standardized interfaces, leading to interoperability and therefore matching with fundamental infrastructure’s interfaces of an enterprise’s existing IT solutions, consequently making the integration of existing and new services easy. On the other hand Web services are reusable software components that adopt open standards such as HTTP and XML based messages to communicate with each other. SOA is basically an architecture defining certain principles for how to build an IT infrastructure for the businesses out of reusable services and web service technology provides the realization of SOA. This research is basically aimed at providing insights into SOA and web services technology. It is focuses on how web service technology is advantageous over traditional distributing computing technologies such as CORBA and COM/DCOM. Furthermore, this research explores the advantages and disadvantages of different standards and protocols, such as REST, SOAP, WSDL and UDDI, which are exploited by web service technology for simplified development and seamless communication and discovery. Different tools and mechanism have been proposed and are commercially available in market such as ESB for the integration of service and several API’s are available to enhance the performance of web services these include Axis2, Saaj1.3 and XFire. For the development of web services Java Web Service Development Pack (Java WSDP) and Windows Communication Framework (WCF) are available to ensure simplified development of web services. References Accenture, Ariba, Inc., 2002. UDDI Technical White Paper. [Online] Available at: http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf [Accessed 10 April 2012]. Bloomberg, J., 2004. Case Study ZapNote: The Hartford UDDI. [Online] Available at: http://www.zapthink.com/2004/03/31/case-study-zapnote-the-hartford-uddi/ [Accessed 19 April 2012]. Cavanaugh, E., 2006. Web services: Benefits, challenges, and a unique, visual development solution. [Online] Available at: http://www.altova.com/whitepapers/webservices.pdf [Accessed 21 April 2012]. Fielding, R.T. & Taylor, R.N., 2000. Architectural styles and the design of network-based software architectures. University of California, Irvine. Goel, A., 2010. Enterprise Integration: EAI vs. SOA vs. ESB. [Online] Available at: http://ggatz.com/images/Enterprise_20Integration_20-_20SOA_20vs_20EAI_20vs_20ESB.pdf [Accessed 18 April 2012]. Gronosky, A., Atighetchi, M. & Pal, P., 2010. Understanding the Vulnerabilities of a SOA Platform - A Case Study. In 2010 Ninth IEEE International Symposium on Network Computing and Applications. Cambridge, MA, USA, 2010. Jucyte, K., Kevelaitis, K. & Park, S.W., 2006. Web service implementation with SOAP and REST. [Online] Available at: http://www.rucsdigitaleprojektbibliotek.dk/bitstream/1800/2108/1/Web%20services%20-%20SOAP%20%26%20REST.pdf [Accessed 21 April 2012]. Lewis, G., 2010. Getting Started with Service- Oriented Architecture (SOA) Terminology. [Online] Available at: http://www.sei.cmu.edu/library/assets/whitepapers/SOA_Terminology.pdf [Accessed 20 April 2012]. Papazoglou, M.P. & Heuvel, W.-J., 2007. Service oriented architectures: approaches, technologies and research issues. The VLDB Journal- The International Journal on Very Large Data Bases, 16(3), pp.389-415. Phu, P.H., 2005. A service management framework for SOA-based interoperability transactions. In KORUS 2005. Proceedings. The 9th Russian-Korean International Symposium on Science and Technology., 2005. IEEE. Rahaman, M. & Schaad, A., 2007. SOAP-based Secure Conversation and Collaboration. In ICWS 2007. IEEE International Conference on Web Services., 2007. Salt Lake City, UT. Revoor, M., 2007. Java Web Services Tools. [Online] Available at: http://freecode.com/articles/java-web-services-tools [Accessed 19 April 2012]. Rotem-Gal-Oz, A., 2012. What is SOA anyway? Getting from hype to reality. [Online] Available at: http://www.rgoarchitects.com/Files/SOADefined.pdf [Accessed 19 April 2012]. Rozlog, M., 2010. REST and SOAP: When Should I Use Each (or Both)? [Online] Available at: http://www.infoq.com/articles/rest-soap-when-to-use-each [Accessed 21 April 2012]. SHNE, A.A.B., FUHRER, P. & PASQUIER, J.S., 2009. Web Services Technologies: State of the Art Definitions, Standards, Case Study. [Online] Available at: http://diuf.unifr.ch/drupal/softeng/sites/diuf.unifr.ch.drupal.softeng/files/file/publications/internal/WP09-04.pdf [Accessed 22 April 2012]. Spencer, T., 2008. Some Benefits of Enterprise UDDI Services. [Online] Available at: http://travisspencer.com/blog/2008/03/some-benefits-of-enterprise-ud.html [Accessed 18 April 2012]. Suda, B., 2003. SOAP Web Services. Thesis Report. School of Informatics, University of Edinburgh. SunMicrosystems, Inc., 2009. RESTfulWeb Services Developer'sGuide. [Online] Available at: http://docs.oracle.com/cd/E19776-01/820-4867/820-4867.pdf [Accessed 20 April 2012]. Wang, H., Huangc, J.Z., Qub, Y. & Xie, J., 2004. Web services: problems and future directions. Journal of Web Semantics: Science, Services and Agents, 1(2004), pp.309-20. Wilkinson, M.D., Vandervalk, B. & McCarthy, L., 2009. SADI Semantic Web Services – ‘cause you can’t always GET what you want! [Online] Available at: http://sadiframework.org/documentation/SADI_SWSIP09_personal.pdf [Accessed 17 April 2012]. Yu, S.-j., Zhang, J.-z., Ge, X.-k. & Wu, G.-w., 2010. Semantics Based Web Services Discovery. [Online] Available at: citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.rep [Accessed 20 April 2012]. Read More