The document discusses web service architectures including SOAP and REST. SOAP uses XML and HTTP standards and has rigid type checking, while REST uses HTTP methods and is lighter weight. Both approaches have common issues around structuring composable services, establishing clear service contracts, and design concerns about communication costs and extensibility. The document also notes that SOAP services meet more enterprise needs while REST is more productive with less code required.

1. www.cerebratecs.com WEBSERVICES ~ S

2. Agenda Web Service? Architecture SOAP REST. Building web-services Architecture issues Design issues. SOAP (Vs) REST Future of REST www.cerebratecs.com

3. Web Service? Lot many definitions are available. Simply, it converts your application into web application which it can be accessible to the rest of the world. Rendezvous point of the business XML (Data Exchange Format) + HTTP (Protocol) Advantages of Web Services. Reusability by exposing the existing function on to the network. Interoperability between applications (Platform and Technology) dependent. Protocol standardization. Low cost of communication compare with proprietary solutions like B2B or EDI. Behavioral characteristics. XML – based approach makes applications are interoperable, since the uniform data representation and data transportation. Loosely coupling helps the EAI applications to support for on demand business. Coarse grained services that access the right business logic. Ability to synchronous and asynchronous executions. Support RPC and Document exchange. www.cerebratecs.com

4. Web Service Architecture- Big Web Services? Uses XML message that follow SOAP standards Popular with traditional enterprises, and corporate heavies from 2000. WSDL is meta data for defining web services. Many frameworks supports many languages and platforms. Interoperable and extensible www.cerebratecs.com

5. Web Service Architecture- Web API? These web services are called as WEB 2.0. Moving away from SOAP towards REST (Representational State Transfer). Basically formalization of direct XML exchange. No framework is needed just handle the XML any way you want. Web API combines multiple web services called “Mashups”. www.cerebratecs.com

6. SOAP Status. SOAP Envelope is a wrapper for content to be transferred. It will not contain no any other information. Header is an optional element it contains, application data and control information. BODY contains actual data in XML format. It can also contains attachment block, which can hold more application data. SOAP status in widespread use across business world. SOAP is easy to consume sometimes It has Rigid type checking, and adheres to contract. Nice potential, but developers are getting tired of waiting. Different SOAP Web Services Rpc/enc easy to use, but limited. Doc/lit cleaner, but schema interoperability issues www.cerebratecs.com

7. REST (Representational State Transfer) It’s an architectural style of World Wide Web. Way of looking at the web as resources. REST is set of rules how to use HTTP. REST uses all HTTP protocol methods. GET for obtaining the representation of service/resource. DELETE for removing the service/resource object. POST/PUT to update or create the service/resource. REST says SOAP adds unnecessary complexity. Light weight, human readable, and easy to build. Give very resource with ID. REST communicates statelessly. www.cerebratecs.com

8. REST Status Simple handling. No framework needed, since just XML and HTTP. Security builds on web servers. Drawbacks. Limited to HTTP, and synchronous. Application should care security, reliability, and transactions www.cerebratecs.com

9. Architecture Issues Both SOAP and REST share few common issues Structuring composable service functions Services as build blocks. Allowing them to link together as needed Factor out service components from applications and common data formats are key implications Establishing clear service contracts Same issues as EJB Web services are widely useful than EJB. WSDL is same as EJB interface Security builds on web servers. Difference in approaches are minor. Both get clear service contract from through XML Both have interface implementation approach www.cerebratecs.com

10. Design Issues Both SOAP and REST share few common issues Structuring APIs costs communication is more. XML serialization and de-serialization processing overhead. Extensible design Design and develop cross-compatible schemas. Practical issues effects performance and usability www.cerebratecs.com

11. SOAP Vs REST With respect to SOA both faces the same issues. SOAP always have higher level functionality. SOAP services will finally meet Enterprise needs. REST is more productive, not required huge chunk less code. REST is little expensive, and it requires few application developers. www.cerebratecs.com

12. WS Addressing With respect to SOA both faces the same issues. SOAP always have higher level functionality. SOAP services will finally meet Enterprise needs www.cerebratecs.com

13. Future of REST. Standardization of WSDL usage. Light weight frameworks for plugin programming. Handle details of HTTP exchange. Data binding or conversions to / or from java objects. www.cerebratecs.com

14. THANK YOU www.cerebratecs.com