First, let us review what is the concept behind services, with particular mention of the web services themselves.

A service is a business functionality exposed by a simple interface. Note that it is not an object, nor a method, nor a module, not a procedure. It is pure business functionality.

Services are consumed, not called, nor executed nor invoked. We define the service consumption as the interaction between agents, a client and a provider, which will communicate using a messaging system, where the data unit is a document. Consumption may be local or remote (meaning a service may not require remote communication).

A service may live in the web, where they are modeled as resources, identified by a URI. If not living in web, as suitable endpoint implementation should be provided.

A service is described at business level with a contract, where a glossary of the terms is agreed upon, and the semantics of all business concepts and processes are clearly stated and known by interacting parts (this is important). The service implementation is defined by the service name, its contract, an endpoint (unique entry point/port) where to send messages, the operations the service offers, the message interaction flow, the message composition (including the document definition) and optionally a binding information.

Nice definition. What is wrong with it?. Not much, actually. Just that when Web Services Architecture group decided to make those concepts into a standard, they did a great job, but also committed a couple of fatal mistakes.

The first one was the actual selection of SOAP as the messaging protocol. Yes, SOAP is a big mistake, not because it is SOAP, but because of what it was created for. You can read here a very complete explanation of the SOAP origins by one of the people that worked on it, Don Box. There, we can understand the main problem to solve was creating a protocol to better support RPC (actually RMI) in a object distributed system.

Yes, SOAP (Simple Object Access Protocol) was not created to support services documents and messaging. It was created to provide a technology neutral data/class definition system, plus supporting remote method access (that actually meant Remote Method Invocation).

So, why is this a mistake? Well, unless your idea of services was, from the beginning, that of distributed objects and the exposition of their methods, SOAP was no fit for a Services architecture. Why is SOAP there, not sure, but my common sense tells me it was not its place. If the idea was to support document oriented messaging, an RPC protocol was the weirdest decision I can think of. You will need to tweak the protocol to support what it was not supporting before. The only reusable aspect is that it was meant for HTTP transportation, which by the way is not a constrain of the WSA (it is the only implementation though).

History tells that soon after, SOAP was modified to allow document style definition, relaxing the literal RPC format. The SOAP acronym meaning was actually changed! So it is not an object access oriented protocol anymore, but a service oriented one. That should prevent people using it for RPC, was the hope.

Ok, if that was fixed (SOAP adjusted), we may have no more problems with that, right?
What is the second mistake?

Well, a subtle one: they kept the RPC idea in SOAP. Backwards compatibility? Not sure, but the RPC literal was there, in SOAP. Worse, the WSDL included that option and WSA did not discouraged the practice! I may think it was because there were tools supporting this and the idea was not banning anyone from using them. So, people started (or continued) using RPC and calling them services!
Is that wrong? Well, a little:

a. The problem is RPC is not Services,
b. RPC does not share the service metaphor,
c, RPC has different implementation side effects,
d. RPC usually forces fine grain while Services try the contrary
e. RPC couples (per method name, parameters and interaction)
f. RPC is in the IT domain, while services should be in the business one (this is a big one).
g. RPC usually works in the distributed environment, but services not are always distributed.
h. RPC forces request-response flow, while services may have any combination of flows.
i. RPC is usually blocking, synchronous. Services are asynchronous per messaging basic concepts.
j. RPC parameters usually require serialization of objects (to be passed as parameters). Services do not even know what objects are nor the parameter concept, they deal with plain messages.
k. In HTTP, as a particular implementation, RPCs mapping of concepts adds overhead to the call, while Services uses HTTP just as a transport and should not add more overhead.

Ok but, what about that? In case the RPC was kept due to tools, the existing tools at that time may be kept as RPC tools, and new tools to work with services and their concepts should had been created. Easy solution.

But that didn’t happen.

