Featured in
Process & Practices

In-App Subscriptions Made Easy

There are various types of subscriptions: recurring, non-recurring, free-trial periods, various billing cycles and any possible billing variation one can imagine. But with lack of information online, you might discover that mobile subscriptions behave differently from what you expected. This article will make your life somewhat easier when addressing an in-app subscriptions implementation.

Featured in
Enterprise Architecture

EIP Designer: Bridging the Gap Between EA and Development

This article presents the EIP Designer project, an Eclipse-based tool for introducing integration patterns into an EA design, providing fluidity and continuity while filling the gap existing between EA practices and concrete software development.

Is REST the future for SOA?

It seems like everywhere we turn we keep hearing that SOA’s future is REST. There are a lot of publications comparing REST to SOAP and WS*[1], but such comparison seems to be too simplistic. There are two main approaches that have emerged lately – true REST and REST as a technology approach for services (aka REST Web Services[2]). In this article I will try to discuss whether either of these approaches can improve SOA implementations.

True REST for SOA

A true REST is effectively an implementation of Resource-Oriented architecture and not a pure technology decision. So the right question to ask when discussing true REST is whether its underpinning – ROA - is a good fit for your SOA implementation.

In order to assess the problem correctly, let’s first recall that the SOA architectural style [2] is based on a functional decomposition of enterprise business architecture and introduces two high-level abstractions: enterprise business services and business processes. Enterprise business services represent existing IT capabilities (aligned with the business functions of the enterprise). Business processes, which orchestrate business services, define the overall functioning of the business.

REST, on another hand, is a set of architectural guidelines [3] expressed as Resource-Oriented Architecture (ROA). ROA is based upon the concept of resources; each resource is a directly-accessible distributed component that is handled through a standard, common interface. So, the foundation of ROA is a resource-based decomposition[3].

In order to assess the applicability of true REST for the implementation of SOA, the real question that we need to answer is “What is the relationship between a service and a resource?”

Services vs. Resources

What is a service?

In the simplest case, a service can be defined as a self-contained, independently developed, deployed, managed, and maintained software implementation supporting specific business-relevant functionality for an enterprise as a whole and is "integratable" by design. A “Service” is defined by a verb ( For example, “validate customer’s credit score”, which describes the business function it implements.)

A service is not a programming construct or a set of APIs, but rather an architectural (unit of design, implementation, and maintenance) and deployment artifact used for implementation of enterprise solutions. The service functionality is defined by a service interface (specific for a given service), which can be supported by multiple implementations. There are two basic ways of defining a service interface – RPC-style and messaging-style. RPC-style implementations use service invocation semantics and are defined through a set of parameters in the service interface. In the case of messaging style, a service interface is effectively fixed – it essentially performs “execute” - with an XML document as input and output (much like the GoF command pattern). A service semantic, in this case, is defined by the semantics of the input and output messages[4].

Historically, services are often defined as a collection of methods, but as explained in [2] these methods are independent from each other[5] and such collection serves as a namespace, simplifying the management of the services.

What is a resource?

In the simplest case, a resource can be defined as a directly-accessible, independently-developed, deployed, managed and maintained software artifact supporting specific data. A resource is defined by a noun for example, “doctor’s appointment” that describes the data provided by the resource. A resource can also relateto other resources and provide a reference (link) to them. In effect, a resource is similar to an object[6], but with a predefined (CRUDish) interface semantic.

The semantics in REST are based on the set of HTTP operations and looks as follows [5]:

getResourceRepresentation - Retrieve the representation of the resource - GET

deleteResource - Delete the resource (optionally including linked resources) - DELETE (referred resource only), POST (can be used if the delete is including linked resources)

modifyResource - Modify the resource – POST

getMetaInformation - Obtain meta information about the resource - HEAD

A resource is defined by its URL and definition of inputs/outputs for every operation supported by a resource[7]. Unlike a service, where methods are completely independent and can be deployed as independent endpoints, methods on a resource follow OO semantics, which means that all of them (except createResource) have to exist on the underlying resource (same URL).

Basic differences between Resources and Services

Based on the above definitions of resources and services, it seems intuitively obvious that they are very different. Let’s delve into these differences first, and then discuss how they can impact resulting architecture.

As stated in [6]:

“Not only is REST not service oriented, service orientation is irrelevant for REST”

And [7] goes even further explaining the differences between the two as:

“If WS-* is the RPC of the Internet, REST is the DBMS of the internet… Traditional SOA based integration visualizes different software artifacts being able to interact with each other through procedures or methods. REST effectively allows each software artifact to behave as a set of tables, and these artifacts talk to each other using SELECT, INSERT, UPDATE and DELETE. ( or if you wish GET, PUT, POST, DELETE). And where exactly is the business logic? Is it in the stored procedures? Not Quite. It’s in the triggers.”

Here we will use a slightly different analogy, one based on J2EE. We can think of services as stateless session beans and resources as entity beans.

Services – session beans – serve as controllers allowing execution of a required operation, regardless of the underlying resource. For example, a debit account service might take the account ID and the amount and debit required account. A single service can debit any of the existing accounts.

