A RESTFull WSDL?

In 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.

When WSA brought SOAP as the protocol to form the messages, it extended the idea in two directions. The first one was to allow some flexibility by defining a non-encoding format, and that was called “literal” (as opposite of “encoded”). The other direction is the style of the access. The RPC style is the original for SOAP, where the service is accessed by mimicking an RPC by indicating the method and parameters in the message and expect a response.
The other one is the Document Style. In this style, the idea is that the message contains a document (XML usually) that is delivered to the port.

The combination of style and encoding gives us four possibilities: RPC/Encoded (original RPC/SOAP style), RPC/Literal (A new RPC that is not that strict, see below), Document/Encoded (Nonsense), and Document/Literal (what all of us should use).

Now, let’s focus in RPC/Literal and Document/Literal. When defining the operations, the developer is able to indicate, per message, which style and encoding to use. If RPC/Literal is selected, the following rules apply:

• The body of the message is an XML with a root element whose name is the name of the operation.
• The children of that root element are the parameters, in order, for the implementing method.

A client calling a service’s operation defined as RPC/Literal, should create a message then that reassembles the structure of an RPC SOAP Message. The important thing here is that the XML in the body is created automatically with a root that has the operation name.

If Document/Literal is selected, the following rules apply.

• The body of the message is an XML document. No other restriction is given.

Note that with document/literal, there is no restriction of the body format. If by chance the root of that XML is not the name of the operation, it doesn’t matter. In reality, some of the vendors I tested, even if document style is indicated, will look for the name of the method to call in the first element of the body.

So, now imagine a service at port http://willyloans .com, that uses http, that has an operation called LoanRequest with one inbound message. That message is a one-part message, document style. That part is an XML document defined in the schema at Types section. The client should simply create a SOAP wrapper XML, and in the body element it will add the XML document (Payload). The client then simply sends that SOAP to the address defined in service (always using a post, WSA defined that).

That’s it. Using WSDL at document style, you can interact with the service just by sending a message containing a document, delivered to a port. NO method names nor parameters. That should be a RestFull call as Paul indicates, but with the help of WSDL that describes the flow, port and the XML document schema.

Hope this explanation helps.

William Martinez.

Reference and Comments: A RESTFull WSDL?

A REAL service definition

Based on several comments and articles I've read, I tend to think that SOA and Web Services are being misunderstood. Maybe I’m the one that is wrong, but just in case I will try to explain here what I understand. I guess the first thing to do is to define what a service is.

Base on the Web Service Architecture specification, a service is “… an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities.”

I want to point out the fact that a service is a “resource”, it can perform some tasks, and it represents functionality. A service has an ID that will let us find it in the networking cloud. It has a description and it has an interface. That interface “… is the abstract boundary that a service exposes. It defines the types of messages and the message exchange patterns that are involved in interacting with the service, together with any conditions implied by those messages.”

Let’s put it in other words. A Service is a coherent functionality offered by a web resource. To communicate with it, you use its interface. It will accept messages interchanged in a predefined pattern.

But there is an important fact: “To be used, a service must be realized by a concrete provider agent.”, WSA spec says. In other words, a service is an abstract model of a resource. That functionality is to be realized by a concrete agent, may it be software or hardware. Let think of it as a functional cloud, accessed by messages delivered to a port.

An Example may help.

Service: Loan service.

Functionality: Actually, the service is able to process loan requests, payments, notifies due loans and you can ask for a loan status.

How is it done?: There are four document types, each one has a particular schema: LoanRequest (input), LoanInfoRequest(input/output), LoanNotification (output) and LoanPaymentNote(input). Any input XML document may be sent to a port located in www.willyloans.com/loanport or to the email loanport at willyloans.com. There, an XML processor will determine the schema type, and send the actual data to the loan analysis department, to the loan payments subsystem, or to the loan service desk system. You can guess what each system does, and what each document may contain.
You can create four WSDL if you want. All pointing to the same address. Just make them document style.

Note that the service doesn’t reassemble an object. It has no methods or attributes, just functionality. You don’t call it (although pure objects are supposed to receive messages), and they may not have a response (although they can send a message back, or the same modified message).

Mainstream is actually building web services from the actual implementation. Instead of creating a service that is realized using exiting classes and systems, developers are simply exposing their methods and objects. They are using an RPC model instead of messaging. They are architecturing a distributed object system instead of services.
This leads to several myths and perceptions that make tool vendors offer what developers want, and none is working towards a truly service development.

I will check on those myths in future posts.

William Martinez Pomares

Reference and other comments: A REAL service definition

YAMTCARO and the Service apology

I just wrote an answer in TSS that I thought I could share here too. The basic idea everyone has about services is that they are to distribute logic, make remote calls, have loose coupling interfaces, and are resusable. And nothing is working as it is advertised. I will play the defendant part here.

