RESTful HTTP web services are not a drop-in replacement for SOAP/WSDL web services. RESTful HTTP web services require a totally different mindset. There are some
solutions where (SOAP/WSDL) is a good fit, however for many (possibly the majority) of solutions that currently employ (SOAP/WSDL) RESTful HTTP web services would a better, more effective, and more sustainable fit. Service-oriented solutions do not require that you use (SOAP/WSDL) - the ubiquity of HTTP APIs on all platforms makes it possible to use other technologies. However the overabundance of vendor (SOAP/WSDL) tooling makes it so convenient
to simply use (SOAP/WSDL) - so most people don't loose a single thought on the fact that they are sacrificing the greatest advantages that the web can give: hypermedia, loose coupling and scalability.
Currently the best resource on RESTful web services is Restful Web Services
. It contains chapter "10 The Resource-Oriented Architecture Versus Big Web Services"
RESTful HTTP web services [REST] vs Big Web Services (SOAP/WSDL) [BgWS] BgWS: adopts an RPC style (document-oriented included): multiple operations on diverse data all mediated through POST on a single URI, e.g. endpoint->my_function(entity, argument)- that goes against the grain of the web. The web was NOT designed to support general-purpose distributed programming. REST: resource oriented like the web. resource->my_function(argument) - note how the "entity" has moved out of the signature and been transformed into a resource (identified) by a URI. BgWS: unlike the web - one URI (for the endpoint) and no links -> not addressable, cacheable, or well connected; doesn't respect a uniform interface. REST: like the web - one URI per resource and representations reveal further links to other resources. Conditional GET increases cachability which greatly benefits scalability BgWS: WSDL allows the specification of specialized interfaces - this reduces the opportunities for loose coupling. REST: only allows one universal uniform interface. Combined with connectedness through links (URIs) in the representations this maximizes opportunities for loose coupling. BgWS: ... furthermore the majority of WSDL contracts are tool generated based on information extracted from code that has nothing to do with "the web". The mappings often let language based idioms and data structures leak into the web service contract (leaky abstractions) that can ultimately make other web service stacks choke. Furthermore changing the code will ultimately change the WSDL contract that will lead to versioning issues (WSDL versioning requires a very a well thought out strategy that probably is beyond tooling). This ultimately tends to make SOAP/WSDL interfaces brittle and clients can be tightly bound to servers that use the same stack (interoperability usually requires carefully designed contracts that only use commonly used contract specification language features - it is usually generated contracts that break interoperability). BgWS: created for the design of process-oriented, brokered distributed services - applications of this type are more prevalent in business and government, less so in technology and academia. REST: resource-oriented approach is turing-complete. Ultimately once you know how, you can model any application in a resource-oriented way. BgWS: the SOAP envelope can go over multiple SOAP nodes - though this feature isn't used often. The SOAP envelope can travel over HTTP, instant messaging, raw TCP, SMTP, JMS, or any other protocol - however the vast majority of the traffic is between a client and server over HTTP. REST: the HTTP "envelope" carrying the representation goes only between the HTTP client and HTTP server. BgWS: WSDL groups many custom operations into a single "endpoint" creating a highly specialized interface and hides the entire service behind a single address REST: WADL describes resources that respond to HTTP's uniform interface and also describes how the resources link to one another. BgWS: SOAP/WSDL are entirely XML based - there are a few standards (DIME, SwA(MIME), MTOM) that define mechanisms for attaching binary data to SOAP messages but none of them are universally supported which again leads to interoperability issues. REST: supports all the web-based media types BgWS: SOAP/WSDL uses XML Schema to define their data layout - ultimately enabling automatic client contract-to-stub generation. This leads to the client being tightly coupled to the entire service interface not just the parts that affect it. REST: Coupling can be minimized by purposefully designing the client API and having representations that are either simple or make parts largely optional. For example, the clients only need to know about the representations they need (hopefully designed on the server-side with minimal mandatory content) to send and only need to know the parts of the received representation that are of interest to them. If for example the representation is in XML the request representations could define a minimal set of mandatory parts (the client code doesn't have to refer to the schema at all - it simply exists for the developer's benefit) while allowing a rich set of optional parts; for the response representations the client can simply use XPath expressions to get at the interesting parts while ignoring everything else (not an approach that a code generator would use as it would consume the entire schema). Loose coupling all comes at a cost - in this case a custom designed client API to minimize the client's coupling to the service. Whenever you get a tool/code generator involved the coupling becomes tighter because, unaware of the client's context, it exposes every little bit to the client. BgWS: UDDI predicated the total automation of web service consumption by eliminating human intervention which even back in 2004 was called "The Self-Organizing Myth". Service Level Aggreement (SLAs) are required between organizations, sometimes even between departments before a client can rely on a web service. This means that human intervention cannot be eliminated. So UDDI is currently in use as a private registry where SLAs are already in place and where it is practical to impose quality controls, uniform interfaces and taxonomies. REST: As human intervention is a given, resources are found by a human being using internet search engines (just like the BgWS equivalent looking for a public SOAP/WSDL web service). BgWS: WS-Security Usernames define headers that use other standards like SAML token, X.509 tokens, Kerberos Tokens REST: While there is no currently WS-Security Username equivalent, there are no fundamental issues preventing a similar standard using HTTP headers. Atom had actually ported some WS-Security concepts to HTTP as WSSE. REST: Transport Level Security (TLS/SSL) has proven sufficient for securing credit card information. XML signatures and encryption can still be used on representations that use XML format. (See Atom Syndication Format: 5. Securing Atom Documents. And yes, Atom is the poster child of a standardized RESTful service definition). Resource-oriented architectures promote simplicity and uniformity - complexity and a large number of interfaces usually make security more difficult. BgWS: has WS-ReliableMessaging REST: doesn't need WS-ReliableMessaging. SOAP over HTTP uses the only nonidempotent HTTP method: POST. GET, HEAD, PUT, or DELETE are idempotent, so if the operation doesn't go through (and you will know if it didn't) just retry the request. The nature of idempotent operations eliminates the need for AtMostOnce, AtLeastOnce, and ExactlyOnce; if each request (finally) goes through in sequence you have InOrder. The only hole that is left is POST which can be closed by implementing POST Once Exactly (POE). Basically you request a POE resource with a special POE HTTP Header from the service. The response will contain a (generated) POE-Link (URI) that you can POST to. Then you POST to the POE resource. Once the POST goes through the POE resource will always respond with 405 "Operation Not Supported" to every subsequent POST - so resending a POST to the POE resource is safe.BgWS: has WS-AtomicTransaction and WS-BusinessActivity to implement transactions that stretch over multiple web services.REST: Again the different mindset comes into play. A transaction needs to be implemented as a resource. You can create a transaction resource by POSTing to a to a transaction factory resource which will give you a URI to the new transaction resource. Then you PUT the details of the transaction to sub-resources of the transaction resource. You can rollback the transaction by DELETEing the transaction resource. Finally you commit the transaction by PUTting the commit to the transaction resource. At this point a status code of 200 OK tells you that the transaction is complete - at which point you can DELETE the transaction resource without altering the effects of the transaction. Furthermore it needs to be noted that a two-phase commit (2PC) that is so popular in homogeneous environments it actually a form of tight coupling - so loosely coupled systems actually prefer compensation (Your Coffee Shop Doesn�t Use Two-Phase Commit (PDF)) (again the cost of loose coupling rears its ugly head).BgWS: The reality is that BPEL and ESB tend to increase coupling with the reliance on common third party middleware.
Originally posted by upul indrajith:
Is there any standard way to compose a RESTful web service ??? Can web service composition / Orchestration automated ?
Robert C. Martin Clean Code
Indeed some have suggested that we are close to the end of code. That soon all the code will be generated instead of written. That programmers simply won't be needed because business people will generate programs from specifications.
Nonsense! We will never be rid of code, because code represents the details of the requirements. At some level these details cannot be ignored or abstracted; the have to be specified. And specifying requirements in such detail that a machine can execute them is programming. Such a specification is code.
Basically the current generation of SOA foundation software and middleware is involved in the same code generation madness that many UML CASE tools have been involved in for a while - which are indulging themselves in the same old code generation fantasy that has been pursued fruitlessly since the dawn of Computer-aided Software Engineering (CASE) tools in the early 1980s.
You have to carefully design and implement your service logic - you need to apply that same care to the design of the interface to that service, you simply cannot expect a code generator to do a competent
job by simply looking at various internal parts of the service. The interface should be about the clients needs - the service internals are all about the service's needs. On the client side that means that you may need to customize (in code) how you use that interface as the needs of various clients will vary and your client should only depend on the parts that it is interested in.
Yes, our craft is all about automation - but there are some areas that should not/cannot be automated, where we need to develop our competence and then exercise that competence. Not everything we do is "boilerplate", there are many instances where we need to apply our judgment that we cannot leave to tools/code generators.
The principles of service aggregation are still important even for RESTful services when you are shaping a service-oriented environment - however completely automating composition and orchestration seems to be a bit of a pipe dream even considering all the claims that some products make.
In Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture
the service life-cycle is divided into the following states Conceptual Service: An Abstraction Analysis Service: An Analysis Unit Design Service: A Logical Solution Provider and Contractual Entity Solution Service: Physical Software Asset
The metamorphosis from one state to the next seems intuitive enough for anyone who has designed and developed software before. However a Solution Service can be knocked back to any of the earlier states for a variety of reasons:
Solution Service to Design Service Revision to Service Visibility and Accessibility Modification to External Structure and Packaging Service Consumer Contract Changes Alteration to Service Relationship Transaction Remodeling
Solution Service to Analysis Service Granularity Alignment Reusability Enhancement Functionality Redundancy Reduction Solution Evaluation
Solution Service to Conceptual Service Modification of Business of Technical Requirements Modification to Business Model or Mission Concept Reevaluation Restructuring and Reengineering
So the only way to automate composition and orchestration AND for every service involved to remain in the "Solution Service" state is to anticipate every possible aggregation scenario and accept the complexity of preparing for all those scenarios even if you do not currently need it. If the Agile movement has taught us any thing then it is: You are unable to predict all the future changes that are possible. You are unable to predict which future changes will be required. Preparing for changes that aren't going to happen wastes times and precious business resources and opportunities. You aren't going to need it (more often then not).
Once you accept that, your tool will have to be able to detect what changes are necessary to achieve a new aggregation and therefore knock the affected solution services back to the required life-cycle state and then drive the metamorphosis though the necessary states up to the new Solution Services AND then deploy ALL the changes at the same time. That seems a bit risky from a business perspective.
It seems to make more sense (and less risky) to continuously assess and adjust the preservation of "separation of concerns" (service refactoring?) in your service-oriented environment and to move in small
iterations to the next state that you need.
There are some interesting insights into the problematic nature of essentially RPC-oriented SOAP/WSDL web services and some of the advantages of the RESTful approach in Steve Vinosky's IEEE Internet Computing "Towards Integration" Column
in particular: 2007; Vol. 11, No. 1: REST Eye for the SOA Guy (PDF) 2008; Vol. 12, No. 1: Serendipitous Reuse (PDF) 2008; Vol. 12, No. 2: Demystifying RESTful Data Coupling (PDF) 2008; Vol. 12, No. 4: Convenience Over Correctness (PDF) 2008; Vol. 12, No. 5: RPC and REST Dilemma, Disruption, and Displacement (PDF) 2008; Vol. 12, No. 6: RESTful Web Services Development Checklist (PDF)
[ November 14, 2008: Message edited by: Peer Reynders ]