CHAPTER 2 LITERATURE SURVEY 2. FIRST LOOK ON WEB SERVICES Web Services

Transcription

1 CHAPTER 2 LITERATURE SURVEY 2. FIRST LOOK ON WEB SERVICES 2.1. Web Services Usually web service can be understood as a way of message transfer among two devices across a network. The idea behind using web services is mainly to solve three problems, i.e. firewall traversal, complexity & interoperability. A web service contains an interface defined in a format which is machine understandable that is WSDL and the additional systems communicate with the web service in a way recommended by its explanation through SOAP messages, classically carried out with the help of HTTP with serialization of XML in combination along with standards related to web. The main focus or act of web services is converting an application into a web-based application; and publishing its functions. The fundamental platform of web services is XML and HTTP. Web services can be found and published. Usually, they are called application components, which can communicate with each other with the help of predefined protocols. They are revealed through UDDI. The basic elements are SOAP, UDDI and WSDL. Web Services Architecture is explained in detail in [48]. 2.2 About Messages and Messaging For the message format, usually there are different layers-message exchange patterns; several transport protocol bindings which are underlying, some processing models for the messages and characteristic extensibility of a protocol. The immediate parameter right after XML-RPC is SOAP, though it catches the transport and communication standard and its envelope, header and body from an unknown source. 21

2 More often we ll choose XML as the standard message format as its usage is more by all open sources. In order to give momentum to the process of XML messages some hardware tools are also available. Moreover, messages are need to be transmitted together with some attachments Message Oriented Model A model which focuses on the details like Message structure, transport but not the Content of message and its relationship to other messages is called Message Oriented Model Message A message is a fundamental unit of data sent from sender to receiver. A message is a group of fields of data strived or to get collected among applications of software or systems. The main functionality of the system is achieved by exchange of messages between various systems. 1. A message can be a SOAP message in XML, where the SOAP headers are the headers for the message. 2. A message is very trouble-free just like a HTTP GET request, in which the HTTP headers represent headers and the arguments in the URL represent the content Features This mode of communication is called message Oriented Communication Unlike to RPC which uses Procedural calls. Synchronous and asynchronous are the two categories of messages which use many protocols like HTTP, SMTP, FTP etc Message typically Contains Header, Body, Envelope, single sender, one or more Receivers, Address, Transport mechanism Message Header A header portrays information about the way to infer the content of the message. Header of a message is used to identify a service Role. Service Role indicates the specific action to be applied on a message with that header. Message may contain multiple headers hence may contain multiple service roles. 22

3 2.2.5 Message Body It is the primary data required to do certain functionality by the receiver. Correct interpretation of the message body depends on the description of the header Message Envelope Message Header and body are collectively called message envelope. Sometimes the names of the recipients of the message are included in message envelope Message Transport The actual mechanism which is used to deliver the message is called message transport. SOAP over XML via HTTP is the Transport mechanism which we use to deliver messages in web services Message Receiver A system which sends the message is called message sender and the recipient of the message is called message receiver. Sender specifies the intended receiver to message Transport mechanism by encoding the address of the receiver. Message oriented communication is similar to the traditional methods of information exchange by mankind in the form of letters Why Messages are used and not methods We have to define messages for using a web service but not methods, because methods are known only within the application but not to the web client. He may not be aware of the class definitions. This architecture has flaws and does not work properly as the client can t really get the instance of the similar object that the service returns. Hence Message Oriented model is preferred to Remote Procedural Calls. Message Oriented model of developing Web services gives more secure web services as explained in [32]. Hence Messages are used but not methods. 23

4 XML Request and Response Messages We define a request message which inputs the area name using zip code which is unique to an area encoded in XML and we get the response message that includes the current Gold Rate in the specified area encoded in XML. <!-- this is the request message with the zip code of an area in it--> <GoldPriceRequest XMLns=" <!-- this is response message with GoldPrice information and Area Name--> <CurrentGoldPrice XMLns=" <Conditions>916 Hallmark</Conditions> <quality>24 K Gold</quality> <areaname>guntur</areaname> <Price>Rs.10,200/-</Price> </CurrentGoldPrice> This is the example of XML request and response messages for finding gold price in a particular area. This mechanism is particularly used by gold merchants. The XML requests and responses mechanism used in calls of a service is explained in detail in [33]. 2.3 Protocols Web services contain a list of protocols in it. It is collectively named as protocol stack. The various protocols involved in web services are UDDI, WSDL, SOAP, HTTP, SMTP etc. 24