“I see a repeating idea about SOA, services in particular, that doesn’t fit in what I have learned from my childhood as an architect. I will explain myself.

I recall the old Object oriented days when all the fuzz was about reusability. The idea was clear: separate the code into coherent and functional complete things. Then a problem was found: the interface. You could not reuse the thing because of the interface not being suitable, or requiring things not in the new problem domain.

Then a service came. It was the idea of having a business functionality (not an interface, not an object) able to accept messages and offer a business value. It has no reusability concept, the fuzz was actually about replacing fixed interfaces with a simple port. And somebody said: Let’s implement it with SOAP. And SOAP was Simple Object Access Protocol, an RPC oriented wrapping protocol used to access distributed objects. Wow. Wait a minute. Something is not working here. I know objects were supposed to accept messages. Nobody uses that. But a service is not an object. A service has no methods or parameters. Definitively, it has no response. There is no interface per se, just a port where you deliver your message.

Now, the message is not SOAP. SOAP is a wrapper. The real thing is in the body.

Once the service has read from the port the message content, it will now know what to do. And it may decide to send another message. As simple as that. But as difficult to grasp for an object programmer, that it was reduced to a YAMTCARO (Yet another method to call a remote object).

NOw, can somebody tell me why a service needs a method name to be called? SOAP had stubs in the client, to simulate the remote object as local. Services are not object, stubs have no place here. Makes no sense. You need a port object to stream your message. Simple.

Finally, since a service is just a port, and the service semantics (which are not technically describable) is hidden behind the service cloud. You can create a versioning system underneath the cloud, so old messages can still be accepted and new messages, that represent new business needs, be processed as required. Service cloud still as white as before. It may have a new port, but old ports may be still there.

Enterprise architects? Their job is to have one eye in the problem space, and the other in the solution space. They will work with business people to design services scope (business driven), and work with designers to technically create the structure of the cloud.

Hope this helps to understand why I say all that I say.”

William Martinez Pomares

SOA in all sizes

Funny article in SOA Masters Class site. It explains the vision of SOA based in two variables: the Architecture involvement scope, and the Service concept scope.
Yep, there is a big difference when you see the Service concept as an exposed component, or as business functionality. Same for involving the architecture simply as a glue to interoperate disparate systems, or as a business driven structure.

Funny indeed!

William Martinez Pomares

First Post, an SOA discussion!

Hi All!

Very excited that I’m writing my very first post in the blog.
And since this is an Architecting blog, I thought I could point it to a very interesting discussion held at The Server Side.

The article presented here is about the complexity generated when using SOA, compared to the same complexity history of CORBA times. Although the idea is nice, most of the participants show a problem of understanding what SOA really is.

System Integrator Technology? CORBA with a new acronym? A new distributed approach to organize business logic? Simple EJB, SOAP and other technologies follow up, with nothing new? No several times.

As I mentioned in my responses there, SOA is based on the service Metaphor, which is placed in the problem domain, problem space, where business organization rules and not technology trends. SOA now is a patched, almost like a stovepipe architecture, solution for integration, and like that it sells.

Later I will write a little bit more about the Service metaphor. That is not for RPC developers, I’m sure.

William Martinez Pomares

The Case of Emergent Design.

This one I owed it since a long time.
In the year of 2000, David Cavallo published his article "Emergent Design and learning environments: Building on indigenous knowledge". In this article, the term "Emergent Design" was coined, as an alternative of blueprints. Cavallo indicates that many analysts researching the situation of educational change projects failing, was actually because of the committee-generated blueprint that was created to drive the change. The result was always a reformed implementation of the blueprint that did not solve the problem.

So, Cavallo proposes another "way" of doing that process. He bases his discussion in two innovations: The Digital technology and the Administrative decentralization. The second one does not change the management practices, but only lowers them to other levels in organization to be distributed.

Now, Cavallo proposes some principles to guide this. Constructionism (Papert, we build knowledge when we construct things), that is based on Constructivism (Piaget, we build upon what we already know). The other ones are Technological Fluency, Applied epistemological anthropology, immersive environments, critical inquiry, long-term projects and Emergent Design.

The idea was to allow children to be immersed in long period projects, so they can handle fluent technological language. With that, the students will start looking with criticism the new understood world, and using the epistemological anthropology the teacher may be able to detect the learning forces of the students freedom and design "on-the-fly" the next learning framework to explode the possibilities.

All this is handled using the emergent design approach. The learner focus on building new knowledge upon the existing knowledge, and the tools and guides are given to facilitate that. Thus, there is no preexisting path, but one that is built as it goes on. It is pure Discovering by Construction.