Resources – aka entity beans – serve as a data access mechanism for a given instance of given data type. For example, in order to debit a certain account, it is necessary to find a resource representing this account and then update it to debit the required amount. An additional caveat here is that unlike an entity bean which can implement any required method, a REST resource has only a single modify resource method. This means that the actual business operation, the debit, has to be encoded as part of the request.

What does this mean?

Based on the above, it is impossible to build an SOA system using true REST. It is possible to build a system, but it won’t be SOA. Both will start with the business-aligned decomposition, but because they are using very different decomposition approaches they will result in completely different architectural styles[8] based on different set of components and connectors.

Just because they are trying to solve the same problem – business/IT alignment and are both based on business driven decomposition does not mean that the result will adhere to the same architectural style.

Another question is whether it is possible to build a complete system using true REST. Based on the above, it is a question of whether it is possible to build a complete system using only a database or entity beans. Certainly you could, but it would require adding procedural code in the form of stored procedures (overwriting the meaning of the methods) or triggers (doing post processing based on the data changes). The same is typically true for a true REST implementation – you have to change the meaning of the modifyResource method (often using command pattern) to do more than data update.

As a result, a REST-based implementation is rarely true REST; it typically includes at least some elements of REST Web Services. So what does it mean to be a REST Web Service?

REST Web Services

The REST Web Service approach is an approach for using REST purely as a communication technology to build SOA. In this case, services are defined using SOA style decomposition and REST-based Web Services[9] are leveraged as a transport.

Although commonly referred to as REST, this approach has nothing to do with true REST and is similar to POX (plain old XML over HTTP), with the difference being that in addition to XML, it supports multiple other data marshalling types ranging from JavaScript Object Notation (JSON) to ATOM to binary blobs and leverages additional HTTP methods, compared to POX, which is typically based on GET and PUT.

Using JSON became a very popular approach due to the advances of Web and wide-spread adoption of Ajax technology; the majority of modern browsers have built-in support for JSON. Since it is a non-trivial task to process XML (especially with multiple namespaces) in JavaScript, it is much easier for web-based implementations to use JSON-based REST Web Services. The proliferation of REST Web Services for Web interactions lead to the increased popularity and wide spread of these technologies.

What is the real difference?

Publications describing differences between SOAP and REST typically point to the following advantages of REST Web Services, for example [11]:

“Lightweight – not a lot of extra xml markup

Human Readable Results

Easy to build – no toolkits required”

Although these differences are important (I will discuss them in detail later in the article), the main difference between SOAP and REST is the fact that while REST is implemented directly on top of the HTTP protocol, SOAP introduces an abstraction layer (SOAP messaging), that can be implemented on top of any transport. Standardized SOAP bindings currently exist for HTTP, SMTP and JMS, but non-standard bindings have been implemented for other transport solutions. This additional abstraction layer that provides decoupling between existing transports and SOAP-based implementations is the root cause of major differences between SOAP and REST Web Services.

The opinions about this abstraction layer vary significantly depending on whom you talk to. The REST camp considers it to be over-engineering and claims that it does not provide any real value. They claim that HTTP already provides all of the features required for implementation of services interactions. The SOAP camp, on the other hand, will argue that HTTP is not the only transport that is typically required for service interactions (especially inside the enterprise) and having a portable, extensible[10] abstraction layer is necessary for building robust, feature-rich service interactions.

Although both points of view have their merits, in my experience trying to limit SOA implementation to a single transport – HTTP - rarely works in practice. Yes, HTTP is ubiquitous and its usage typically does not require any additional infrastructure investments, but it is not reliable (HTTP-R is not widely adopted), synchronous only[11] (creating temporal coupling), does not have transactional semantics and so on.

Additionally, even if HTTP is the only transport used in implementation, the SOAP envelope can become very handy for a clean separation of business (SOAP Body) and infrastructure or out-of-bound (SOAP Headers) data in SOAP messages. And finally, if your original implementation does not require any infrastructure or out-of-bound data, the overhead of the SOAP envelope is minimal – two tags, but provides a well-defined way for adding such data as the need arises.

So, at the end of the day, data enveloping with separation of business and infrastructure concerns is a very powerful paradigm, which is often used even in the REST Web Services implementations. Whether to use a standardized SOAP or a custom enveloping schema[12] has to be decided by a specific implementation.

Other differentiators

Let’s take a moment to discuss some of the other differentiators between SOAP and REST Web Services often cited in publications.

Simplicity

A popular opinion is that REST is much simpler then SOAP. According to them, REST simplicity stems from the fact that REST does not require WSDL or any interface definition. Such statements are naïve, at best. No matter which technology is used for communications between service consumer and provider, they must still agree on both syntax and semantic of their message exchange (interface)[13]. This means that in the case of REST, one of two approaches is possible:

Defining an interface in a text document and “manually” coding of data marshalling/unmarshalling based on a common interface definition described in the interface document. Although such an approach is often promoted by REST advocates, it rarely scales beyond 10 - 15 elements, which is not typical for coarse grained REST services. Besides, such an approach is very error prone and as a result, most of the available REST frameworks have abandoned it in favor of the next approach.