5 2.3.1 Web Services Protocol Stack - Layers Web services contain a group of web protocols and abstract standards to exchange the information between various augmented applications. The Protocol Stack of web services explains the set of internet based protocols or guidelines used to discover, blueprint and extend the web services. In the view of Eric New Comer [46], Web Service Protocol Stack Contains 4 layers. They are shown below: Layer 1 Transport(HTTP,SMTP,FTP) Layer 2 XML Messaging(SOAP,XML) Layer 3 WSDL(Description of Service) Layer 4 UDDI(Service Discovery) Figure 2.1: Web Services Protocol Stack 25

6 The Figure 2.1 explains about the main constituents or layers of Protocol Stack that contain: Transport Layer carries out messages between various balanced applications. XML Messaging Layer encodes the predefined messages in XML which is understandable to together with client and the server. WSDL Layer explains the service description present for each web service. UDDI Layer central registry which contains list of all the web services available. The primary layer in the protocol stack is transport. This layer is accountable for the genuine transfer of messages between different applications. The most common protocol used is HTTP (Hyper Text Transfer Protocol). The remaining protocols which can be used for transport layer are Simple Mail Transfer Protocol often called SMTP and FTP which is File Transfer Protocol Reason for HTTP extensive practice HTTP is widely used because it goes through Port 80. This port is not blocked by firewalls whereas SMTP goes through Port 25 which is more vulnerable and is blocked by firewalls. Hence HTTP is more widely used for transport of data as it is allowed by Firewalls. HTTP/s is the secure version of HTTP which contains the SSL encoding to provide more security to the messages sent between two systems XML Messaging Layer The second layer is called messaging layer identified in the protocol stack and depends on a unique model of XML. XML is extensively used in applications of web services and the usage of XML for message transfer makes the web services independent of the technology and Operating System used. The XML Messaging specification is a Generalized Specification which can be specified into many other protocols. SOAP is one of the protocols which uses the XML specification, and is widely used in transfer of messages between two communicating parties in web services. 26

7 XML is used to transfer messages between two communicating parties by using HTTP request and response mechanisms by creating XML Documents. SOAP acts as a common Data Transfer Protocol between sender and Receiver. We use SOAP over XML through HTTP Protocol as medium to transfer messages between Systems in Web services WSDL Layer This layer acts as an interface that describes all the available services. It contains information of the functions available in a particular web service and the data types involved in XML message binding of the information and the location of a particular web service. A web service should be published first earlier than it is worn by any client. WSDL uses a common format for publishing and discovery of a particular web service. WSDL more often combined along with SOAP, and the specification of WSDL contains a SOAP binding. Each web service contains an embedded WSDL file which describes about the service and the parameters used in the web service. Actually, WSDL often treated as XML document which is used to define and locate service. It is a recommendation of W3C. Before understanding WSDL we should know about XML, XML namespace and XML schema UDDI Layer This is the final layer in the Protocol stack and is used for publishing of a web service by the service provider and finding of a web service by service consumer. UDDI contains a business registry which enables the service consumers to check for their required service in the registry and then subscribe for it. This is about the protocols used in web services. 2.4 Integration Web services signify a noteworthy new segment in the fruition of software development. Web services usually are different from the web applications in these services contain communication 27

