Вы находитесь на странице: 1из 8

Introduction

SOAP (originally defined as Simple Object Access Protocol) is a simple XML-based protocol that lets applications exchange information over HTTP. It supports two possible communication styles: function/RPC and document style.

Question 1
Remote Procedure Call (RPC)-style web services RPC-style services are tightly coupled and interface-driven, which means that the business methods of the underlying implementation determine how the Web Service works. The client invokes the Web service, sends parameter values to the Web service, which executes the corresponding methods and sends back the return values. The relationship is synchronous, which means that the client waits for a response from the Web service before it continues with the reminder of its application. They are typically process-oriented. Modern Unclassified Guide (MUG) can use this style to track the number of completed adverts in a given month (e.g. April) from the design agencys database as shown in Figure 1.1.
Web Services Interface Total Adverts for April Request Applications Programs or Stored Procedures

Database

Total Adverts for April Response

Figure 1.1 RPC-style interaction for brief data exchanges

Document-style (Message-style) web services Document-style services are loosely coupled and document driven. They are characterized as asynchronous with the potential for highly complex document structures. The client sends the parameter as an XML document to the Web service, which receives the entire document, processes it and may or may not return a response. They are typically data-oriented. MUG can use this style to send the basic data required for the advert as an XML document to the design agency. They may receive an e-mail acknowledgement from the design agency as they wait for the final document to be completed as shown in Figure 1.2.
Request for Advert design document Web Services Interface Business Process Flow Receive E-mail Acknowledgment

Check Database Design

Advert Document

Send

Figure 1.2 Document-style interaction for bulk data exchanges

A SOAP message is encoded as an XML document, consisting of an/a elements: Envelope: (Mandatory) - that identifies the XML document as a SOAP message. Header: (Optional) - that contains header information. Body: (Mandatory) - that contains call and response information. Fault: (Optional) - that contains errors and status information.

The MUGs RPC-style request and response messages used to track the number of completed adverts for the month of April from the design agencys database is shown in Figures 1.3, 1.4 and 1.5.
SOAP envelope SOAP body Method name GetTotalAdverts Input parameter 1 April Input parameter 1 Quantity SOAP envelope SOAP body Method return Return value Total Adverts

Figure 1.3 RPC-style SOAP message

<env:Envelope xmlns:SOAP=http://www.w3.org/2003/05/soap-envelope> xmlns:m=http://www.advertdesign.com/advert-list> <env:Header> <tx:Transactions-id xmlns:t=http://www.transation.com/transactions env:mustUnderstand=1> 0512 </tx:Transaction-id> </env:Header> <env:Body> <m:GetTotalAdverts> <month-name>April</month-name> <advert-total>Quantiy</advert-total> </m:GetTotalAdverts> </env:Body> </env:Envelope> Figure 1.4 RPC-style SOAP body

<env:Envelope xmlns:SOAP=http://www.w3.org/2003/05/soap-envelope xmlns:m=http://www.advertdesign.com/advert-list> <env:Body> <m:GetTotalAdvertsResponse> <total -adverts>50</total-adverts> </m:GetTotalAdvertsResponse> </env:Body> </env:Envelope> Figure 1.5 RPC-style SOAP response message

The MUGs Document-style request message used to send the basic data for the advert layout as an XML document to the design agency is shown in Figure 1.6 and 1.7.

SOAP envelope SOAP body

SOAP envelope SOAP body

Advert design document

Acknowledgement Completed advert document

Figure 1.6 Document-style SOAP message

<env:Envelope xmlns:SOAP=http://www.w3.org/2003/05/soap-envelope> <env:Header> <tx:Transactions-id xmlns:t=http://www.transation.com/transactions env:mustUnderstand=1> 0512 </tx:Transaction-id> </env:Header> <env:Body> <po:PurchaseOrder orderMonth=2012-05 xmlns:m=http://www.advertdesign.com/adverts> <po:from> <po:accountName> ModernUnclassifiedGuide</po:accountName> <po:accountNumber> MUG-0343-12</po:accountNumber> </po:from> <po:to> <po:supplierName> Advert Design Ltd. </po:supplierName> <po:supplierAddress> Strubens Valley Rooderpoot </po:supplierAddres> </po:to> <po:advert> <po:advert-name> nandis weightloss </po:advert-name> <po:advert-type> weightloss </po:advert-type> <po:advert-qty> 4 </po:advert-qty> </po:advert> </po:PurchaseOrder> </env:Body> </env:Envelope> Figure 1.7 Document-style SOAP body