Defining an interface on the XSD level and generation of the data marshalling/unmarshalling based on the preferred framework (for example, JAXB or Castor in the case of XML payload or Jackson, in the case of JSON payload). Such an approach is, in effect, a minimalistic version of WSDL and requires about the same amount of effort as SOAP-based implementations. In fact, exactly the same approach is often used in the SOAP-based implementation, leveraging a single interface and a command pattern for service execution. The extension of this approach is usage of WSDL2.0 [13] and/or WADL [14] for REST.

Another common complaint about SOAP is perceived complexity of WS* standards [15]. Although there is no single spec that lays out the key WS*standards and their interrelationships, there is a standard for a majority of service interaction use cases. Granted, the choosing of an appropriate WS*standard and its usage might require some extra understanding/implementation time, but [16]:

“Arguing simplicity versus standards is ridiculous in the war between REST and SOA because simplicity without standards is just as detrimental to the costs and manageability of an application “

So, with the exception of the most simplistic examples like “temperature converters”, REST is not any more simple than SOAP.

Lightweight

Another reason why many REST proponents are advocating REST as an alternative to SOAP is the fact that in REST, both requests and responses can be short. There are two main reasons for this:

SOAP requires an XML wrapper around every request and response, which increases the size of a message. Although this is true, the important thing to consider here is not how many bytes the wrapper adds, but rather the percentage of overhead it creates. Because the wrapper size is constant, this percentage decreases as the size of the message grows, eventually becoming negligible. Considering that a typical service is fairly coarse-grained, the size of the request and reply is fairly large and consequently the overhead of a SOAP envelope is rarely an issue.

SOAP is XML-based messaging, which uses verbose encoding. REST, on the hand, provides a more lightweight messaging alternative – JSON[14]. Although this is true, usage of the Message Transmission Optimization Mechanism (MTOM) [17], supported by most SOAP frameworks, allows for splitting of messages into minimal XML-based SOAP Envelope/Header/Body parts and additional parts containing message content that can be encoded as any MIME types, including JSON, binary streams, etc.

Although in theory, REST is lighter-weight compared to SOAP, in practice, with some advanced SOAP design techniques, the difference between size of realistic SOAP and REST messages can be made minimal.

Easy to build – no toolkits required

Because REST is based on HTTP, one of the claims of its proponents is that one can use familiar technologies like the Java servlet API and Java HTTP support to write REST services implementations and clients without any specialized toolkits. This is true if one wants to “manually” implement building input/output messages and data marshalling. The same can be done for SOAP Web Services as well. However, people rarely want to write such boilerplate code and as a result use toolkits for both SOAP and REST [18].

Conclusion

REST can be used as both system design approach leveraging ROA (true REST approach) and SOA design implementation leveraging REST technologies (REST Web Services). Although both approaches have their merits, they do not change the hardest part– defining business services/resources aligned with the enterprise business model. There are cases for both SOA and ROA, but at the end of the day those are two very different styles.

About the Author

Boris Lublinsky is principal architect at NAVTEQ, where he is working on defining architecture vision for large data management and processing and SOA and implementing various NAVTEQ projects. He is also an SOA editor for InfoQ and a participant of SOA RA working group in OASIS. Boris is an author and frequent speaker, his most recent book "Applied SOA".

Acknowledgements

I am thankful to my NAVTEQ colleagues, especially Jeffrey Herr for help in writing this article. Also thanks to Stefan Tilkov and Kevin T. Smith for providing interesting feedback (often negative), that helped me to improve the article

[2] I am using here the term, that technically make no sense, and is not REST, but is widely adopted in industry and is considered to be REST by many people.

[3] By definition, a resource is any component deserving to be directly represented and accessed

[4] A typical implementation of such service is based on “command pattern”. An input document defines both command itself and data used by this command.

[5] Method independence stems from the fact that although different methods can be executed on the same data – here this is an enterprise data which exists regardless of whether it is exposed by services, not an object instance specific data as it is used in OO.

[7] Many of the REST proponents claim that the latter is not necessary. We will return to this point later in the article.

[8] Architectural style are “like “design patterns” for the structure and interconnection within and between software systems'' [9]. A more holistic definition of the architectural style, provided by [10] states that “An architectural style is a family of architectures related by common principles and attributes”

[9] Another misnomer popular in industry – Web Services are SOAP by definition.

[10] All of the WS* implementation heavily relies on SOAP, more specifically on SOAP headers.

[11] You can always implement asynchronous messaging on top of HTTP, but you need an additional abstraction layer, for example SOAP with WS-Addressing, on top of it.

[12] Many REST proponents will argue that HTTP already have a set of standard headers thus SOAP headers are completely unnecessary. The issue here is that a predefined set of HTTP headers [12] has a very well defined semantics and any application specific data requires a custom HTTP header, which creates the same level of complexity as custom SOAP header.

[13] An interesting example of this is usage of the client APIs in many JAX-RS implementations, where interface is effectively a java interface – so much for multi language support.

Really good article, particularly pointing out that REST web services are really just a different protocol used to implement what is architecturally the same thing as what you get with WS-*. That said, having worked with both, I favor using REST as a protocol simply because it better supports my incremental development style that involves manually interacting with the service through a browser. This reflects my history using the ancient, text-based Internet where the analog to the browser was Telnet and I could invoke and 'converse' with services manually e.g. FTP, NNTP, etc. and thereby more quickly debug my programmatic service clients.