8 between applications, and are not meant for accessing through web browser. All the clients can be written in any lingo where they hold up HTTP and SOAP. Moreover, web services don t have any user interface in common. The integration of web services is difficult because this process involves different message encoding types of SOAP. In order to implement a middleware sometimes we need another middleware view which is Apache web services invocation framework (WSIF). More often, most of the web services development concentrates on SOAP; by providing APIs and allowing the applications to create and receive the messages. Basic Elements of web Services: The fundamental Web services entities are XML and HTTP. Every potential Web Service work through the following constituents together - SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language) These elements in particular are grouped into a single system and enable the correct functionality of web services. UDDI: This is the Centralized Registry which contains the list of available web services. Client uses this UDDI register to find whether the required Web service is available or not. The service Provider can publish new Web services into the Registry. A contract can be established between service provider and consumer and UDDI registry acts as centralized medium to achieve it. Simple Object Access Protocol - SOAP Web service uses a renowned web based protocol called SOAP for transfer of data among various systems. SOAP request and response are encoded in XML. These messages are transported over HTTP/HTTPS. Actually the basic foundation of web services lies in sending and receiving messages in a particular standard message format. And this format is SOAP. A SOAP message is shaped and sent manually. A typical SOAP message consists of an envelope which has two parts: header and a body. Even though the application decides how these categories are used, on the whole the message should follow the XML structure. 28

9 SOAP messages can be bundled together and sent. A framework given in [25] converts many fine grained messages into single coarse grained message. This bundling of SOAP messages increases the performance of web services. WSDL Before using the web service i.e., sending the request as input to the service we have to find the data types of accepted input and parameters of functions in service is obtained by Web service. This WSDL describes the services available in the UDDI registry. The UDDI registry acts as central part of SOA architecture and is integrated into the web services architecture. Integration-how? Hence the Client first looks up the UDDI registry for his required service. If the service is available then he gets the information about the service using WSDL. We can send a SOAP message to a service as the main body of a request of method http POST. In general, Web Service reveals the request of SOAP and transforms into a rule that the predefined application can comprehend. The information is processed by application and generates the necessary response. After that the service bundles this response into the other SOAP message and sends it as response to the client which sent the HTTP request. In this way various components are integrated in web services. Advantages of Web Services 1. Interoperability 2. Taking the converted application to the next level. 3. The application components are reusable. (Reusability) The benefits obtained by using the Web Services along with the challenges faced during development of Web services are explained in [49]. 2.5 XML- Extensible Markup Language It is intended to stock up and transports the data but cannot display the data as html. 29

10 About XML The striking feature of XML is allowing the user to describe his own tags in XML unlike in html. Actually, the XML is the great step in developing the prospective of the web and also the internet. Most of the browsers, just like HTTP (Hyper Text Transfer Protocol) lined the way for the communication between computers. XML is used as standard of communication in Web Services; hence there is a need for development of efficient web services using XML. Step by Step procedure for developing Efficient Web Services Using XML is explained in detail in [31]. Origin of XML Most of the web pages are designed by using elements of HTML. These are called tags. Actually, HTML was derived from SGML (Standard Generalized Mark-up Language). This is an international standard. Similarly, XML contain some capabilities which can be found in SGML. XML Document As HTML contains tags; XML also defines starting and ending tags, but user-defined. We have to remember that XML is a subset of SGML because it confines to the rules and standards of SGML. <?xml version="1.0"?> <mail> <to>ramarao</to> <from>ranjth</from> <Subject>Hi</Subject> <body>come to the college tomorrow by 9 AM</body> </mail> The opening line describes the conceptual version in which every document falls in line up with. The above example is an XML document; it contains a root element mail and four child elements embedded in a root element. Web Services are generally tested by using XML based framework as explained in [35]. 30

11 Tree Structure XML Documents creates a tree structure. Normally, the tree begins at root and then divisions to the lowermost level of tree. <root element> <child element> <subchild element>...</subchild element> </child element> </root element> This is a generalized structure of the above mail XML document. It contains mainly the root child and sub child elements. Proper nesting of tags is necessary to obtain an XML document which is formed well. Well Formed Documents The document of XML with correct syntax is an XML which is called well formed. Usually the DTD is used to describe and conceptually define the legal building blocks of XML Document. More often predominantly with the collection of legal elements and attributes, it defines the basic construction. <!DOCTYPE Mail <!ELEMENT Mail (to,from,subject,body)> <!ELEMENT to (numberpcdata)> <!ELEMENT from (numberpcdata)> <!ELEMENT Subject (numberpcdata)> <!ELEMENT body (numberpcdata)>]> Here PCDATA represents the character data which is parsed, that is text parsed by the parser for entities and markup. XML Schema It is otherwise defined as XML Schema Definition (XSD). <xs:element name="mail"> <xs:complextype> <xs:sequence> 31

