Anda di halaman 1dari 10

Tunku Abdul Rahman College

Advanced Diploma in Science AACS5274 Web Services


Tutorial 4

1.

What is the purpose of SOAP? Briefly describe how SOAP provides inter-application communication. Answer: Purpose: to exchanging data over networks. SOAP, an XML-based communication protocol for exchanging messages btw computers regardless of their operating systems, programming environment, or object model framework. SOAPs primary application is inter-application communication. It codifies the use of XML as an encoding scheme for request and response parameters using HTTP as a means of transport. In particular, SOAP is simply an HTTP request and response that complies with the SOAP encoding rules.

2.

Define wire protocols and describe the characteristic of the wire protocol. Answer: Wire protocol (specifies the form and shape of the data to be exchanged between disparate applications and eventually systems) Transport protocol (is a method that data is transferred from system to system, is responsible for taking its payload from its point of origin to its destination.) SOAP commonly uses HTTP to transport XML-encoded serialized method argument data from system to system. This serialized data argument data is used on the remote end to execute a clients method call on that system, rather than on a local system. Compactness

Protocol efficiency Coupling

Scalability Interoperability

Refers to how terse a network package becomes while conveying the same information. Small degree of companies is the best. examine the overhead required to send the payload. the more overhead required, the less efficient the protocol is. Is the rate at which the client application needs to adapt to changes. loosely coupled protocols are quite flexible and can easily adapt to changes, while tightly coupled require significant modifications to both the server and the existing clients. the ability of a protocol to work with a large number of potential recipients. the ability of the protocol to work with a variety of computing environment platforms.

3.

Describe how SOAP processes distributed applications. Answer: Distributed application processing with SOAP can be achieved in terms of basic steps Page 1 of 10

illustrated in figure 4.3: A service requestors application creates a SOAP message as a result of a request to invoke a desired Web service operation hosted by a remote service provider. (XML document containing information needed, i.e. the location and its arguments, is created by SOAP to remotely invoke the method) service requestor forwards the SOAP message together with the providers URI. The network infrastructure delivers the message to the message providers SOAP runtime system (e.g a SOAP server). The SOAP server is simply special code that listens for SOAP message and acts as a distributor and interpreter of SOAP documents. The SOAP server routes the request message to the service providers Web service implementation code. (conversion of the XML documents received to programminglanguage-specific objects required by the application implementing WS, i.e. at providers site.) The Web service is responsible for processing the request and formulating a response as a SOAP message. The response SOAP message is presented to the SOAP run-time system at the providers site with service requestors URI as its destination. The SOAP server forwards the SOAP message response to the service requestor over the network. The response message is received by the network infrastructure on the service requestors node. The message is routed through the SOAP infrastructure, converting the XML response into objects understood by the service requestors application.

Web service requestor

Client Client application application


4. List and describe the elements in a SOAP message. Answer: A SOAP message consists of an <Envelope> element containing an optional <Header> Page 2 of 10

and a mandatory <Body> element.

<Envelope>: Purpose: to provide a uniform way to transport messages between two end-points. Job: to wrap XML document interchange and to augment the payload with additional information thats required to route it to its ultimate destination. In fact, <Envelope> element defines a framework for describing what is in a message and how to process it. All elements of the SOAP envelope are defined using W3C XMLschema. Rule: ALL conforming messages are using exactly the same namaspace and XML schema, therefore same processing rules, otherwise, fault is generated. <Header> Only one <Header> child element immediately from <Envelope> element. Content: all the processing hints that are relevant for the endpoints or intermediate transport points. (information about where to send, where its originated, may carry digital signatures) Purpose: to encapsulate extensions to the message format without having to couple them to the payload or to modify the fundamental structure of SOAP. (e.g. security, transaction, object references, billing, QoS attributes can be added.) This allows for WS client to place extra data in the header of the message so that every single method call on that service does not have to accept that data as argument. For example, header information can be used to supply authentication credentials to a Web service rather than requiring username and password for every single call. <Body> The SOAP body is the area of the SOAP message where the application-specific XML data (payload) being exchanged in the message is placed. It can be empty or contained body entries (content). <Body> element contains either the application-specific data (information that is exchanged with a WS) or a fault message. A fault message is used only when an error occurs. i.e. processing error or a message thats improperly structured. 5. What do you understand with the mustUnderstand attribute in SOAP Header? Answer: env:mustUnderstand attribute determines further processing actions that have to be taken. (avoid SOAP nodes to ignore header blocks) With a value of true or 1, indicates that the node(s) processing the header, must absolutely process these header blocks. With value of a false or 0, indicates NOT processing the message or report a fault.