The simplicity of REST when i read about it, it's on the client side, you only need to know the parameters the service need and write a simple request...on the other side, on SOAP WSDL and all that stuff you will need a framework, but when you have 5 or more services on different ws-stack...you start to have troubles, the classloader and the conflicting libraries are the most common problems you will found..on my experience the REST aproach is more simpler to work that the SOAP approach. At least on java applications.

Reflecting a bit, I agree with you that calling these 'REST Web Services' is misleading and wrong. My experience is that people use the REST term for practically anything, but when I mention HATEOAS I just get blank stares....

One of the benefits of a true REST implementation is the navigability. Each resource can provide hypermedia with links to potential "next steps". With WS-* style services the client needs more documentation.

Paul.I agree and nice example but being you I would not call REST a protocol :) REST is actually an architectural style and some REST people will tell you it is not a protocol. That is why it makes no sense to compare REST against SOAP.

Hi Gaston.Actually, that simplicity you mention, if I understand correctly, is real, but it is not from REST. You see, REST is hard, actually, as all you should need to know is the initial URL. You should not have any prior knowledge about operations or parameters before hand. It is mentioned in this comments, HATEOAS is a requirement not often met. Knowing about the operations and parameters and even the url format (like templating) before consuming the resource is like having the WSDL not in XML but on your mind, or written in out-of-band.

I also have my opinion about the REST Web Services concept. I do believe the idea is useful but I would not call it REST anyway. Still, JSON is great in web environments using javascript, but in other ones it is requiring a library to parse js to use it, so it is important to check on appropriate technology.

General comments and hints of REST misinterpretation...
by
William Martinez

Hi Boris.Very good article. I specially like the idea to clarify that REST and REST-WS are different things.Here are a couple of comments:

1. I do not like the REST~Resource CRUD idea. You know, HTTP operations have similarities with CRUD, but are essentially different. The GET is not a read, it is a request for a representation. The PUT (often used as an update in REST community) is really a creation operation within the client's control space (it is the client the one that provides the URL or ID of the new resource). The POST is not an update nor a create (as in the REST Community), but an "Send" operation, where you send or post some data TO a resource. What that posting means and affects is totally depending on the actual resource business semantics. Thus, posting may result in a creation of a sub resource, in an update or even in a simple notification without any resource change. You see, not quite CRUD.

2.Nice to have a differentiation between Resource and a Service. Now, there is a difference between a plain Service and a WEB Service. The second is a service delivered through the web. Ha. As web is mentioned, REST is a nice word that may fit here. But, you see, WEB is not just HTTP and web as a delivery system is different to WEB as a System Platform. So... REST Web service looks more to me as a service that is implemented through a set of basic operations on resources that are driven using the HATEOAS constrain. Much more complicated than just saying web as a transport system. Of course, that service has some impedance mismatch associated when used for SOA and may be use sparingly, not as a foundation. See here for my slides on that: www.slideshare.net/willmarpo/explaining-the-soa...

3. REST is more than a set of architectural guidelines, it is actually an architectural style based on the combination of other styles, specially tuned to meet the Web requirements. It is a nice comparison between the resource and a service, but it is also important to compare REST style vs SOA style. REST is for networked applications and SOA for integrated ones, the components and relations are different, etc. And of course, comparing SOAP vr REST makes no sense as they are at different levels.

Mark, I mean no disrespect to your expertise on REST and I claim no such expertise myself. But you must understand that out here in the IT shop shanty towns, anything built with a JAX-RS implementation (or similar) is understood to be RESTful by most developers and managers... You know, it's a buzzword: Use the kit, get the buzz. Good luck trying to convince IT people otherwise... I think it's very hard to get out of the RPC way of thinking and planning; it's simply faster/easier and more concrete to hack together an RPC style wrapper around some data/function (that's probably RPC like to begin with). Thinking and designing with resources, representations and hypermedia is still hard work and takes time. Most developers and managers can't be bothered because they don't see any immediate value. Sadly this story is not news to anyone.

Re: General comments and hints of REST misinterpretation...
by
Boris Lublinsky

Thanks William.Let me try to answer some of your points:In my mind, and I write this explicitly - SOA is an architectural style, while Web services is a communication mechanism. Moreover, in my mind, Web Services is an extremely unfortunate name - it has nothing to do with Web, hence there are multiple binding, SOAP over HTTP being just one of them. Now what you are describing is, in my mind is true REST, not REST Web Services.I fully agree true REST represent ROA architectural style. I am in now position to judge whether SOA is better or worse then SOA, I am only saying they are different and should not be confused.

Paul, You bring up good points on how seemingly hard it is to design RESTful services. SOA as an architectural style isn't constrained; to the contrary, REST as an architectural style is a constrained architecture with very specific constraints; in a sense its opinionated; a term popularized by 37signals/ruby-on-rails.

It is unfortunate that vendors have made developing SOAP based Web Services very easy to develop and put out into the wild, without any service orientation nor architecture; I like to call these services-that-get-the-job-done. IMO RESTful systems are hard because it makes people think about what they are doing.