12 <xs:element name="end-to" type="xs:string"/> <xs:element name="begin-from" type="xs:string"/> <xs:element name="subject" type="xs:string"/> <xs:element name="body" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> XML schemas are written in XML unlike DTD In the above syntax we take the individual elements of the XML document and specify their data type.for example we stated to, from have String data type. XML Schema support name spaces and Data Types. Many operations are performed on XML schema generally like schema compatibility test, schema minimization etc., these Operations are explained in detail in [30]. XML Schema is also known as Successor of DTDs due to its Structure. XML Validator We can check the syntax of the XML file written by using XML Validator, which is used to verify the exactness of the syntax to get highly accurate error detection mechanisms. XML NameSpace XML Namespaces supply a technique to evade element name conflicts. We can define various elements with same name if provided they are present in different XML documents. But when they are integrated into a single unit then conflict arises when we want to call an element. This conflict can be eliminated by using XML namespace which is normally defined by an acute attribute of xmlns in the beginning tag of an element. The declaration syntax of name space is: XMLns:prefix="URI". The Uniform Resource Identifier (URI) is a group of predefined characters that recognizes a resource from the internet. 32

13 Example: URL- Uniform Resource Locator is used to identify Internet Domain Address. URL S are used to locate a particular website in internet. In general, the namespaces are used in the basic essentials where originally they are being used or sometimes in the root element of XML. Namespaces contain various parts like local names, namespace URIs, prefixes, and declarations. These are explained in detail in [29]. 2.6 Regarding Service-Oriented Architecture Service Oriented Architecture is the basic concept present behind the working of web services. SOA is an environment for dynamic, discovery of services over a network. Services are on the whole the software components with well framed interfaces which are independent of implementation. Here, service consumers interact only with the interface but are not aware of the requests being processed by the web service. In SOA, the services are self-contained i.e., perform prearranged responsibilities and loosely coupled for independence. Actually, the essence of the service is a vital element of the component. Earlier we have used distributed architectures to implement SOA. It is extremely significant to bear in mind that web services are part of SOA. The web services provide us with different benefits and propertiespredominantly independent of platform, loose coupling etc. Generally, service is understood as a unit of work (or) a component which is having the capability of performing a task. In fact, the services are the building blocks to demonstrate different capabilities. According to w3c, SOA is a collection of elementary components which is normally invoked, and the description of the interface can be published and discovered. The concentration of web services lies on the internet based protocols through which the services often be undoubtedly published and predominantly discovered. Essentially, there will be two processes for provider and consumer. For consumer, the process should be in terms of service interface; and for the provider there are different capabilities and issues that are necessary to develop and deliver a particular service, which can be handled in a separate process. 33

14 Service Consumer: Service consumer is an application which requires a particular service for its functionality. Service consumer looks up the UDDI registry to verify whether the service is available or not. Then it finds the location of the service, and across a transport it binds the service and then the service execution by sending the request formatted as request specified in Service Contract. Service Provider: It is the Entity which accepts the requests of the consumers from the network and then executes them. It can be a main frame system or any other Software module. Publishing is done by the service provider, the contract of service in the service registry for access to the consumers. Service Registry: A service registry usually is understood as a centralized directory based on network which contain catalog of all services those are readily obtainable. It is a registry that normally accepts without any delay and usually stores various contracts from providers and supplies this service oriented contracts to large number of consumers who pay attention. It is generally referred to UDDI registry. This register is a very important aspect of SOA. Service Contract: A contract is a conformity connecting the provider and the consumer which specifies the way they interact with each other. It consequently mentions the accepted set-up format of specified request and expected response. In particular the contract should satisfy a collection of predefined conditions and post mentioned conditions. The pre and post defined conditions denote the situation in which the so called service should be able to execute precisely a function and appropriately as required by the user. The contract sometimes also relies and contains quality of service (QOS) indication. For Example, an attribute called quality of service which talks about the quantity of period of time it takes to accomplish a service method. The quantity of total time taken to carry out a particular method is the measure of quality which is widely used in various cases. 34

