Soap and Rest


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Openness is achieved by specifying and documenting the key software interfaces of a system and making them available to software developers.", pp. 14 Mechanisms for achieving openness: Programmer interfaces for system calls Programmer-loadable resource managers (device drivers) Core principles that seem to improve openness: Encapsulation - The hiding of design decisions within the module that they affect Low coupling - The reduction of dependencies between modules.
  • Eight forms of transparency: Access transparency enables local and remote information objects to be accessed using identical operations Location transparency enables objects to be accessed without knowledge of their location Concurrency transparency enables several processes to operate concurrently using shared objects with interference between them Replication transparency enables multiple instances of an objects to be used to increase reliability and performance with knowledge of the replicas by users or application programs. Failure transparency enables the concealment of faults, allowing users and application programs to complete their tasks despite the failure of hardware or software components. Migration transparency allows the movement of objects within a system without affecting the operation of users or application programs. Performance transparency allows the system to be reconfigured to improve performance as loads vary Scaling transparency allows the system and applications to expand in scale without changes to the system structure or the application’s algorithms.
  • Definition: “A distributed system is a collection of autonomous computers linked by a network, with software designed to produced an integrated computing facility.” Coulouris, pp. 1
  • A distributed system is the sharing of resources in independent and perhaps heterogeneous computer systems. Coulouris characterizes a resource as anything that can be shared usefully. A more traditional and perhaps not so abstract definition says that a resource is anything used in a computerized system to accomplish a task.
  • Physical Resource Examples: CPUs, Memory, Disk space, Clocks, Displays, Keyboards, Printers Virtual resources A virtual resource is a simulation of a physical resource. Virtual resources are sometimes implemented by time-sharing a physical resource, such as with virtual machines and virtual memory. In other cases, a virtual resource may be simulated on some unrelated physical device. For example, a display may be simulated in memory. Examples: Virtual memory, Virtual displays, Virtual keyboards, Other kinds of input devices Logical resources Logical resources are abstract entities which are eventually bound to physical and/or virtual resources. Logical resources eliminate the hassle of dealing with actual or virtual resource identifications. Operating systems are usually responsible for binding logical resources to physical and/or virtual resources. Examples: Units of work, Processes, Files, Procedure libraries, Shared programs
  • (Broaden discussion and generalize) Challenges of resource sharing: What challenges arise from resource sharing in a centralized multi-user system? Are these challenges present in distributed systems? Are there new challenges in distributed systems?
  • Illustrate each of these problems by stopping the server restarting server and disconnecting lines entering illegal ids look at packaging of Parcel Data look at sequential server design Which of these problems would exist in a centralized system? Which of these problems would exist in a single user system?
  • Key design questions: What are the costs of achieving a degree of fault tolerance? What are the benefits of fault tolerance? What degree of fault tolerance does a given application require or justify?
  • Concurrency in a computer system is when two or more processes execute simultaneously on separate processes. Single processor systems can give the illusion of concurrency by interleaving process execution. This is not true concurrency; rather, it is simulated concurrency True concurrent execution requires multiple processors. Opportunities for concurrency can occur in distributed systems in several ways: Coulouris, p. 16 Many users simultaneously invoke commands or interact with application programs Many server processes run concurrently, each responding to different requests for client processes.
  • Scalability We can increase the number of resources in a distributed system by adding more computer systems and communication channels The cost of increasing resources in a distributed system is usually less than the cost of scaling a centralized system. Why? However, system designers need to count communication delays as part of the cost. Scalable distributed systems have the potential to operate effectively and efficiently at many different levels (sizes). Work is distributed Loads can be balanced across the network Scalability is not an automatic property of distributed systems Designers need to consider the dynamic addition or removal of resources Designers must consider how the work is distributed Designers should consider dynamic load balancing
  • Openness "The openness of a computer system is the characteristic that determines whether the system can be extended in various ways.", pp. 14 This applies to both the addition of new kinds of resources and functionality with respect to those resources Scalability is a simple type of openness involving the addition of resources of the same kinds as those already in the system.
  • Transparency "Transparency is defined as the concealment from the user or the application programmer of the separation of components in a distributed system, so that the system is perceived as a whole rather than a collection of independent components." pp. 20
  • Soap and Rest

    1. 1. Web Services The SOAP & The REST Edison Lascano
    2. 2. Web ServicesWeb Services: Method of communication forweb applications (Internet, intranet, extranet,desktop, mobile) . Application layer : Mainly the HTTP protocol and port 80. Port and protocol may change, e.g. SMTP Message Formats: XML, JSON, RSS, longer than binary. MIME types match resourcerepresentations.
    3. 3. JSON / XML{"Table": {"httpStatus":"200","primary_key": "val1","key1": "value1","key2": "value2"}}<tables> <httpStatus value="200"/> <table primary_key="val1" key1="value1" key2="value2" /></tables>{"Student": {"httpStatus":"200","student_id": "005802615","name": "Edison Lascano","address": "2199 McLaughlin Ave"}}<students><httpStatus value="200"/><student student_id="005802615" name="Edison Lascano" address="McLaughlin" /></students>
    4. 4. Web Services• The basis of web 2.0 and many distributed applications currently• Public APIs are published by web 2.0 providers in SOAP, REST, XML-RPC, js. Private APIs are used internally. REST SOAP• MASHUPS (main users of Web APIs) – Public APIs + local APIs + My Application – Dont develop what is done, use others resources. Low coupling. But, APIs may disappear at any moment, Yahoo search.
    5. 5. API´s
    6. 6. Technology
    7. 7. Web Services in Web 2.0• . Cloud Services providers publish their Web APIs: AWS, Google App Engine...• Technology:-Tools, Languages, Platforms: Java, .Net, Python, php, Ruby, …-Distributed Objects: JEE-EJBs, .Net Remoting; ORMs: Persistent Units, JPAs: Linq, Hibernate, Eclipse Link-Clients: desktop, gadgets, widgets, mobiles, web, Ajax, Flex, JavaFX, Spring... Client-
    8. 8. SOAP Web Services• Simple Object Access Protocol, acronym dropped after 2003, it is a service oriented protocol• Microsoft begins in 1998, currently supported by the World Wide Consortium W3C• Usually Service verb form: URLs Uniform Resource Locator “getItem”
    9. 9. Ser UDDI vice Reg istry SOAP Web Services L W W SD SD L SOAP Messages Ser Ser vice vice• SOAP: protocol Pro vide r Con sum er – SOAP envelope: SOAP Header+SOAP Body – It uses XML• WSDL: IDL – Description of the methods, parameters, types – XML• UDDI: Universal Description Discovery and Integration – The service broker – Besides the Web Server
    10. 10. What is a SOAP Web Service?• Distributed Objects?• Is it RMI?• Is it RPC? – Every Web Service has a set of operations, – Two libraries in Java to program ws are JAX-WS and JAX-RPC.
    11. 11. RESTRepresentation State Transfer• Architectural style• Resource Oriented• Spread from 2000, It looks like they always existed, but became to be noticed and well organized/architected after Roy Fielding Dissertation.• Fielding is one of the authors of HTTP.
    12. 12. REST• A representation of the resource is returned – Resource: Noun form: URI, Uniform Resource Identifier• HTTP Methods: GET, PUT, POST, DELETE• WADL: Web Application Def Lang – Unlike Soap, WADL is not mandatory to discover the resource, the providers supply development documentation: URI´s lists.
    13. 13. URIs / URLs |ko
    14. 14. RESTful Web services “If an application complies with the 6 REST constraints, then it is RESTful” Roy Fielding• Three Client Constraints: • C/S, for separation of concerns • Stateless, Client holds the session state • Cacheable,To improve scalability and performance, but be careful of getting outdated information• Three Coding Constraints: • Layered Systems, they do not know about each other implementations, the URI is enough • Code on Demand, Javascript, any or “none” • Uniform Interface, for all WSs.
    15. 15. RESTful Uniform Interface• HTTP Request/Response Codes: • 200 OK; 300 Redirect; 400 Error, e.g. 404• Noun form URIs . . . .• HTTP Methods • GET /items/{id} # read an Item • POST /items/{id} # create an Item • PUT /items/{id} # update an Item • DELETE /items/{id} # delete an Item
    16. 16. Some REST advice• Use the standard HTTP methods, not as in SOAP, that you must create new methods for every requirement.• Opportunities  Improve your REST design – Provide one URI for every resource – Minimize the use of QUERY_STRING, prefer items/1 over items?id=1 – Logical over physical URIs, items/1 over items/1.html – No verbs in the URI, they are resources
    17. 17. More REST advice• Use hyperlinks in the Response when need to communicate an executed action ack/nack.• Use / to represent parent/child relationships. e.g. stock/items1 doctor1/patients/1• Use GET to allow the client retrieving a resource representation, not POST• Use POST to update a big object, so the URI will not be long and your data can not be seen in the URI.• Use GET, PUT, POST, DELETE properly.
    18. 18. The REST way of implementing the Web Services HTTP GET request URI1 Items List Response (HTML/XML/JSON...) HTTP response HTTP GET request URI Web Server Item Response (HTML/XML/JSON...) HTTP response POHTTP POST (HTML/XML/JSON...) URI PO URL to submitted PO HTTP response Adapted from: Roger L. Costello, “REST (Representational State Transfer), XML Technology Course”
    19. 19. Web app architecture designs• Client ↔ REST ↔ EJB ↔ DB (EIS)• Client ↔ SOAP ↔ EJB ↔ DB (EIS) Client ↔ REST ↔ JPA ↔ DB (EIS) Client ↔ REST ↔ DB (EIS), SOAP can be interchanged with REST in any case• Client ↔ REST ↔ .NET ↔ ORM ↔ DB(EIS) Client ↔ SOAP ↔ .NET ↔ ORM ↔ DB(EIS) .NET can be replaced by any other Distributed Objects technology.
    20. 20. SOAP web service lab• Netbeans 7.2 full version• Create a new Web Application, then a create a new “Web service”• Implement a new operation using the wizards, finally test the Web Service and take a look of the generated WSDL file.
    21. 21. REST Web Service Lab• Create a new Web Application• Create new RESTful web services – From patterns, simple root resource – New RESTful web services from database, finally test the RESTful web services, read the WADL file and then try some URIs to read the XML/JSON data returned.
    22. 22. Web Services (Java)SOAP RESTJAX-WS JAX-RS annotations: annotations: @WebService @Path @WebMethod @GET, @PUT, … @WebParam @PathParam, @QueryParam
    23. 23. Web Services clientsSOAP RESTJAX-WS stub Consume through generation from simple HTTP WSDL import calls from Java, js WADL is not needed
    24. 24. Motivation for REST"The motivation for developing REST was to create an architectural model forhow the Web should work, such that it could serve as the guiding frameworkfor the Web protocol standards.REST has been applied to describe the desired Web architecture, help identifyexisting problems, compare alternative solutions, and ensure that protocolextensions would not violate the core constraints that make the Web successful." - Roy Fielding