Page 3 of 10

6.

Describe the two SOAP communication models. Answer: SOAP supports two possible communication styles: RPC-style communication Document-style communication RPC-style communication: An RPC-style Web service appears as a remote object to a client application. A client expresses its request as a method call with a set of arguments, which expects a return value (response value).

Document-style communication: Document-style Web services are message driven. When a client invokes a message-style Web service, the client sends it an entire document, i.e. purchase order instead of a set of parameters. Page 4 of 10

<env:Envelope xmlns:SOAP=http://ww xmlns:m=http://www.p <env:Header> <tx:transaction-id xmlns:tx=http: <env:Envelope env:mustUnderst xmlns:SOAP=http://ww 512 xmlns:m=http://www.p </tx:transaction-id <env:Header> </env:Header> <env:Body> </env:Header> <m:GetProductPrice> <env:Envelope <env:Body>

<po:to> <po:supplie

<po:supplie

7.

With the aid of a diagram, describe how a SOAP intermediary validates a purchase order in a messages path from a customer node (initial sender) to the purchasing order service (ultimate receiver). Answer:

</po:to> <po:product> <po:product

Page 5 of 10

<po:product

Ultimat e receiver

Purchasing service node

8.

Process purchase order Briefly describe the error handling in SOAP.

The purchasing service node validates that the purchase order was indeed send to it by a particular customer. The intermediary verifies that the customers digital signature header block embedded in the SOAP message is actually valid. The SOAP message is automatically routed to the intermediary node (digital signature service), which extracts the digital signature from the SOAP message, validates it, and adds a new hear block telling the purchasing service whether the digital signature is valid.

Answer: SOAP provides a model for handling situations when faults arise in the processing of a message. It is able to signal the fault to the originator of the faulty message or another node. Fault information will place in <Body> element. <env:Fault> is predefined element for transporting structured and unstructured information about the problems that have arisen during processing. The <env:Fault> element contains 2 mandatory sub-elements; <env:Code> and <env:Reason>, and an optional <env:Detail> sub-element.

<env:Code> sub-element contains <env:Value>, a no. of standardized fault codes in the form of QNames, and <env:Subcode>, is the cause of the failure to process the request, sub-elements. <env:Reason> sub-element contains a human readable description that gives an account of the fault situation. <env:Detail> sub-element contains application-specific error information, generally generated understood by all SOAP nodes.

9.

Discuss the advantages and disadvantages of SOAP. Answer: Advantages: Simplicity: SOAP is simple as it based on XML, which is highly structured and easy to parse. Page 6 of 10

Portability: SOAP is portable without any dependencies on the underlying platform like byte-ordering issues or machine-word widths. Firewall-friendly: posting data over HTTP means not only that the delivery mechanism is widely available but also that SOAP is able to get pass firewalls that pose problems for other methods. Use of open standard: SOAP uses the open standard of XML to format data, which makes it easily extendable and well supported. Interoperability: SOAP is built on open, rather than vendor-specific, technologies and facilitates true distributed interoperability and loosely coupled applications. Universal acceptance: SOAP is the most widely accepted standard in message communication domain. Resilience to changes: Changes to the SOAP infrastructure will likely not affect applications using protocol.

Disadvantages: SOAP was initially tied to HTTP and this mandated a request/response architecture that was not appropriate for all situation. HTTP is relatively slow protocol and of course the performance of SOAP suffered. SOAP is stateless. The stateless nature of SOAP requires that the requesting application must reintroduce itself to other applications when more connections are required as if it had never been connected before. Maintaining the state of a connection is desirable when multiple Web services interact in the context of business processes and transactions. SOAP serializes by value and does not support serialization by reference. Serialization by value requires that multiple copies of an object will, over time, contain state information thats not synchronized with other dislocated copies of the same object. This means that currently it is not possible for SOAP to refer or to point some external data source in the form of an object reference.

10.

Describe the role of the SOAP intermediary in context of the SOAP message transmission. Give TWO (2) examples of the functions served by the intermediary. Answer:

SOAP intermediaries are applications that can process parts of a SOAP message as it travels from its origination point to its final destination point. (4 marks) Intermediaries can both accept and forward SOAP messages. (2 marks) Example 1: providing security as the message passes across trust domains (2 marks) Example 2: Providing value-added services such as providing message-tracing facilities. (2 marks) 11.
Examine the SOAP message below, Figure 3.2: <SOAP-ENV:Header> <t:Transaction xmlns:t="www.xmlbus.com" SOAP-ENV:mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> Figure 3.2 Must the SOAP node process the SOAP block according to the requirements of the header? Explain the purpose of this attribute. Page 7 of 10

Answer: The SOAP node must process the block according to the requirements of the header since the mustUnderstand attribute equals 1. This attribute allows older applications built using the older versions of SOAP to fail gracefully when they receive a message that they do not understand.

12.

(a)

UserLand, DevelopMentor, and Microsoft have developed and published a Simple Object Access Protocol (SOAP) specification on the Web. SOAP is typically designed to provide an independent, abstract communication protocol which is capable of bridging two or more businesses and it is also used to define a messaging framework for exchanging formatted XML data across the Web. The authors of the SOAP specification intended to keep the specification simple and small. (i) What is the rationale for keeping the SOAP specification simple and small? Answer: To ensure that a basic level of functionality would be supported in all SOAP implementations and that higher-level functionality could be built on a common basic protocol.

(ii)

Define the elements of the SOAP specification as it is used to provide a common XML messaging protocol for the Web. Answer: The start and the end of an envelope that encloses the XML document to be transported. How to represent any optional headers for additional information, including pointers to additional schemas associated with the document, such as security, transaction coordination, and so on. How to serialize data type encodings optionally over the wire, with specific support for RPC-style interactions. A binding to HTTP to ensure that it carries the document correctly to its destination and that the destination directs the message to an appropriate SOAP processor. To ensure elements and attribute names dont clash, the envelope elements and the encoding rules are defined using different namespaces. SOAP syntax blocks may be implemented individually or entirely and processed by separate handlers associated with each. SOAP specification is defined a layered approach, it can be used in combination with other transports.

(b)

Write the SOAP request and response message based on the following information: Input Parameters staffID itemCode quantity Output Parameter totalPrice Note: Date Type string integer integer Date Type double

A SOAP request sends three parameters, staffID, itemCode, and quantity with corresponding data types, to a Web service.

Page 8 of 10

The Web Services will return the totalPrice as a SOAP response message. Use a getTotalPrice body and its targeted www.morrisan.com/calculatePayment. An XML namespace is names. SOAP Header elements SOAP message. Answer:
<SOAP-ENV:Envelope xmlns:SOAP-ENV=http://www.w3.or/2001/12/soap-envelope> <SOAP-ENV:Header> <SOAP-ENV:Body> <m:getTotalPrice xmlns:m=www.morrisan.com/calculatePayment> <staffID> *anyStringTypeValue </staffID> <itemCode> * anyIntegerTypeValues </itemCode> <quatity>*anyIntegerTypeValues</qualtity> </m:getTotalPrice> </SOAP-ENV:Body> </SOAP-ENV:Header> </SOAP:ENV:Envelope> <SOAP-ENV:Envelope xmlns:SOAP-ENV =Http://www.w3.or/2001/12/soap-envelope> <SOAP-ENV:Header> <SOAP-ENV:Body> <m:getTotalPriceResponse xmlns:m=www.morrisan.com/calculatePayment> <totalPrice>*anyDoubleTypeValue</totalPrice > </m:getTotalPriceResponse > </SOAP-ENV:Body > </SOAP-ENV:Header> </SOAP-ENV:Envelope>

as a SOAP requests name within the URL is required to qualify application-specific element and Envelope namespace are required on the

Page 9 of 10

(c)

When an error occurs during processing in Q12 (b), the response to a SOAP message is a SOAP fault block in the body of the message and the fault is returned to the sender of the message. List and briefly describe sub-elements of the SOAP fault body block. Answer:

<faultcode>: a software-generated XML qualified fault namequalified as either Sender or Receiver, depending on whether the message was found to be incorrect on receipt or an error occurred during processing of the message. <faultstring>: associated with the fault code, an explanatory text that describes the problem, similar to the ReasonPhrase defined in HTTP. <faultactor>: a URI (Uniform Resource Identifier) identifying the address of the SOAP processor that generated the fault. <detail>: application-specific information about the fault, required when the message could not be successfully processed.

Page 10 of 10

Anda mungkin juga menyukai