15 So the Service Consumer must discover the Service and then manage it efficiently i.e., making service respond to user in given time. An Approach For efficient Discovery and Management of SOA Applications is discussed in detail in [28]. 2.7 SOAP SOAP is a protocol which was developed by IBM and Microsoft to make easy communication between client and server by using HTTP protocol for the invocation of remote objects. SOAP is extremely supple and can bear different applications. Definition: SOAP is a protocol which is based on platform element like XML and also on protocol which is of internet-based like HTTP to retrieve a particular service, objects and servers in a platform independent behavior. [Source: SOAP-project paper by Jack Koftikian from TUHH]. SOAP more often considered as an object invocation protocol particularly to swap or to interchange the data seriously in a disseminated environment. Encoding of SOAP messages as XML documents. SOAP is highly flexible and can support different applications; It is used to enable remote procedure calls (RPC) via HTTP that uses XML. Why SOAP is used Over HTTP? The difficulty with the so called internet-based protocol like HTTP is in particular that it is mostly a method for transient the files appropriately from a reliable server to authenticated client and is extensively used in client server architecture systems. To create more complex Web services, HTTP is not enough and SOAP is used as it extends the functionality of the web service. SOAP contains a collection of intangible HTTP headers and also a large XML predefined payload in order to build composite and critical application-to-application contact across the web. 35

16 Example - SOAP Request The example mentioned below is about sending an area code to the server. Request has an area code parameter and response has two parameters - Gold Price and Purity. The function s namespace is defined in " This XML Document is generated by TANISHQ a gold retailer which operates on nationwide. POST /InGoldPriceHTTP/version1.1 host: Content-Type: applicationdef/soapmess+predefxml; charset=utf-8 <?xml version=1.0?> <SOAP:Envelope XMLns:SOAP=" SOAP:encodingStyle=" <SOAP:body XMLns:mess=" <mess:getgoldprice> <mess:areacode>12292</mess:areacode> </mess:getgoldprice> </SOAP:body> </SOAP:Envelope> Example - SOAP response HTTP/v OK Content-Type: applicationdef/soapmess+predefxml; charset=utf-8 <? xml version=1.0?> <soap: envelope XMLns:SOAP=" soap:encodingstyle=" <soap:body XMLns:mess=" <mess:getgoldpriceresponse> <mess:price>rs.10500/gm</mess:price> 36

17 <mess:purity>23.1 K</mess:Purity> </mess:getgoldpriceresponse> </soap:body> </soap: envelope> Like this the SOAP message request and response are sent which are encoded in XML and are transported through HTTP. SOAP request and Response and usage of SOAP for Remote Procedural Calls (RPC) are explained in detail in [26,27]. 2.8 Web Services Description Language - WSDL This is a kind of language based on XML which is used particularly to describe web services and explains the procedure for retrieval of these services. About wsdl This is used to define XML grammar and in order to describe communications in web services in a structured and standard way. In general a WSDL document always distinguish and explains the services as group of endpoints or ports which are based on a reliable network and is independent of message format and protocols used for communication. Steps for creation of a WSDL file for a service is described in detail in [38]. Structure of WSDL Document The WSDL Document structure is defined as: <definitions> <types> type definitions are those which explains about the data types which are utilized by services </types> <message> message definition...specifies the messages which are utilized by a web service </message> <porttype> port definition...specifies the Operations performed by a service </porttype> 37