Question 2
Web Services are software components that can be published, located, and run over the Internet using XML. The following technologies form the foundation of the Web Services standard:

Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems and is the foundation of data communication for the World Wide Web. eXtensible Markup Language (XML) is a set of rules for defining and representing information as structured documents for applications on the Internet. Simple Object Access Protocol (SOAP) is an XML-based protocol for exchanging information in a distributed environment. Web Services Description Language (WSDL) is an XML-based language for describing Web Services and how to access them. Universal Description Discovery and Integration (UDDI) is an XML-based standard for describing, publishing, and finding Web services.

The Standard bodies involved in Web Services are: World Wide Web Consortium (W3C) for XML, SOAP, WSDL and The Web. Internet Engineering Task Force (IETF) for TCP, HTTP, TLS. Organization for the Advancement of Structured Information Standards (OASIS) for UDDI. Web Services Interoperability Organization (WD-I) for interoperability rules.

These standards work together as layers on the web services protocol stack as shown in Figure 2.1.

Web Services Protocol Stack Layer 4 - Service Discovery (UDDI) Layer 3 - Service Description (WSDL) Layer 2 - Messaging (XML and SOAP) Layer 1 - Transport (HTTP) Figure 2.1 The four-layer model of the Web Services Protocol Stack

The service transport layer between applications (HTTP). The messaging layer that provides a common communication method (XML and SOAP). The service description layer that describes the public interface to a specific web service (WSDL). The service discovery layer that provides registry and repository services for storing and retrieving web services interfaces (UDDI).

Web services have become the de facto standard for implementing Service Oriented Architecture (SOA). SOA is an architectural style for building software applications that use services available in a network such as the Web. Figure 2.2 shows how SOA organizes Web Services into three basic roles: service provider, service registry, service requester. These roles interact using publish, find and bind operations.

UDDI Service Registry Provide Service Description WSDL WSDL WSDL

Find Services Service Requester Exchange XML based messages Invoke/Bind (SOAP over HTTP)

Publish Service Description Service Provider Exchange XML based messages

Figure 2.2 SOA realized with Web Services

Organizations within the advertising industry can take on one or all of the following roles: Service provider publishes the Web service using WSDL to an UDDI service registry and making it available on the Internet for the requests of the consumers. Other advertising newspapers, print on demand newspaper companies, advertising and design agencies and online small ads websites would use these standards to widen the circulation of adverts placed with MUG. MUG would also use the standards to publish its services to the local businesses that need to place adverts with its newspaper. Service requester finds the required service by querying the service registry UDDI, binds with the service at the service provider and then invokes the service using SOAP. MUG would search the service registry for various service providers e.g. advertising and design agencies who offer when offering cheaper services covering wide geographical areas. Service registry acts as a service broker and provides a searchable repository UDDI of service descriptions where service providers publish their services and service requesters find services and obtain binding information for these services.

Benefits of Web Services standards Strategic Web services expand the amount and kind of data the trading partners can exchange. This enhances the collaborative activities among trading companies, allowing them to participate in a dynamic business relationship where mutually beneficial information can be shared. They allow companies to sell their internal service applications to other companies needing similar services, thus generating new revenues. By unlocking business information from inside each information silos within a company, web services can expand the value of goods and services delivered to its customer, or create new products and services. Infrastructure Web services decouple service interfaces from implementations and platform considerations, while supporting an industry-agreed common method to access resources across heterogeneous networks and systems.

They integrate previously incompatible computer systems, achieving better data integration and allowing applications to be shared internally and externally. Through web services integration, companies can streamline the middleware technologies that they employ, and reduce the number of proprietary interfaces in the disjoint systems, providing a cost efficient way to integrate many computing resources at the applications level. Operations With Web services applications developed for one project may be usable as a plug-and-play architecture by another project, ending duplication of software code in different groups or systems. Because they are loosely couple services by nature, companies can tinker with applications without major changes to the interface, thus avoiding affecting other systems or applications. Companies using can easily outsource processes deemed as non-core to outside providers offering the same services. The can dynamically choose providers and applications best suited to their needs on a real-time bases, reducing the risk of bad sourcing decisions. Web services can be deployed to help integrate different systems from multiple acquired companies going through mergers and acquisitions. Conclusion Question 3 SOAP supports four modes of messaging: RPC/Literal Document/ Literal RPC/Encoded Document/Encoded