Actually, the tools took over and started to fight back! There was almost no support for document style. There was an RPC style non encoded. There was no standard way to represent a document (that you can feed the service call with). Yes, the tools claim they supported document style. But when I did some research projects to compare the tools, I found the services created using document styles didn’t work at all! I created a service, then I created a client using the same tool, and the client failed talking to the service! I made it work by manually structuring the XML document to have the first element named as the method that implemented the service! It was RPC all along, and since nobody complained, I assume no one was expecting to work document style. Well, there were a few.

But the worst comes afterward, with the creation of the Wrapped and Bare modifiers. They are no were in the WSDL nor the WSA. The wrapped is a way to use document style, but doing what I did manually in the lines above: formatting the XML to reassemble an RPC format message! You know what, testing the BARE modifier yield what I suspected: didn’t work.

That means the tools and server vendors are still selling RPC, creating RPC “services” and RPC clients. The ones that supported the document style, did a great job making people stay away from it, like Axis, whose example of RPC is a couple of lines long, but the same example using document style is gross and long, not even I could read.

Ok, granted, the web services implementation are just RPC in disguise. So what? We’ve been using RPC all our lives and we are happy with it, right?

Well, SOA is a style that looks forward to have its structure and components made out of business functionality. Under that assumption, we can build lots of additional features, like business composition (business processes), orchestration, governance, etc. But, for that we need services as business functionality, decoupled by an uniform interface. RPC adds coupling to the mix, since we are adding the object or library concepts (for many, those two are the same!) , the method invocation interaction, the data coupling in the arguments lists, and the stiffness of non-variable method definitions (just change one argument and all breaks!).

Point (f) above is important. All other features of SOA are built on top of the concept of a business functionality exposed as a service. Governance, composability, visualization, all those work with services, not with function calls. So, as mentioned in point f, what surfaces is IT, not business, and thus the features may not work as expected.

Add to the mix that, to actually create the services, you must be a programmer. Since they reflect the RMI concept, we assume distributions, method and parameter passing knowledge, etc. Even more, the actual code is converted into exposed services, bottom up approach. This will create services shaped as the actual legacy implementation, which may not match the actual business at hand. The top down approach, which should start with the definition of the service at the business domain level, is discouraged. Tools offer not help there (or very little), and only a few architects follow that path. So, the RPC influence is breaking the possibilities of actually taking advantage of the Services metaphor.

Can I say that the whole failure of SOA as a agent of change, an encourager of business over IT in systems, a provider of business valuable concepts like business processes, governance and product composing, is just the intrusion of RPC in the whole dance? May be, but there are other causes as well. Still, SOA may not raise from he tomb if no paradigm shift is achieved.

Wait a minute. REST is in the title, it is another problem in your list? Or is it just the enemy of SOA?

Well, not really. REST is another architectural Style. It was made for a very different problem and I can assure you it is not the replacement of SOA.

It is in the title because of two reasons:
1. People think the problem of SOA were the Web Services using SOAP,
2. and also people believe REST is a simple way of creating the next generation of services.

So, they are adding another point of failure to the new SOA by trying to construct SOA using what they call “RESTFull Services“.

Why is it a fail point? I’ve heard REST services rock!

Well, first I own REST an apology. You see, actually REST has nothing to do with this. The problem is with the wrongly named REST services, which are no more than an API based on HTTP. Now, there could be REST services, but they are much more complex that the ones most people use. And bigger. So, let’s simply call those “Not-So-REST Services” as Web API Services, (WAS? Nice acronym, a provider for one of those would be a WASP!).

Well, our WAS are, as usual, more oriented to functional calls (yes, RPC). There could be a way the WAS achieves a truly service meaning, when using HTTP as the messaging transport, and the Hypermedia as the documents. Yep, it is a nice match. But that requires people thinking on documents and interactions through messages, and they are not doing that. If you check, it is the same old RPC story again.

So, what to do then? Are we doomed, I mean, is SOA doomed?