Now, that is a learning experience Cavallo says it is not the only one possible. It was mapped to software development by Kent Beck, and it is presented as an alternative to blueprints (that is, the dreaded BDUP).
Emergent design is built on top of a Make-Verify-Improve life cycle. Since the new world is not created yet, the developers usually give baby steps, one step at a time. Decisions are not taken at earlier stages, but a just-in-time approach is followed, and developers are the one making those decisions.

These can prove good points:

• Avoids Prediction. Decisions are taken upon knowledge acquired by constructing, when the developers know that it works, and at the time it is needed.
• Verifiable products. The created products are real, working, and thus they can be validated against the requirements. New development is done on top of this real thing and not on top of paper ideas.
• Decisions are backed up by information obtained from feedback of real products and not assumptions.

Still, there are a couple of bad points to mention:

• Refactoring vrs Redesign. Note these are two different things. Refactoring is about improving the code after it works, redesign includes changing what it is done to use another approach or structure simply because the first one does not work. So, emerging design may not be about creating and then improving, but creating and then recreating.
• Late decision at Macro level. The problem with too late decisions are that the ones that affect a level higher that code may require much more amount of rework, recreating functionality in another way. Remember, refactoring is work to improve, rework is work to make it work as it should.
• There is certainly more information (a developer immersed knows more about his local environment than a designer), but there is less higher view to make the correct decision. That is, the grass-level view Cavallo explains work for individuals creating a single knowledge, since that knowledge is ok to be incomplete (there are lots of data the learner will not know). When you have individuals working together, you need a second level view to understand how all the individuals are doing matches together.
• The validation is locally centered. When individuals validate their decisions taken upon the current local value, the isolated solution may work. When integrated, the correct parts may not add up to an integral sound structure.
• It is assumed the individual will make the correct decisions based on information, which requires a long time to acquire (Cavallo’s long process). Thus, initial development is a challenge since no individual has enough info to make certain decisions.

So, those and other pitfalls can be avoided by taking care of tactical and strategic decisions:

• Use guidelines, like principles, to driven the decisions in case of doubt.
• Create from the bones. That is, create on top of a secured and sound base that explains by itself the rationale of the solution. That may require to bring some critical decisions Up Front, always knowing those decision may be changed in the future.
• All decision has to have a rationale that supports it. The idea is that later on, when the decision proves to be wrong, the rationale may help to chose another idea.
• Multilevel Coding. I know this is something not much people understand, but actually defining the global structure, then defining each component using a tactical structure to bind the bones, and finally writing the code to add meat to them, is what I call coding at levels, since every description of the solution is code. This helps a lot to visualize when and how a decision of any level can be taken or improved.

Hope this helps to clarify a myth about Emergent Design: It is not an easy two step methodology of blindly doing and then step back to see what emerged from the disconnected decisions. And, it may not be good for all projects nor for all people. Lastly, it is not an alternative to architecture, but just another technique to construct the architecture itself.

William Martinez

About the NOOB definition– Part 2: Globalization.

Prior the Internet days (some people talk about prior television), we had different villages, local ones, with no communication. Now, we live in a global village. We need to communicate and share knowledge, even in different languages and cultures. Furthermore, we learned it is not just us and the "my limited world", but any thing we do affects the globality.

Now, when working on a real world problem, working to find a solution of course, we need to communicate and all or our work is to complement the one from others. There is no one single person that fights all the villains and the rest of the team observes and cheers.

Solving a problem with a software intensive system, involves working with all parts of the system: Hardware, Software, people and processes. No one lives alone with its computer, everybody interacts with all the other components of the system, and the developers are part of that system too!.

Making sense of that, the strategy of working only in my local line forgetting there is something beyond that, goes back to the local world and denies globality. Does it mean you need to work all at the same time? No. It means you work in your local line knowing there is something bigger of which that line is an important part.
What does this matter in Steve Yegge’s post about NOOBs? Well, going extreme, the post indicates there is much waste, fat we need to remove to be healthy. The comments, even the modeling and describing language structures are needless for the seasoned, non-noob programmer. I agree, as long as the programmer is working in a system that has only two components: the programmer and his lines of code.

Unfortunately, that is not the reality. A system not only requires the work of many other components, some non-software and some non-programmers, but also requires all those components to communicate at design and execution time. Robert Martin once said that one of the software functions is actually communicate with people, readers that may have not participated in the development. Does that mean the comments should stay? Not exactly, but that the code itself should be readable, understandable.

One way of doing that, for the development group, is using sentences that make sense and do the function (you can scramble the sentences and do the same thing but being not readable).

Globalization in the System means all components will need to communicate and work with other components. Creating the product with those characteristics, because they are needed, is not being NOOB, but being aware of the fact the software is not an island.

William Martinez.