"Most developers and managers can't be bothered because they don't see any immediate value. Sadly this story is not news to anyone."

Indeed it isn't news and it's a good chunk of the reason why our industry largely under-achieves.

"A “Service” is defined by a verb ( For example, “validate customer’s credit score”, which describes the business function it implements.)"

That's one means of defining a service (functional) but there's another one (data). If one follows the rule of thumb that says "don't move lots of data across functions" (research.microsoft.com/apps/pubs/default.aspx?i...) then one can see that splitting services on the basis of function is often (but not always) a poor choice. The point then is that service design (like all design) is a matter of taste and judgement, not fixed process and checklists to be followed blindly with no thought.

I'm sure the author is full of good intentions, unfortunately they're masked behind an article that is inaccurate and mis-representative of the way in which design should be done. A shame...

Dan,I am sorry you feel this way, but lets stick to the facts:1. I think that one of the reason why our industry is largely under-achieves is because we are not willing to either read or listen. We tend to form our own opinions even before we read or listen to something.2. For better or worse SOA is based on the functional decomposition which often makes it difficult to accommodate enterprise data www.infoq.com/articles/SOA-enterprise-data. As for the data service, it is typically a data access service, which does not really solve the problem of moving data.3. An article is not trying to compare functional and data decomposition. It merely states that they are different. I happen to agree that "service design (like all design) is a matter of taste and judgement, not fixed process and checklists to be followed blindly with no thought." I also happen to think that a good service design is still an art, not a science.4. There is no place in the article that talks about how design should be done. What do I know, I am just an architect.

1) You bring up good points on how seemingly hard it is to design RESTful services.

2) It is unfortunate that vendors have made developing SOAP based Web Services very easy to develop

I may misunderstand what you mean.

I also would like to remind everyone that to the best of my knowledge JAX-RS was designed with Roy Fielding's participating and blessing. Here is the list of "experts"

1.6 Expert Group Members 1This specification is being developed as part of JSR 311 under the Java Community Process. This specifica- 2tion is the result of the collaborative work of the members of the JSR 311 Expert Group. The following are 3the present and former expert group members: 4Jan Algermissen (Individual Member) 5Heiko Braun (Red Hat Middleware LLC) 6Bill Burke (Red Hat Middleware LLC) 7Larry Cable (BEA Systems) 8Bill De Hora (Individual Member) 9Roy Fielding (Day Software, Inc.) 10Harpreet Geekee (Nortel) 11Nickolas Grabovas ...

1. Any real world business service that you can possibly think of can be defined as one of the HTTP methods. In fact, in your example ("VALIDATE customer’s credit score") I stil don't know what service does for me. The consumer is not interested in validation part, but in the outcome of the validation of the thing that needs to be validated. So, from business perspective, the better service would be: "give me customer's credit score". The validation part is the implementation. What I'm trying to explain is that from business perspective the consumer always wants to give or get something. The "noun" can be important, but is only part of the giving or getting. That's why probably in your experience too, almost any service starts with get, save or something similar. Other noun's are rare or have stupid names like "process". So, it's all about the payload and not the service.

2. The comparison with DMBS is clever, but completely wrong. Similarity in methods says nothing about granularity. Business service can be "give me monthly report" which can based on many systems and databases.

3. You are actually admitting that you never haven seen REST based system: "Another question is whether it is possible to build a complete system using true REST". So, based on what did you wrote this article. A lot of theory? The arguments from REST community comes from practical experience.

4. In your article, I did not find a single example of a situation and service that cannot be solved with REST. All your arguments are about technology. I thought SOA and SOAP is all about business. :-)

5. Simplicity vs. standards. I don't really get it what you are trying to say. So, if we implement all those WS* standards we will have great systems? Well, I would rather bet on simple systems which are easily changeable. This is a fundamental difference in the way we see system engineering. Agile crowd tend to go for simplicity, which proves in practice as a better approach. Standards are important, but so often not needed and only a bottleneck in delivering business value.

1) You bring up good points on how seemingly hard it is to design RESTful services.

What I mean by this resource oriented design involves re-thinking how one thinks about distributed systems and thats not easy. While the principles of RESTful systems are very simple at a high level, it involves a lot of design thinking. Which is why you see a lot of systems claiming to be RESTFul, that are really RPC systems over the web; where developers try to shoe horn the RPC paradigm onto a web platform.

2) It is unfortunate that vendors have made developing SOAP based Web Services very easy to develop

With tools/frameworks that allow an object oriented system to be exposed as a "web-service" easily and tools that can generate proxies that can be used to talk to these services; it makes it easy to expose a system thats not designed to be distributed, easily exposed for consumption over the wire. I don't mean this in a derogatory way; you can do good SOA with the tools, its the flip side thats unfortunate.

I like the notion of decomposition and the discussion in general. Well said!

I agree with the select few here who say REST is not a protocol, nor does it dictate HTTP as a transport. It's a paradigm.

