SERVICE ORIENTED ARCHITECTURE APPROACH FOR WEB SERVICES

512 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
512
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SERVICE ORIENTED ARCHITECTURE APPROACH FOR WEB SERVICES

  1. 1. A SURVEY PAPER ON SERVICE ORIENTED ARCHITECTURE APPROACH FOR WEB SERVICES Diana Geangalau (dgeangal@utdallas.edu) Computer Science Department The University of Texas at Dallas Software Architectural Design Acknowledgement: The specific implementations of SOA principles into Web Services are taken from Java Web Services Architecture by James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, published by Morgan Kaufmann Publishers. All rights reserved.
  2. 2. WEB SERVICES - DEFINITIONS <ul><li>The term Web Services describes a standardized way of integrating Web-based applications. </li></ul><ul><li>“ Web Services is the technology that allows for different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language.” - Webopedia </li></ul><ul><li>Web Services are primarily used as a means for businesses to communicate with each other and with clients. </li></ul><ul><li>Web Services are inherently distributed as opposed to the Client/server applications that are primarily data-centric in nature. </li></ul>
  3. 3. WEB SERVICES ARCHITECTURE <ul><li>UDDI - Universal Description Discovery and Integration </li></ul><ul><li>Finds the Internet location of the requested web service. </li></ul><ul><li>The &quot;yellow pages&quot; of Web Services on Internet. </li></ul><ul><li>WSDL - Web Services Description Language </li></ul><ul><li>Web services provider advertises the provided services so that the client applications obtain information about a web service prior to accessing and using the web service. </li></ul><ul><li>SOAP - Simple Object Access Protocol </li></ul><ul><li>The channel used for communication between a web services provider application and a client application. </li></ul><ul><li>XML - Extended Markup Language </li></ul><ul><li>Is a meta language that has a well-defined syntax and semantics to provide the means to format the messages into XML documents. </li></ul><ul><li>HTTP – Hyper Text Transfer Protocol </li></ul><ul><li>Ensures that web services provider applications and client applications can communicate using the Internet as the backbone. </li></ul>Web Service layers Transport (HTTP) Encoding (XML) Standard structure (SOAP) Description (WSDL) Discovery (UDDI)
  4. 4. USING WEB SERVICES <ul><li>The client application queries the Web Services WDSL file in order to find out what the service can provide and how. </li></ul><ul><li>Then the client sends a request to the service at its given URL using the SOAP protocol over HTTP. </li></ul><ul><li>The service receives the request, processes it, and returns a response. </li></ul>XML Client WDSL proxy WDSL WDSL WDSL WDSL Web Service WDSL stub 4 UDDI Server response request 1 HTTP +SOAP 2 3 1. Communication protocol 2. Message format 3. Description language 4. Discovery mechanism
  5. 5. STEPS TO CREATE A WEB SERVICE Define the services that will be provided Implement the functionality behind the services Deploy the service provider application Publish the Web services with a directory service Wait for processing client requests Service Provider Identify the services that will be required Locate the Web service by querying a directory service Send the request to the service Receive the response from the service Service Client
  6. 6. SERVICE ORIENTED ARCHITECTURE - DEFINITION <ul><li>A Service-Oriented Architecture is essentially a collection of services that communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. </li></ul><ul><li>The Service-Oriented Architecture for Web Services has: </li></ul><ul><ul><ul><li>a standard way for communication </li></ul></ul></ul><ul><ul><ul><li>a uniform data representation and exchange mechanism </li></ul></ul></ul><ul><ul><ul><li>a standard meta language to describe the services offered </li></ul></ul></ul><ul><ul><ul><li>a mechanism to register and locate web services-based applications </li></ul></ul></ul>Service Provider Service Consumer service request service response
  7. 7. SERVICE ORIENTED ARCHITECTURE - ENTITIES <ul><li>Service Consumer </li></ul><ul><li>The service consumer is an application, service, or some other type of software module that requires a service. </li></ul><ul><li>Service Provider </li></ul><ul><li>The service provider is the service, the network-addressable entity that accepts and executes requests from consumers. </li></ul><ul><li>Service Registry </li></ul><ul><li>A service registry is a network-based directory that contains available services. </li></ul><ul><li>Service Contract </li></ul><ul><li>The contract specifies the way in which the service consumer and the service provider will interact. It specifies the format of the request and response from the service . </li></ul><ul><li>Service Proxy </li></ul><ul><li>The service proxy is provided by the service provider to the service consumer. It enhances the service performance by caching at the service consumer site the remote references and data. Thus the subsequent service calls do not require additional registry calls. </li></ul>The consumer of a service asks the registry for the service that matches its criteria. If the registry has such a service, it gives the consumer a contract and the endpoint address for the service. The consumer than accesses the service. Registry Service Provider Service Consumer Contract register find bind and execute
  8. 8. PRINCIPLES - MODULARITY <ul><li>The modularity allows the services to be aggregated into an application with a few well-known dependencies. </li></ul><ul><li>The service application can be decomposed into many smaller modules in which each module is responsible for a single, distinct function within the application. </li></ul><ul><li>The software services are reusable so that they can be combined with other services to produce new systems. </li></ul><ul><li>The functions of a service can be understood by any client without having any knowledge of other services, thus any consumer is able to find and decide to use a service at any time. </li></ul><ul><li>A service hides the information about its internal design therefore any changes made internally will not create a domino effect to affect other services. </li></ul><ul><li>Faults in the operation of a service do not impact the operation of a client or other service or the state of their internal data, thus the faults do not cascade from the service to other services or consumers. </li></ul>
  9. 9. PRINCIPLES – LOOSE COUPLING <ul><li>Coupling refers to the number of dependencies between modules. The loosely coupled modules have a few well-known dependencies. </li></ul><ul><li>The consumer of the service does not need detailed knowledge of the service before invoking it, thus the consumer and provider are loosely coupled. </li></ul><ul><li>SOA accomplishes loose coupling through the use of contracts and bindings. </li></ul><ul><ul><ul><li>A consumer asks a third-party registry for information about the type of service it wishes to use. </li></ul></ul></ul><ul><ul><ul><li>The registry returns all the services it has available that match the consumer's criteria. </li></ul></ul></ul><ul><ul><ul><li>The consumer chooses which service to use, binds to it, and executes the method on it, based on the description of the service provided by the registry. </li></ul></ul></ul><ul><li>The consumer does not depend directly on the service's implementation but only on the contract the service supports therefore a a service may be both a consumer and a provider of some services. </li></ul>
  10. 10. PRINCIPLES – ENCAPSULATION <ul><li>All components in Web Services are services. </li></ul><ul><li>The type of behavior a service provides is important not how it is implemented. </li></ul><ul><li>A WDS (Well-Defined Service) document is the mechanism to describe the behavior encapsulated by a service: service category, service description, and expiration date, as well as business information about the service provider, such as company name, address, and contact information. </li></ul><ul><li>System complexity is reduced because the application designers do not have to worry about implementation details of the services they are invoking. </li></ul><ul><li>Substitution of different implementation of the same type of service, or multiple equivalent services, is possible at runtime. </li></ul><ul><li>The behavior of a service is encapsulated and extended by providing new services with similar service descriptions. </li></ul>
  11. 11. CONCLUSIONS <ul><li>Web Services are the preferred standards-based way to realize Service Oriented Architecture. </li></ul><ul><li>The use of Service Oriented Architecture for Web Services offers potential for lower integration costs and greater flexibility. </li></ul><ul><li>Service Oriented Architecture separates the service interface (the what) from its implementation (the how). </li></ul><ul><li>Such services are consumed by clients that are not concerned with how these services will execute their requests. </li></ul><ul><li>Web services are the next step in the Web's evolution, since they promise the infrastructure and tools for automation of business-to-business relationships over the Internet. </li></ul>
  12. 12. REFERENCES <ul><li>Java Web Services Architecture (ISBN: 1-55860-900-8), by James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, published by Morgan Kaufmann Publishers. © Copyright Morgan Kaufmann Publishers. All rights reserved. </li></ul><ul><li>Service-oriented architecture Perrey, R.; Lycett, M.; Applications and the Internet Workshops, 2003. Proceedings. 2003 Symposium on 27-31 Jan. 2003 Page(s):116 - 119 </li></ul><ul><li>Modeling and design of service-oriented architecture Stojanovic, Z.; Dahanayake, A.; Sol, H.; Systems, Man and Cybernetics, 2004 IEEE International Conference on Volume 5,  10-13 Oct. 2004 Page(s):4147 - 4152 vol.5 </li></ul><ul><li>Deployment of service oriented architecture for a business community Baglietto, P.; Maresca, M.; Parodi, A.; Zingirian, N.; Enterprise Distributed Object Computing Conference, 2002. EDOC '02. Proceedings. Sixth International 17-20 Sept. 2002 Page(s):293 - 304 </li></ul><ul><li>A service management framework for service-oriented enterprises Ying Huang; Kumaran, S.; Chung, J.-Y.; e-Commerce Technology, 2004. CEC 2004. Proceedings. IEEE International Conference on 6-9 July 2004 Page(s):181 - 186 </li></ul><ul><li>Extending the Web services model to it services Stern, A.; Davis, J.; Web Services, 2004. Proceedings. IEEE International Conference on 6-9 July 2004 Page(s):824 – 825 </li></ul><ul><li>Web services oriented architecture for electronic commerce Huinan Xu; Engineering Management Conference, 2003. IEMC '03. Managing Technologically Driven Organizations: The Human Side of Innovation and Change 2-4 Nov. 2003 Page(s):479 - 483 </li></ul><ul><li>http://www.service-architecture.com/web-services/articles/index.html </li></ul><ul><li>http://www.sys-con.com/webservices/ </li></ul><ul><li>http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci882438,00.html </li></ul>

×