18 <binding> binding definition...specifies the interaction abstract protocols which are utilized by a service </binding> </definitions> The structure of the WSDL document, Common mistakes made while writing a WSDL document and guidelines to revise these errors are explained in detail in [37]. WSDL Message A WSDL message contains the following components to describe Web Services: Types contain definitions of data types through a type of structure like XML Schema Definition. Message The information which is to be transported. Operation A type of action which is supported and implemented by a web service. Port Type a set of predefined operations supported by one or more active endpoints. Binding Specifies Data Type and protocol intended for a specific port type Port An end point which is Collection of scheduled binding specifications and address of network. Service is a set of associated End points. The element types itself contains relevant data type definitions for messages which are being exchanged. It is not required to use the XSD specification but generally it is preferred. WSDL functionality, semantics and relation with XML schema are further explained in [36,49]. Types of Operations Operations are mainly classified into 4 categories: One-way: The active endpoint predominantly receives an active incoming message. Request-response: The active endpoint on the other side receives an active message as request and then sends a associated live message as response Solicit-Response: The end point normally sends a live message as request and then receives a associated message as response. Notification: The active endpoint that sends a live message keep up a mark that the message has been sent. 38

19 2.9 Parsers Parser is like a Compiler which is used to parse XML messages. Parsing is nothing but division of compound structures into their basic individual slices. Parsers generally take a conceptual string which is serialized as unrefined input parameter and then perform a group of operations Parser Operation First XML Document is verified for syntax errors, then it is checked whether it is well formed or not. Then starting and ending tags are verified whether they are properly matched or not. Then If in DOM a tree is generated, where as in SAX, the code is interpreted while it is being read without waiting for entire document to be read Types of parsers There are three types of XML parsers in java. They are: 1. The Document Object Model - DOM 2. The Simple API for XML - SAX 3. The Streaming API for XML - StAX These parsers perform validation of syntax and schema of the XML document.these different types of parsers are explained in detail in [39,40] DOM We require a DOM parser in order to parse the XML from strings to DOM trees. DOM Parser permits you to access any active slice of the related document frequently and alter even the structure of the DOM tree. Parsing with DOM sometimes depends on a structure of tree and often constructs the whole structure of the tree accurately in the memory. The DOM parser represents the XML Document in the form of tree and it contains a root node which is parent to the entire document and series of child nodes. Root element maintains a catalogue which contains a set of elements. The elements present in this catalogue contain derived nodes often called children and can be utilized as conceptual elements. 39

20 2.9.4 SAX We can also parse XML with SAX. The internal structure cannot be created by a SAX parser. But it often receives the number of times of elements of a raw input file as events, and informs the authenticated client and explains what it wants to read. Parsing with SAX depends on the flow of events and it is purely a model which based on events to process the documents of XML. Even if it is not an official recommendation by W3c it is so popular and is used in various applications for parsing. The DOM parser reads the entire Document and then generates a tree in memory where as SAX reads the XML code line by line and generates events and forwards it to different handlers that manage events. Event handlers supply admittance to data. There are 3 different categories of handlers: 1. DTD handler- often used to access the information. 2. Error handler - which is used to access the errors. 3. The abstract Content handler - often used to access the content. These are the 3 event handlers used to handle various things like content, data and errors Primary differences between DOM and SAX 1. DOM parser creates a tree in memory but a SAX parser doesn t waste memory. 2. DOM parser reads the entire document, so it is considered slow when compared to SAX which processes the code and serves the client by generating events from pieces of data without wasting time, waiting for the entire document to be parsed. 3. DOM parser is well-to-do in its functionality but is space inefficient when the document is large. In general the type of parser which is more efficient depends upon the type of application. Other than these we have parallel approach for XML parsing which helps to get significant increase in XML parsing performance as shown in [41] UDDI The UDDI describes a typical technique to publish and discover the components of software of a SOA via network. A UDDI registry is used for representation of data and Metadata about Web services. Meta data is data about data which is self explanatory. 40

