• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Issues related to RESTful web servicers

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What are the unsolved / existing issues related with RESTful web services ?


Can anyone give me some issues that may encounter when implementing a RESTful web service ??

What is the existing mechanism to identify the QOS level of the web service before its being consumed by a service consumer ?? Does the new UDDI version (3.0.2) support this ??

Is there any standard way to compose a RESTful web service ??? Can web service composition / Orchestration automated ?

[ November 14, 2008: Message edited by: upul indrajith ]
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What are the unsolved / existing issues related with RESTful web services ?


Security is an issue. SOAP stacks have the full arsenal of tools afforded by WS-Security, but REST has only HTTP-based approaches (like Basic authentication and SSL encryption) available. That may or may not be an issue for any given WS application.

What is the existing mechanism to identify the QOS level of the web service before its being consumed by a service consumer ?? Does the new UDDI version (3.0.2) support this ??


I wouldn't rely on UDDI to solve any WS-related problems. Just about nobody uses it.

Is there any standard way to compose a RESTful web service ?


If by "compose" you mean "implement", then -in the Java world- there's the JAX-RS API and its reference implementation called Jersey. You might also look into WADL for describing such services, although not everybody agrees that it's useful or even desirable.

Can web service composition / Orchestration automated ?


You mean something like BPEL for REST? Given that one of the main drivers for creating REST (over SOAP) was simplicity, I doubt that there's work going on in that area. If you need something along those lines, SOAP stacks (and BPEL) are probably your best bet.
[ November 14, 2008: Message edited by: Ulf Dittmer ]
 
upul indrajith
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Security is an issue. SOAP stacks have the full arsenal of tools afforded by WS-Security, but REST has only HTTP-based approaches (like Basic authentication and SSL encryption) available.



Can anyone give me specific issues , problems related to RESTful web services ? Ok. Lets say security is an issue ??? So what are the specific issues related to web service security and when those issues occur ??. If you can give me some detailed scenarios it would be a great help.

If by "compose" you mean "implement", then -in the Java world- there's the JAX-RS API and its reference implementation called Jersey. You might also look into WADL for describing such services, although not everybody agrees that it's useful or even desirable.



ok. Is there any standard technology to compose web services dynamically ?? I mean is there any standard specific way to compose a web service "ON THE FLY" ??? . I believe this type of capability is essential , since services (web services) are intended to be used by machine purpose other than human purpose. So is there any standard way to compose web services dynamically with out human interaction.


I wouldn't rely on UDDI to solve any WS-related problems. Just about nobody uses it.



It means there's no standard way to identify the quality of a web service with out being consumed it ??

And one more new question. Is there any "Web service search engines" ?? How to publish a RESTful service in a service registry since there is no specific way to describe the service (Like a WDSL for a normal service) ??

RESTful services are giving more simplicity over SOAP and other communication mechanisms. But does it limit the benefits of SOA.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So is there any standard way to compose web services dynamically without human interaction?


What exactly do you mean by "compose" - are you talking about the client or the service? Composition refers to combining two or more services into one, but somehow it doesn't sound as if that's what you're asking about.

It means there's no standard way to identify the quality of a web service with out being consumed it ?


The usual way to get a guaranteed QoS would be a SLA (service level agreement) with the service provider. QoS is something that -if it's that important to you- you don't want to automate, but instead get it in writing.

Is there any "Web service search engines" ?? How to publish a RESTful service in a service registry since there is no specific way to describe the service


http://xmethods.net/ is a large repository of available WS, be they SOAP or REST or something else. It's meant for human consumption, not machine consumption, though.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is recent commentary on the difficulty some folks have in adjusting to a truly RESTful architecture after years of thinking in SOAP or XML-RPC terms.

Bill
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also be aware that REST is not CRUD.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 (p.2)

    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 ]
     
    upul indrajith
    Ranch Hand
    Posts: 36
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thank you for your valuable reply.
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by William Brogden:
    recent commentary



    Roy Fielding:


    So much coupling on display that it should be given an X rating





    Ted Neward's original blog entry
    [ November 15, 2008: Message edited by: Peer Reynders ]
     
    reply
      Bookmark Topic Watch Topic
    • New Topic