As for the difference between a service and a resource, I think it's valid to differentiate but at the end of the day does it matter? I call a service and get a resource. In many ways I can think of them as the same. REST to me doesn't dictate that it's an extension of the database and therefore restricted in data manipulation as a service would do. I expect a requestee to do what it needs to do to service my requestor. Some of my services are really physical resources (address), some are logical resources (payment). Maybe I'm violating something, but it's working really well to allow variance in my abstractions.

What in specific? Do you mean development and implementation or architecture? RESTful systems, provided you understand the principles and constrain the architecture according to them, is technically very simple to understand.

really? anyways, understanding is a moot points, as architects we all know that LOE, cost, ROI, time-to-market is really what counts. Hard to do vs Easy to do is impacting all of them. I guess that should easily close the debate then.

I disagree! Strategically good architecture is important for LOE, cost and ROI. Time to market is not a one time thing. If you don't have a good architectural foundation you cant sustain all of those metrics. Business agility comes with good architecture and good architecture only comes with understanding; be it SOA or RESTful architecture.

Victor, before discussing who is wrong and who is right lets take a closer look at your objections:1.

Any real world business service that you can possibly think of can be defined as one of the HTTP methods.

There are two issues here. Services in SOA are not necessarily services delivered to end user. The majority of SOA services are the building blocks of the solutions satisfying user's needs. Second is that they can not really be delivered as an HTTP method. They can be delivered using HTTP as a transport and there is a big difference between these two statement.

from business perspective, the better service would be: "give me customer's credit score"...The "noun" can be important, but is only part of the giving or getting. That's why probably in your experience too, almost any service starts with get, save or something similar.

With all due respect I disagree. In your example, The noun will be "calculate Credit Score" and a customer will be a parameter.

2.

The comparison with DMBS is clever, but completely wrong. Similarity in methods says nothing about granularity. Business service can be "give me monthly report" which can based on many systems and databases.

First its not mine, its belongs to Nene. Second the comparison is on API not a granularity level. The resource can be as complex as it needs to be.

3.

You are actually admitting that you never haven seen REST based system: "Another question is whether it is possible to build a complete system using true REST". So, based on what did you wrote this article. A lot of theory?

Well, I have been an architect for about 15 years, developer before that. I have done quite a few systems implementations. What I am saying is that every REST implementation that I did or have seen always was a mix of True REST with REST Web services, which disqualifies it as a true REST implementation.

4.

In your article, I did not find a single example of a situation and service that cannot be solved with REST.

Yes, but it will not be SOA system anymore. That's my point.

5.

Simplicity vs. standards... So, if we implement all those WS* standards we will have great systems? Well, I would rather bet on simple systems which are easily changeable. This is a fundamental difference in the way we see system engineering.

The problem is that the absence of standards leads to proprietary implementations, which makes it significantly more complex (more code to write and maintain) and hinders interoperability. As for simplicity - I am all for it. Use only what you need - problem solved

Dan,I am sorry you feel this way, but lets stick to the facts:1. I think that one of the reason why our industry is largely under-achieves is because we are not willing to either read or listen. We tend to form our own opinions even before we read or listen to something.2. For better or worse SOA is based on the functional decomposition which often makes it difficult to accommodate enterprise data www.infoq.com/articles/SOA-enterprise-data. As for the data service, it is typically a data access service, which does not really solve the problem of moving data.3. An article is not trying to compare functional and data decomposition. It merely states that they are different. I happen to agree that "service design (like all design) is a matter of taste and judgement, not fixed process and checklists to be followed blindly with no thought." I also happen to think that a good service design is still an art, not a science.4. There is no place in the article that talks about how design should be done. What do I know, I am just an architect.