21 A registry can be used on a public network or within an organization to identify a web service and then access the web service by consulting the service Provider. This registry contains a list of all available web services. The service consumer uses find and bind mechanism to find particular web service and invoke it. The service provider enters the new web services into the registry by publish mechanism. We can also specify the information about web services even also by UDDI. It also specifies the required parameters which act as input for the service to function properly. WSDL is used by UDDI to explain interfaces in relation to the services. In general the UDDI Registry is used to find the required service by the Service Consumer regularly. The method of publishing interoperable services and processes in UDDI Registry so that with this the collaborative business processes can be discovered easily is explained in [42]. Evolution of UDDI: UDDI Version Year of release Objective Establishment for Registry of business services based on internet Released in OASIS guidance. It contains the Align Specification and supplies bendy Service classification with rising Web Service standards Supports safe and sound communication of Private and public activities as major constituent of Service Oriented communications. It is released by OASIS in the year Table 2.1 Evolution of UDDI In total there are 3 versions of UDDI. This is shown in table 2.1. UDDI version 1.0 contains the basic registry details and its structural specification to be followed for business services based on internet. UDDI version2.0 contains the Align 41

22 specification and Service description. And UDDI version3.0 contains the features of previous versions along with extended security to interfaces. In addition to the above 3 versions of UDDI, UDDI is new extension to UDDI Registry which enables the registry to be more dynamic and makes the discovery of a required service easier. UDDI is explained in detail in [43]. Example: The below example states UDDI registry which contains all the Gold rates with an interface provided to interact with the service provider. UDDI registry is used for Gold rate checking and purchase; Gold merchants often register their predefined services regularly into an UDDI directory. Local gold dealers thereafter search the so called UDDI directory to identify the gold purchase related interface. When the same is identified, the local gold dealer may exchange a few words with the web service instantly because it regularly uses a well-framed and welldefined self-optimized gold purchase interface Trees Usually a tree structure is formed and created by XML documents. It contains root elements and Child elements. XML documents should hold a root element. This element is considered as parent to each and every other element. The tree structure contains a root node and branches which contains leaves. The XML document elements will shape a document tree. The tree gradually elaborates from root node to all child nodes. We need to remember that each element can contain its own sub-elements. General Tree Structure The general Tree structure for an XML Document is: <root-element> <child-element> <subchildelement>...</subchildelement> </child-element> </root-element> 42

23 To describe the relationship between various elements the terms Parent, Child, Siblings are used. Child element is the sub-element to a parent element. The parent element is not included in the root element. The elements which are present in the same level are called siblings to each other. Example: Include tree structure of clothshop which is mentioned in the code below: Root element <Clothshop> Attribute: lingo Parent Element: <shirt> Child Attribute: kind Element:<brand name> Siblings Element:<color> Element:<type> Element:<price> Transcript:Lee Cooper Transcript:White Transcript:Ready made Transcript: Figure 2.2 Structure of Cloth Shop The above Figure2.2 is the representation of a shirt in the XML below: <clothshop> <Shirt type="formals"> <Brandname pricetype= medium >Lee Cooper</Brand name> <Color>white</Color> <type>readymade</type> <price>700</price> </shirt> 43

24 <shirt type="casuals"> <Brandname pricetype= High >Levi Strauss</Brand name> <Color>Black</Color> <type>readymade</type> <price>1290</price> </shirt> <Shirt type="partywear"> <Brandname pricetype= High >Park Avenue</Brand name> <Color>Violet</Color> <type>readymade</type> <price>1400</price> </shirt> </clothshop> Here, the root element is <clothshop>. All <shirt> rudiments particularly in the document packaged under <clothshop>. The <shirt> component normally have 4 children: <brandname>,<color>, <type>, <price>. This is the tree structure of the XML document. Step Wise Procedure for Generating tree structure of an XML Document is explained in detail in [44] SOAP A Review SOAP ENVELOPE Head Body Figure 2.3: SOAP Envelope 44