Not really. We need to understand what a service is about, and provide a suitable implementation that allows developers to work with it without mapping. I mean, why does a service need to implemented as an object method call? It breaks the metaphor and thus breaks design and implementation, making it flawed.
I’m working on a DOSE (Document Oriented Service Engine) implementation in Java, WAS and WSA oriented (WSDL 2.0, that is), with no RPC. The programming model should be quite different that the proxy and RPC model, plus a set of articles to show how design using document orientation for services should be done.

So, stay tuned.

Commenting on Tim Bray’s blog post about the use of Post for REST, I came to a discussion about actually how much RESTFull is an API, and more specifically if it should be RESTFull at all.

You see, many people is trying to get their APIs into the REST world, and some people like Dilip Krishnan believe the reason is to gain "simplicity, discoverability and serendipitous reuse of the solution". Still, as I read through all the comments on how to "imagine" the app so it fits REST, I feel a greater sense of something not right about it.

When creating a solution, you may want to analyze first the functional requirements, and then the quality properties. The ones noted by Dilip are great, but I’m not sure all apps that hit the web every day need to accomplish them. Furthermore, REST is not the only way of getting those attributes! Let’s explain a little what this famous style is so you can understand what I’m saying.

The REpresentational State Transfer style was born as an architectural style to represent/improve the modern web implementation, as Roy Fielding explains in his dissertation. So, REST is an architectural style, and that means it has a set of constrains that the app needs to adopt to obtain the benefits. But that architectural style is not built from scratch. It is built by composing several other well known styles like Client-Cache-Stateless-Server, Layered-Client-Server or Code-On-Demand. Any of those can be used separately and all their pros and cons will be cast upon the solution.

Now, this is a special case where an implementation is taken as a base to develop an architectural style that improves it. Usually, you have a solution to build with a set of requirements, and you look for an style that better fit into the problem. But once you start changing the problem just to adjust to an architectural style, you are actually “Wagging the Dog” there. And it seems to be a contagious syndrome.

So, what does it need to have an APP to be worthy enough to use the style? Well, first

• - the semantics should be the ones of the style.
• - Next, the app should try to solve a similar issue the style is solving, and third,
• - the app’s quality attributes should be the ones the style is promoting.

If some of the three is not true for your app, and you still want to use the style, I may guess you are trying to get the buzzword title instead of the real benefits.

One little clarification at this point: The web is one implementation that follows the style, it is NOT REST itself. What do I mean by that? Creating an app that runs on the web doesn’t make it RESTFull. Using HTTP for your API won’t make it either (I wanted to clarify it since all comments are about HTTP and its semantics and it seems everybody confuses the implementation with the style). You need to read the dissertation to learn all the constrains, but even more important, to learn if the style is for you or not. You may learn HTTP is not a required protocol, but one constructed that meets the constrains. You can build your own! (and make it standard).

William Martinez.

Through all these years, the service concept has been a confusing one. At the edge of Service Era, even before the service name was coined, services existed and were implemented using the tools at hand, and the tools helped to define the concept. I mean Services in all their presentations, those including SOA and Web Services, REST and CORBA, etc.

Today, after all this time, hundreds of articles, papers and news had been written explaining all facets of Services. Yet, many of them presented conceptual differences, and in the community’s mind a mix of myths started to grow.

The following is a list of myths I’ve encountered to be still present nowadays. Some are innocuous, some others are not. Furthermore, some may not be considered myths at all for all people, since their opinions may differ from mine. Anyway, here they are.

Myth 1: SOA = Web Services.
More that a myth, this is a general confusion enforced by tool vendors. Why? Because of selling SOA ready tools that offered Web Services construction, so conceptually having SOA was simply achieved by having Web Services
.
Reality: A Service is a bunch of functionality that is cohesively integrated into a locatable resource and accessed through a port using messages. (No, it’s not an object).

SOA is an architecture style that simply indicates the use of Services (special functional units) in the architecture. That is, you can have several very different architectures that are SOAs, with the common characteristic of having services in them.

Web Services Architecture is a special architecture that defines the description, interaction and messaging definition for a service that uses the web to communicate. Note that the service concept is part of both things, but Services are not limited to be Web Services. Web Services is just a way to create services. And Services may not use that architecture, nor be implemented trough the web.