If you agree service design is a matter of taste why are you prepared to be bound by SOA being defined as a functional decomposition? Presumably some element of the industry has decided this is the rule? There are a number of examples of SOA's that aren't decomposed by pure function and with good reason (see my original reference to Jim Gray's analysis).

More importantly, if one ignores this rule of functional decomposition being the driving design approach for an SOA, services start to look a lot more resource oriented and can thus be made RESTful.

"There is no place in the article that talks about how design should be done."

Except that you insist that SOA is all about functional decomposition, which is an assertion about how design should be done i.e. you cannot focus on a data-based approach.

"As for the data service, it is typically a data access service, which does not really solve the problem of moving data"

Typically is not a rule though, so one can design a data service that isn't about purely data access and thus does address the moving data problem.

More importantly, if one ignores this rule of functional decomposition being the driving design approach for an SOA, services start to look a lot more resource oriented and can thus be made RESTful.

That is exactly my point. If you do this, then you do not have SOA. You have REST. SOA is an architectural style, which defines services as a result of functional decomposition.

so one can design a data service that isn't about purely data access and thus does address the moving data problem

Yes, but this is yet another architectural style, which I am using a lot lately with my Hadoop - based implementations.Once again - my point is that there are many architectural styles in a true architect toolbox and he has to pick the one or combination of several to do his job. The is the right thing to do. He also has to know exactly which style and why he is using for solving specific problem.

The SOA group of the enterprise I consult with has developed a data oriented scheme for organizing service interfaces.

All services are organized around major entities (such as Customer, Part, Vehicle, etc). This organization is apparent in the WSDL target namespaces (e.g. urn:customer/...; urn:part/..; etc). All new services are organized this way.

There is a kind of a macro-level OO'ness present here. Service operations are considered as operations around a major entity. An entity can have multiple services allowing us to grow an entity over time.

"Anyone who claims that REST is something other than what is in my dissertation is just babbling nonsense -- the dissertation defined the term (and other people making it a buzzword won't change that)." -- Roy Fielding, 2006

The goal is to build and an 'enterprise api' over time. Realize that enterprise data models are very complex (much more so than say facebook or ebay public data models). So the api we are building is virtual as it is composed of different services implemented by different groups, over time.

The key is that we are using major entities (as opposed to functions) as the organizing principle for services. The api is discoverable via the registry (and we have prototyped ways of making it browsable by entity in a nice Silverlight front-end).

Business processes 'stitch' services together. Most of these are implemented as applications but many are implemented with BPMS tools. We heavliy use intermediaries such as xml gateways and have started to use an ESB for async and pub-sub.

I don't want to give the impression that we are already there and successful. This is a journey that we have been on for over a year now. All I can say is that we are progressing well and have not found any major disconnects, yet.

Besides the mis-information about REST, I think the article mis-represents the very issues of the problem domain. Maybe the problem is more one of the writing than of your knowledge of the problem space? Could it be that the points your are trying to make simply don't come across?

If WS-* is the RPC of the Internet, REST is the DBMS of the internet…
by
Leo Gan

Great article. “If WS-* is the RPC of the Internet, REST is the DBMS of the internet…" - I would rather say:REST is like a method to manipulate data with set-operations (Insert, Delete, Update, Select), WS-* is like a way to manipulate data with stored procedures. sp-s do create an additional abstraction layer for the same reasons and with the same results as WS-* do.

Faisal,Of course this is real, but...What you are describing is really two level functional decomposition. What you are calling entities, I can call functional areas. The approach that you are describing is actually very close to IBM's SOA definition model. The fact that you are using BPM for orchestrating services, means that your services represent actions - that is what process consumes. I think we are talking about same things but are using different terminology,

Jan, thank you for the benefit of the doubt.Of course I am not the best writer, at the end of the day my PhD was in EE not English literature, and besides, English is my second language. But may be, just may be not all the blame should be addressed to me. May be some of the problem is the way people are reading this article. Quite a few comments that I see here puzzle me. The article is NOT about benefits or shortcoming of either REST or SOA (sorry, both of them have shortcoming), its about the fact that they are different styles.Now, what exactly did I mis-inform and mis-represent? If I am blamed for something I prefer this being more specific.

The data transportation mechanism you use to carry event notifications and parameter values from a client to an application does not change the architecture of that application. The application interface is always (if OO) one or more roles performing operations on business entities. No external thing EVER accesses a business entity directly but goes through a role (to give RBAC). A set of operations supports a business process run by the roles and is called a service. Web or restful services are at a lower layer in the ISO 7 layer model. When such a service is invoked it has to translate to calling an operation on a role. This is exactly the same as you do in a GUI though in a thick client the widgets may invoke a role operation directly. A restful interface can talk about modifying a business entity directly but it never does – it is an abstraction exactly as we have been doing for years in GUI design. The RBAC “layer” has to be there.

2. Purchasing – Managing the sourcing of parts from one or more suppliers (supply chain)

3. Manufacturing – parts eventually are included in an end product (such as engine or transmission) and have to be tracked as part the bill-of-material of the final product. Also part of the supply chain.

5. Finance – cost analysis of parts and bill-of-materials; other types of analyses

The above is what we would call functional areas. The entity Part cuts across them all. Each functional area itself is huge in terms of Part data and business processes. The only data element common across all functional areas is the part-number.

While the functional areas appear to be silos they are in fact all linked together with complex interdependencies. For example, warranty repairs may trigger engineering design changes with cascading consequences. There are also interdependencies between different entities such as Part and Vehicle.

Systems in the functional areas were pretty much silos before SOA. With SOA we can link the functional areas better and reduce (but not eliminate) data movement. The approach we have taken gives us a consistent way of building a façade to enterprise data and processing. Operations around Part can be logically grouped together in a coherent view, even when each service/operation is managed by a different functional area.

There is so much metadata that it would be impossible to deal with the data without some kind of metadata description language that is machine readable. Operations are not all CRUD type. There are set operations and other business process specific operations.

Also it is impossible to create a single model for any major entity as that model keeps changing all the time and no one person knows it all. We deal with piecemeal models of each entity in relation to service calls – with contracts and versioning.

The challenges are enormous and I don’t want to minimize that. We have our feeble attempt to address these challenges, which seems to be working thus far. Whether we are ultimately successful, we don’t know.

Clearly, there are different levels of abstraction being represented by the same terminology. Are [Service | Resource] Oriented Architecture representing the same level of abstraction? And are they mutually exclusive? Or does 'Service' simply represent a business offering or solution, while 'Resource' represents a business concept or entity? And so, can a Service be a Resource, or vice versa? Of all the terms here, REST seems the most clearly defined based as it is on other, already well defined Internet characteristics through Fielding's thesis. However, it's level of descriptive abstraction seems to me completely orthogonal to the so-called architectural styles being argued above. It seems to me more like a design technique than an architecture, though it is itself is an abstraction of certain Internet architecture properties. The use of the word 'protocol' also requires better care in usage: It does not always or only refer to networking and communications. A protocol just describes the discrete steps of some process with well defined results. Consequently, we may use the term at practically any level of descriptive abstraction. I still think the article is quite useful and well written in that it brings up several points well worth further discussion. And it does take care to try and carefully define terms. Readers just need to be a bit less orthodox and parochial in their reading of it.

If it helps, here are some ways in which the article seems to misrepresent REST.1. REST is not built on the HTTP verbs. REST is a style and those verbs are part of the HTTP realisation of that style. Rheims Cathedral is built in a gothic style, but that does not mean you have to look like Rheims to be gothic. You can be RESTful without using the HTTP verbs.2. The descriptions of PUT and POST are confused. A PUT is idempotent, but creating a new resource is not idempotent. 3. REST is not about entity beans. Just because the HTTP verbs can be interpreted as CRUD (Create, Read, Update and Delete) does not mean that REST is just for CRUD. It is for managing resources. Where a resource is directly mapped to an Entity, it will look like an entity. Where the resource is not directly mapped to an entity it will not. For example, you can use a Transaction resource to manage a transaction using REST.4. The other defining characteristics of REST are ignored. Namely: multiple representations; every resource is a URL; Hypertext as the engine of application state. These are far more important to understand than the universal interface. 5. The context of REST is ignored. This is explicitly a style for mediating between user agents and resource managers. There is no such context for Web services.6. The reason why RESTafarians believe that WSDL is not needed for RESTful services is completely misunderstood. It is precisely because it is the User Agent's job to represent a resource, but the person's job to understand it, that WSDL is not needed at run time. REST does not need expensive dynamic binding like SOAP.

For these reasons, and a few more, I concur with Mark Baker's assessment of the article.

Thank you John, these, at least I can try to answer:1. Technically you can, practically I've never seen it.2. Sorry, my and inspire.jrc.ec.europa.eu/reports/ImplementingRu... mistake, which does not really change anything in the content.3 Comparison to Entity beans has nothing to do with CRUD. The difference between Entity beans and Session beans(I know it was long time) is that an instance of Entity bean is associated with the explicit resource (database record), while Session bean is resource independent and resource is passed to it as a parameter.4. Yes, I did not write about these additional features of REST, because they are not relevant to the topic. I do happen to know about them, but this was REST usage for SOA article, not REST evaluation.5 I personally think that JAX-WS model with dynamic WSDL processing is a mistake (i prefer JAX-RS model with the static generation). For me WSDL is important for formal definition and client code generation. I still concur that the absence of WSDL in REST is a bad thing, leading to creation of client frameworks in packages like RESTEasy and Metro, which are using annotated Java interface in place of WSDL

Faisal,I might be wrong, but it feels like part belongs more to the canonical data model than to service definition. Also, when you are saying things keep changing, which is normal. The question is whether base entities are changing fast (should not happen) or the processes orchestrating these services are changing (expected).

It is hard to completely model a major entity like Part in a large enterprise. A major entity has its tentacles in many functional areas. It will have to be a coordinated effort of multiple knowledgeable individuals and will require so much time that by the time its done things will have changed.

In the meanwhile we can't stop groups building services to support the process they are implementing.

Changes in business process and new processes often do require new data to be kept and managed which many times is associated major entities.

I think the right 'solution' to the modeling problem is to move to semantic models (owl,rdf)that can be grown organically over time. However that is a major shift from where enterprises are today. Perhaps the adoption of NoSql/graph stores will slowly move us in this direction.

It seems, that your are mixing the semantics of "simple" and "easy". The uniform interface is simplistic, which means it is "artles" or "plain".

A priori knowledge

You have to know more, than a single bookmark URI. There must be an agreement on media types and relation semantics. Furthermore, no one hinders you to use a schema to describe you representations.

Lightweight

Did you ever try to consume SOAP service with mobile clients? Microsoft did a pretty good job there on their mobile platforms. But all others have really bad support for SOAP. Why is that? I think due to the restricted resources on the phone.For AJAX clients its very easy to consume REST "Services" due to JSON support.

REST based on HTTP

Really? from Fieldings Diss.:"REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components. For example, the Web's primary transfer protocol is HTTP, but the architecture also includes seamless access to resources that originate on pre-existing network servers, including FTP , Gopher , and WAIS ."

Nature of Resources

Resources are not only "things". An activity/task/process can be a resource, too (see pautasso's work). Fielding: "Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource"

-----------

I love some stuff in SOAP world (e.g. proxy generation). But i think, REST has some really "cool stuff": The biggest power of HTTP/REST is the linking of things. Through the simplistic nature of the interface, everything is linkable - even task/activities/processes.

By the way: A REST-based web service is (usually) not a single resource.

The functional complexity is split up on multiple resources. Some of them may be activity resources. I dont see, why a SOA can´t be realized with the REST approach... The functional decomposition is just different in comparision to the SOAP/RPC style. Here, a service is one endpoint with multiple methods.