The WS-I Basic profile 1.0 permits the use of RPC/Literal or Document/Literal only. The RPC/Encoded and Document/Encoded are explicitly prohibited. I would recommend using SOAP with Document-literal approach for exchanging data. SOAP benefits It is the standard messaging protocol used by Web services. It is simple as it uses XML that is well structured and easy to parse. It uses the HTTP protocol which is capable of getting past firewalls which totally block other protocols. It relies on open instead of vendor-specific technologies and thus enables distributed interoperability and loosely coupled applications. It has received an official recommendation by the World Wide Web Consortium (W3C).

Document-literal style benefits Interoperability Document style message provides interoperability and is recommended by WS-I. Some Web services frameworks, including MS.NET, generate a document message style message using literal encoding. Loosely Coupled There is more flexibility to change business documents without affecting all serviced users. State Maintenance

If the stubs generated by a toolkit cannot maintain state, then document style can be used to pass the contents of an entire transaction as an XML document. The service implementation can then ensure the processing sequence and maintain state in the execution of that sequence. Validation and use of complex documents If a service is accepting or returning a complex XML structured document, document style message is better suited since you can run XSL transformations against it, then validate it an XML schema (XSD), or manually massage it however you like prior to calling the service. Minimize in-memory processing Marshalling and un-marshalling parameters to XML in memory can be an intensive process. The SOAP model requires Document Object Model (DOM)-based processing of the envelope, which can lead to large DOM trees in memory if the XML representation is complex. Document messaging style allows other techniques like Simple API for XML (SAX) for parsing, XMLBeans and Castor XML for custom data binding to optimize and improve performance, which can be a critical factor for services that handle many simultaneous requests.

References:
[1] Abdaldhem, A., Patrick, F. & Jacque, S. P. (2009) Web Services Technology: State of the Art Definitions, Standards, Case Study. Available at: http://diuf.unifr.ch/drupal/softeng/sites/diuf.unifr.ch.drupal.softeng/files/file/publications/internal/ WP09-04.pdf [2] Aphrodite, T. & Thomi, P. (2002) An Overview of Standards and Related Technology in Web Services. Distributed and Parallel Databases Available at: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.8241&rep=rep1&type=pdf [3] Bianco, P., Kotermanski, R. & Merson, P. (2007) Evaluating a Service-Oriented Architecture. Software Engineering Institute. Available at: http://www.sei.cmu.edu/reports/07tr015.pdf [4] Cavanaugh, E. Web services: Benefits, challenges, and a unique, visual development solution. Available at: http://www.altova.com/whitepapers/webservices.pdf [5] Cerami, E. (2002) Web Services Essentials. OReilly Media, Inc. Available at: http://proquest.safaribooksonline.com/book/web-development/webservices/0596002246/introduction/webservess-chp-1-sect-1 [6] Derrick H., C., Qing Hu. (2004) Integrating Web Services with Competitive Strategies: The Balanced Scorecard Approach. Communications of the Association for Information Systems. Available at: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.4785&rep=rep1&type=pdf [7] Erl, T. (2004) Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Prentice Hall. Available at: http://proquest.safaribooksonline.com/book/web-development/webservices/0131428985/integrating-applications/ch10 [8] Goldberg, Kevin H. (2008) XML: Visual QuickStart Guide. 2nd ed. Peachpit Press Available at: http://proquest.safaribooksonline.com/book/xml/9780321602589/ajax-rss-soap-andmore/ch17lev1sec6 [9] Gunzer, H. (2002) Introduction to Web Services. Borland [Online] March. pp 4-5. Available at: http://archive.devx.com/javasr/whitepapers/borland/12728JB6webservwp.pdf [10] Kanneganti, R. & Chodavarapu, Prasad A. (2008) SOA Security. Manning Publications. Available at: http://proquest.safaribooksonline.com/book/networking/security/9781932394689/soabasics/ch01 [11] OASIS (Organisation for the Advancement of Structured Information Standards).

Available at: http://www.oasis-ws-i.org/

Вам также может понравиться