Myth 2: Web Services = RPC.
SOAP (Simple Object Access Protocol) was born to make remote objects accessible through web. Its initial goals were clear: allow to encode a method call through web using XML. Later on, the service definition and concepts were improved, not limiting it to remote object method invocation but to a messaging system (even SOAP acronym changed to Service Oriented Architecture Protocol), but the “traditional” way of doing things kept implementing the services as simple remote method calls. In other words, a simple RPC.

The Service concept states the communication should be using messages, and those are all one way. If you want a request-response behavior, you need two messages: one in-one out. So, at the end, the services concept accepts RPC, but services are not RPC.

Martin Fowler states that difference in the book "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (The Addison-Wesley Signature Series) by Gregor Hohpe and Bobby Woolf", when he writes about integration by sharing. RPC is good to share functionality, but services will help to share functionality and data, and they are the less coupled form of integration.

Pages: 1 · 2 · 3

Paul kindly pointed to a blog entry about WADL use in REST, (WADL definition is found here). The Blog entry was interesting to read.

I want to quickly explain that WADL is meant to describe the possible interactions with a Web Application. Thus, it has methods, but those are HTTP commads, and it also describes the query variables (like the fields in a form) that the method needs to send to the web application. Finally, it describes the expected response.

Now, in the blog I see some misconceptions. First, it relates SOAP and WSDL to XML-RPC. That may seem true due to actual use of those two, but SOAP is just a wrapper and WSDL does not enforce XML-RPC, using document/style it reassembles a simply document sending paradigm. By the way, XML-RPC and WS used to do RPC are two completely different things.

Second, the REST based Service concept is defined to encompass even static web pages. May REST style architecture handle resources in the web, and REST “style” Services are services implemented using the REST underlying paradigm. But Static pages are not Services.

Third, WADL is at implementation level of the HTTP call, thus it does not define the service, just what to call and what to expect in response. That is not bad, it is actually good, but then WADL describes an HTTP interaction, while WSDL describes a messaging interaction. Although not actually standardized, WSDL may allow you to send messages using a message queue, SMTP, or any other transport.

Now, I want to explain my vote. I’m not a WSDL lover, I think it may be improved. Still, I’m carefull to compare, it is not as easy. We cannot say WADL is a description document for REST based Services and WSDL for RPC based ones. Right?

I may want to go even further. I may say REST Style Services may actually make use of both! Yes, while WSDL describes your Service at message level, defining the document and port, and a WADL that makes clearer the HTTP interaction (since WSDL inly indicates you are using HTTP as a transport).

Again, what do you think?

William Martinez Pomares.

I a recent comment, Paul mentions he is not familiar with the Document Style concept. This is a great opportunity to touch the theme and clarify some ideas about WSDL and the WSA idea of a service.

WSDL is meant to describe the service definition and interaction models. WSDL defines:

• The Service’s visible endpoint. That is, the address where the port of the service leaves.
• The Binding. That is, which transport to use and how.
• The Operations. Each operation with a name and a message flow (a named message inbound or outbound).
• The Messages. Each named message has a number of named parts that conform the payload.
• The Parts. Each one is defined either by indicating the primitive type or a schema defined xml.
• The Schema. A Types section that is defined using an XML schemas.

Using the above sections, we can define the service by indicating the port, the available operations, which message flow each operation has, and what is the structure of each message.

With the WSDL, the client is able to know how to construct the message and where to send it. So far so good for our service notion.

The problem comes when WSA came out with the style/encoding idea. SOAP was originally created to access Objects remotely (Simple Object Access Protocol). Here is the story.

Those were the times when RPC was the idea of remote access. So, SOAP was created a requirement for the body of the message. It had to be constructed with a fixed structure, where the root element’s name should be the same as the method name. The children elements should be one per parameter, and each one containing the type as an attribute. That structure was known as the encoding.

Pages: 1 · 2 · 3