25 According to James Snell, Doug Tidwell and Pavel Kulchenko [45], SOAP (Simple Object Access Protocol) message often considered as an XML document which contains a component based SOAP envelope, a discretionary SOAP header, and finally a fixed SOAP body. This is shown in Figure 2.3. SOAP and its Envelope The first constituent of the so called XML document is envelope which represents SOAP message. Envelope is compulsory to every SOAP message. Envelope generally contains Header and Body elements. The SOAP envelope may contain name space declarations and attributes which are optional. They must be qualified by the name space which is compulsory. SOAP Envelope is important part in every SOAP message and its importance is explained in [27]. SOAP and its Header The element called header is a method to mess up with different features to an active SOAP message with no preceding concord between the parties that communicate. Header in SOAP envelope may be optional or mandatory. If this part is optional, immediately it should be presented to child element which is more often to the SOAP Envelope. The header usually contains a collection of entries which are immediate to child elements to the header element and are qualified by name space. SOAP Body The Body element stores the information which is sent to final recipient of the predefined message. Body of SOAP message is mandatory in every message. If element called header is optional and then element body should be the next child element to the element-envelope. If the element-header is at hand then body element must be placed right after the header element in SOAP envelope. The body contains a group of identified entries which are considered to be the next child elements to the element-body and are namespace-qualified. 45

26 Syntax <?xml version=1.0?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <SOAP:Header>... </SOAP:Header> <SOAP:Body>... <SOAP:Fault>... </SOAP:Fault> </SOAP:Body> </SOAP:Envelope> 2.13 Web Services and its functional testing The services in particular established by a renowned company, used by some other company and maintained by the third company. Thus web services bring several companies to interact with each other. Web services are used to transfer data between Heterogeneous distributed systems over network independent of the language used to develop the web application, and the underlying operating system. Due to the above two reasons web services have gained significance over other technologies like DCOM/CORBA. DCOM and CORBA are used when two homogenous systems are used for communication through network. These are faster than web services in case of homogenous systems but they fail when we use heterogeneous systems, hence web services came into existence. Functional Testing So the functional testing of web applications using web services is one of the methods to test the web applications. In general Web applications are large in size and source code may not be available always to test them using the White box testing mechanism. Hence, the concept of 46

27 Black box testing sometimes considered and may be used to test the web application by considering the functions present in it. Black box testing is used for testing the superficial functionality of various methods present in web service unlike White Box testing which checks the internal details of the methods. Black box testing is also called Functional testing. In functional testing various inputs are given to the function and its outputs are analyzed to check the correct functionality of the system. Sometimes, integration testing can also be done with the help of a selenium tool [74] that tests automated web applications. Steps in Functional Testing The various steps used in Functional testing of a web application [18] are: 1. The recognition of all the functions where the software is likely to carry out. 2. The design of put in information depending on the specifications of the functions. 3. The grit of the productivity depending on the specifications of the functions. 4. The test case execution. 5. The assessment of actual and expected and noted outputs and their comparison. Hence by comparing this actual output with expected output we check whether the function works correctly or not. We repeat the procedure for various random inputs to get accurate results. Functional Testing Method As web services [50] are Stateless protocol we ll be able to set up autonomous test cases so as to divide files. We can use a Generator Tool which returns a test case randomly and sends it as input. Test cases are written as separate files in XML. How to prepare XML test files Retrieve an example XML file which is secured from a developer of software in order to give entry to the elements as input parameters, generally it is WSDL File. The only difference between Functional Testing and GUI testing is to register the data into a set of fields of secured XML document instead of set of fields of an abstract GUI. 47

28 Automated Tool for Test Generation After preparing these test cases we place all of them in an automated tool. This tool randomly gives a test case as output in which we enter the data fields and sends it as request using HTTP Post method. The response to the above said request is verified to verify the performance of the web service. An Automated Tool for Functional Test Generation for semantic Web services is explained in [47]. Verification of Response Then we have to capture the HTTP response and store it in a file. Now this obtained response and expected response are compared to check the functionality of a particular method in web application. In this way by testing all the methods present in web application, we test the web application using functional testing methodology Conclusion The main goal of web services is to convert an application into a web application. Keeping this in mind an architectural style called SOA is designed. The web services provide different benefits and properties which enable the user to understand the messaging structures and frameworks. In this chapter, we presented different aspects of SOAP messaging formats which includes envelope. The idea of UDDI and also how this service registry holds on service description and other information which was scattered in three different versions of UDDI is also explained in this chapter. The functional testing plays a vital role in the environment of web services. The steps involved in making this testing possible are also presented. 48