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.

Agile taste for working code over documentation may be misleading to some. As seen in many posts and discussions, it seems that it means no documentation at all for some people. For another group, it means you just need to start coding, nothing else matters. This post is to differentiate plain coding from development, and to explain that working code is more that just executable sentences.

Let’s start by saying that code is the description of a solution in some sort of language. I defend the position that the description of a solution may not be executable. That description is to be read sometimes by the machine, some others by humans, and some others by both. The description has to have an abstraction level. That is, based on the approach we use to describe and to whom, it may be machine language (assembler for instance) or a high level code like a DSL. And we don’t just write ones and zeros because we will need later to revisit that code, and be able to read it and to make changes. Bear with that in mind for later.

Development is not just coding. It involves finding the why in the business needs and decisions, deciding the how we will solve that, actually describe the solution (to stakeholders and to the executers), and verify that solution meets the needs.

One point to clarify here is the executers concept. A solution is not a chunk of code. A solution may be a complex system, that is software intensive. That means it is not just code, it usually contains processes, people, and many other elements. All together are the solution. And that system is to be built in development, not just the code part.

There are several other tasks that should be performed during the development process. As we deal with humans, you need to have people management. A group has always issues, problems, questions. Also, humans need material to work with. Meetings, information, computers, and many other assets. During the development, several decisions should be made, and not just about code: deliverables, QA scheduling, assignments, feature modifications, priorities, etc.

People needs to communicate. Creation of communications channels, management of those, coordination, moderation, etc. Some voices say all that work should be done by developers themselves. Not so sure about that. Some other say that is not needed, we just need code writers to write code. Not sure that works either.

So, so far, I believe development is far more a complex process that just writing code. And coding is far more complex that just writing an executable set of instructions for a machine (Description of a solution, remember?) Thus, I proclaim that coding is not the same as developing. Let’s continue.

Going back to the coding definition. Some people think that a non executable code is waste. Specifically, design is seen as useless documentation, wasted time. Here then I start to defend what we may call design.

Non executable code is that one that describes de solution, but may not be read be a machine and may not be executed by it. As we mentioned before, the executer may not be a machine, but let’s assume the executable code is executed by a machine not to mess with concepts. Some of that code is the one generated as strategic and tactical description, aka, architectural description and design. If it is not executable, why do we need that kind of code? There are several reasons:
- The ones to design are the developers, why? Because it is a description of the solution, and thus code.
- Executable code is often done quicker when the ideas and major decisions are already made in the design.
- When code is done, it is usually reviewed and almost always changed to improve it. Describing at design level is quicker than writing low level code, and thus fixes and improvements can be made earlier, saving time and effort (changing executable code, large portions of it, may have a great cost and impact).
- Once done, the executable code should be verified. Checking against a high level description helps to verify. If it is different, then it means either the decision at high level or at low level need a review. It is important that both descriptions are kept in synch.
- Why doing the work twice? Because they are different works. Description at high level is used at some time, and the low level description later. But both are used. Missing one means there is something in development that may have more cost later. See next point.
- Development is never finished with complete code delivery. There are always enhancements, additions, changes. To decide why, how and what, it is always important to know what is done, how and why. Reading machine code means almost impossible changes. Reading executable code is possible, but at high cost. Reading a high level description, that was kept in synch, is great.
- Design is not a documentation process, it is a description process that should be used through the development. If design outcome is not used, the it is waste. Design that is done trying to be complete before operational coding, it will also be a waste of time. Design should be made in regular chunks, not to little ones that misses the tactical view, not so big so that you end up making decisions with not enough information.

So, given the ideas above, I want to proclaim that used design is actually working code, and thus, if well done, complies with Agile thinking.

First of all, let’s clarify a couple of things.

1. This post is not intended to list “bad ways” of thinking about REST, but to list the actual way people really think about it. Some of them are perfectly correct per REST constrains.

2. From articles, presentations, discussions and the like, I extracted commons ways of thinking, and tried to categorize them. So, this is a totally subjective classification.

So, let’s start.
People know about REST. Many are trying to get into the REST world for the first time, some other have more flight hours, still not so many had read Roy’s dissertation. Even more, some of the ones that actually read the dissertation, may think about REST in different ways.

Usually, when in a discussion, the same concept may be understood differently by the participants, which yields in non-useful conclusions. This may be actually true about REST. That is why I composed the following list of “ways people understand REST”. The list may help the reader to find out where he stands in understanding REST, and how may other people understand it. Also, it may show how some people is using REST.

First, an cautionary word: the names I use are not intended to make fun of people, but to be easy to remember.

The list is divided into three major groups: The API makers, the Mappers and the Fad Followers. This last one may seem a bad one, but it is actually a normal one, trust me many people fall in it.
Then, each group contains categories. Those categories may be present in more than one group, since the characteristics may fit both groups. Finally, people may fit in more than one category, since the work is complex in the world of REST to reduced to just one characteristic.

Here is the list.

Major Groups 1: API Makers.
People in this group I find them everywhere. Most of the time they have a system, usually not built thinking on REST at first (REST as an afterthought), and they want an API created to access that system. They usually think about REST like an API making technique or recipe, for the web.

Categories:
- URI Jugglers. These are the ones that think REST is all about creating URIs, and nothing more. So their discussions are solely focused on URIs, and their presentations are about URIs definitions. One way of spotting this category is when the application API is documented as a URI construction process using templates

- RPCers. This group think REST is a way to map RPC in disguise using URIs in a web API. The most of them don't know they speak RPC at all. Easily spotted when you see the API defined as a set of calls using a URI construction. Most typical is a URI format that includes the actual method name or action, followed by several parameters. There are many of them coming from SOAP based web services (the RPC kind), that made the change believing is easier to define the RPC call in a simple URI than using the complex SOAP envelope.

- Exposers: This type is repeated below. Those are the guys that think you need to expose things in REST using resources. So REST is an API for exposing things on the web. They usually look for objects or domain entities, but mostly processes or methods, and expose them using a URI formatted call. The slight difference with the RPCers, is that the exposers may not use RPC, but still expose the processes and entities through an API.

- CRUDers: Another repeated group. They think REST is a web API for CRUD. The similarities of the HTTP operations and the CRUD ones, plus the reference of resources as Data elements, support this way of viewing REST.

Second Group: Mappers.
This other group may use the API idea, but they actually think REST is a way of representing things and thus the work to be done is to map everything using that new way. Interesting?

Categories:
- CRUDers. Again, the idea is that CRUD operations can be mapped naturally to HTTP operations, and that makes it RESTful.

- HTTPers. They believe REST is HTTP. Deep enough. This category is hard to spot, since many people talking about REST implementation may talk much about HTTP, but think REST is far more than just the protocol.

- Exposers. Again too. They usually try to map all classes, data entities, elements into resources, and then call their systems RESTful. This category includes people that take into account REST constrains, and also people that just maps the domain to resources.

Third Group: FAD followers.
This is a group that is identified by themselves. That is, they expose what they think explicitly. Usually, they tend to follow a lead or the current business idea.

Categories.
- Standard Haters: Here you have all those that think Standards are evil and that REST is an anarchy where you have the freedom to do whatever you like, so they follow REST doing whatever they want.

- KISS lovers. These are the ones that like things to be simple. And someone told them REST is easy, so they follow doing easy things with URIs. There are lots of URI jugglers in this group. People here may not follow all REST constrains when they get complex enough. The idea is to keep the API or system with not much complexity.

- Servicers. They think Services is good, and someone told them REST is a way to do services without SOAP. So they follow. There are several RESTFull service creation techniques. Many RPCers in this category too.

- BuzzWorders. This is a vast majority. They like buzz words, so they follow REST just because it is cool and all people talk about it.

Is there some one I'm missing? Well, yes, probably the group that knows REST as it actually is and understands it. That may be a one person group (yes Roy).

What do you think? Do you find yourself in any of those groups? Which other category may you add?

Yep, my own. Although it may have some shared ideas, this is not a group agreement, nor the savior of what is now known as SOA (which is what is being done so far), nor something made for others to follow. It is just what I believe, what I follow, and what I teach each time I can.

So, here it is.

SOA MANIFESTO

1. Commons.
a. SOA is an acronym composed of the words Service Oriented Architecture, which relates to an architectural style that is based on the rules of the service metaphor.
b. A Metaphor is an application of the figure of speech concept to the IT design discipline. Using metaphors in architectural design actually refers to observing the rules of behavior of a particular entity in the business domain, and mimic them with an architectural element.
c. A Service is conceived as a cohesive (and coherent) business functionality, technologically neutral, offered through a uniform interface. A Service is a plain, homonymous metaphor of a business service.
d. For an architecture, Orientation describes the guidelines, principles and decisions that are based on the rules that govern the metaphor behavior.
e. The Architecture refers to an actual style that defines the architectural constrains, suitability and consequences of using it.

From (a) to (e) :

SOA is an architectural style whose components, constrains and principles
are driven by the service metaphor.

2. Delta
By definition, and in contra-position from some usual implementation, SOA IS NOT:
a. An Indirection Layer for interoperability.
b. A Decoration Wrap for legacy code accessibility.
c. A Component from a whole that represents one architecture instance
d. A Service Group or container of services
e. A Business Process Container.
f. A Modernization Agent
g. An Object Distribution Technology
h. An Antagonist of REST
i. A ROI salvation
j. A Way of Life, A Philosophy of Doing or a Trend (It is an architecture style!)

Corollary of (j): SOA cannot be killed, it cannot just die.
It can be suitable for a problem or not.

By definition, and in contra-position from some usual implementation, Services ARE NOT:
a. Necessarily Web Services as defined in the WSA.
b. Ways to implement RPC nor RMI.
c. Exposed Methods or Objects.
d. Defined by the process they execute
e. Necessarily Stateless (YES, they should not necessarily be Stateless).

3. Principles.
Whenever there is the opportunity when working with SOA, people should
a. Favor Business Value exposed in the business domain OVER Business Value exposed with IT domain.
b. Favor Composability OVER Integration through Interoperability, AND favor Integration through Interoperability INSTEAD of Distribution.
c. Favor Metaphor rules INSTEAD of Tool rules
d. Favor Pure Document Style INSTEAD of RPC/RMI style. (NO WRAP TRICKS ALLOWED)
e. Favor Messaging OVER Other communication options.
f. Favor Business needs OVER specific IT practices (like optimization or flexibility)
g. Favor Entity documents OVER commanding documents
h. Favor Versionable documents OVER Structurally static documents.

So it is written.

William Martinez Pomares

In a recent discussion at InfoQ about the news of the upcoming SOA Manifesto, I had discussion with great people, including Jean-Jacques Dubray and Steve Ross-Talbot both renowned guys in the SOA world. We all talk the same, maybe at different levels or on different realms. Still, I promised Steve to put my two cents about SOA. Well, here I have a couple of ideas about it, too high level, but trying to clarify at least the three words that conform the acronym.

Well, here they go.

1. Many people talk about SOA and Services, but I’ve found in presentations, articles, case studies, working with tools vendors and looking at real implementations, that not everyone understands the concepts quite right. So, I have a couple of posts (here, and here) and a short video in the Architecture Journal (SOA Myths), explaining the types of perceptions people have about the concepts, and why I think they are wrong. I assure you it is a good list, interesting to read. So, that would be my first contribution.
2. Now, let’s check on the Service concept. As I mention in the posts, to me a service is a cohesive (and coherent) business functionality offered through a uniform interface. And it is technologically neutral. What does that mean? Well, a service is a plain, homonymous metaphor of a business service, just like the loan service in a bank, or a delivery service of you mail office. As a metaphor, it is driven by the rules of common services, with contracts, processes, protocols, controls and evolutions. Its actual implementation may be whatever, but it should not surface the definition, meaning users of a service do not have to know how the service was implemented to use it, and should not have to learn anything else apart from the rules and protocols of regular business services interactions.
3. Now, Orientation. For an architecture, orientation describes the guidelines, principles and decisions that are based on the rules that govern the metaphor behavior. That is, the service one.
4. Architecture refers to an actual style that defines the architectural constrains, suitability and consequences of using it.
5. So, SOA is an architectural styles whose components, constrains and principles are driven by the service metaphor.
6. Service implementation is out of scope. Service metaphor implies business domain. The implementation domain should not surface into the business view, not affect the rules of the metaphor. This is something almost all of implementation fails to accomplish: to use a service you usually must know implementation details, and those are the ones that actually avoid flexibility and change.
7. The service contract requires a semantic agreement (standard shared business semantics are a must), functional specification, pre and post conditions and the description of side effects. All that is technologically neutral.
8. Lastly, and just for the records: to me, reuse is not a business concept, but an IT one. So, Services should not have as a goal the reusable property. In business, the property is composability. The key is to be able to create higher-level services from composing lower level ones. Reuse is a side effect, and should not be the base for ROI, because it will never make it!

Hope this is clear.

William Martinez Pomares

When creating a solution, much of thinking goes into the creation of functional chunks, database tables and generation of reports. Basically, the definition is made part by parts, and then it is all glued together.

Now, how do you glue it? At architectural level, it is important (and often overlooked) to define a flow strategy. What is that? Well, all the functional elements will have to execute at some time, and the execution may have at least start and one end. But before and after that what happens? How do you get to that start, and what do you after the end?

At one particular moment, the application may be doing several things, all coordinated. At the next moment some things will continue, other will stop and other will start. That “movement” is the flow, which is important. Think two applications with the exact same elements, but with different flows: they will behave differently, and even produce different things!

So, which flow strategies are there? Of course, your actual application does have one, maybe you don’t it yet but there it is, just like an undocumented architecture. Let’s review some of the strategies:

-> The Script. In this strategy, there is one script, like in the movies, where all is described: from the start, the time when one actor cries and the way another actor jumps out of the window. And there is a director, who is in charge of telling the actors what to do. Notice that the actors (architectural element, components, or even plain objects) know what to do and they do it, but the time when they must act, and the decision of who is next, is the director’s job. And this can be hierarchical, where one higher director will control other directors, which in turn control the actors.
Another important thing is the director may know all. That is, there is a continuum manager (the director or a helper). Meaning the state, persisted or not, is taken care of by the directional staff, and not by the actors.
This is perfect for concurrent processing, with highly pluggable and independent pieces of code.

-> The Production Line. If you center the flow on the processed entity, then you can have a production line. Here, the entity goes from one station to the next one, following one sequence (with forks in some parts and sub-roads). You recall the Pipes-and-filters here. The flow is actually very static, predefined. There are decision in the way too. The state in this case is managed by the actual entity, and in some cases you may need to avoid state at all.

-> Democratic Control (Chained, Distributed). This is a very common setting: the flow is in the actual executed code. That is, one piece of code not only executes its task, but also knows which other piece is called next. Of course, this means coupling and a bad separation of concerns. A change in the flow will require changes in the business code. Despite this, it is commonly used by developers (without much thinking in the strategy).
It may be use in very simple cases, with a very static flow, where the construction of a more complex flow strategy may not be worth it.

-> Workflow (or control container). Usually it uses orchestrators (I prefer to call them directors) in an engine, which will parse and interpret the flow. It seems similar to the Script, but here the engine is a generic orchestrator that executes a flow, instead of a functional element programmed with the flow itself. It is more flexible as a change to the flow may require simple adjusting the flow definition. The engine will not suffer modifications.
This is the regular workflow solutions out there, like WFF and the tools using BPEL.
The problem with this is that you require a control container, an engine to execute the flow.

-> Reactive (Event Driven). The other strategy is similar to the democratic control, as the control is associated to the functional pieces. Here, the pieces are no chained, and the control may be an aspect. Each piece is passive but listening to the environment, until something happens. Then, some pieces may decide to act, and perform something. That performance may be also detected by others, and so on. These are event driven systems, where there is an event engine and the pieces are the ones that act upon messages or events. Note the control here is in the pieces, not the engine.

So, now: which flow strategy do you use?

From many talks, blogs, case studies and reviews, I have collected a list of conceptions of what people think SOA is.

Yes, Service Oriented Architecture may mean different things for different people. I’m not talking about definitions, since those are more academic-theoretical things. Conceptions are more like the practical being of the concept.

Most conceptions differences are subtle, but enough to be important.

Let’s star by saying I conceptualize a SOA (yes, an instance of a SOA) as an architecture whose elements, in majority, represent (or are) services. SOA is an architectural style.

That said, here is the list:

SOA as an Acronym. Yes, SOA is just a name created by composing the first letter from Service Oriented Architecture. Thus, SOA is taken as yet another acronym that may be compared to other named technologies. Just another one of the bunch.

Academic SOA. In trying to explain the concept, many academics find several similarities with other concepts they had known from long time ago. Are they simple exposed objects? Are services similar to Complex Systems? What is the difference between a Service and an Intelligent Agent? Of course, there are differences. Services were never meant to be exposed objects or components (although implementation made that happen). Complex systems have evolution, self organization, chaos is involved and emergence (clearly, services are far much simpler). And of course, an agent is something that is not only autonomous, social (talk to other agents) and react and pro-act, but also have intelligence. Services do not.

SOA as an Indirection Layer. Now this one is more on the earth of implementations. SOA is seen just as a layer that receives commands or requests, and passes them down to the real working objects (that ones with the business rules). So, SOA is just a way to add indirection to the requests, encapsulating and hiding the actual how-to. Of course, this conception is wrong by a great deal. SOA is not a layer to begin with. Being an architecture, it should be an organization of elements, the majority of them representing services. As implementation, we may think of services as the layer before the actual implementation, but the service is really the complete thing: the service contract, interface and inner implementation.

SOA as a Wrap. This is very similar to the above. SOA is seen just as a decoration for already made business logic. Usually presented as a salvation for legacy code, SOA is depicted in the diagrams as a layer that wraps the old in-use code, and made it usable for the new generations. (Careful with that picture, it is not as easy to expose old functionality with new interfaces, old code may not be designed to handle new load or business flow). Of course, SOA cannot be a wrap. You can create a wrap that uses services, but then your architecture will have new elements on top, services in the middle and old code down below. That is a sandwich, not really an architecture oriented to services.

Pages: 1 · 2

This was the first day of OMG's technical meeting, here at Costa Rica.
I attended the Architecture-Driven Modernization (ADM) – Case Studies Information Day hosted by William Ulrich and Philip Newcomb.

First of all, William did a great introduction to ADM, that I can summarize as a process to update software system solutions (legacy ones) to newer (modern) languages and architectural best practices.

Now, the actual focus was about synching the business architecture to the IT (technical) architecture. This idea I had talked about in several other places: there is a trend to create IT solutions that require the business architecture to be adjusted to the IT decisions, and not all the way around. And they seem to move independently.

The presentation was good, but, based on the cases that were presented, the whole ideal was not actually implemented as it was described (maybe I missed something). Two cases were about translating the solution from ancient languages to new ones (Modernization of the EuroCAT Air Traffic Management System (EATMS) and Model-driven Reverse Engineering of Cobol-based applications). The other case was a different approach, using a SOA wrap of the legacy modules and building improvements upon it (SOA and BPM enabling an Agile Enterprise Architecture that, btw, didn't mention much of BPM).

So, my questions went around the ideal presentation of using architecture as a driven force to modernization, still the cases were more on language translation (so far no architecture look up). Also, the language translation was achieved using tools that were to automate the process. In this regard, I'm not sure about the capabilities of those tools to pass from a pure procedural language to an object oriented one (I know you can use Java for procedural programming, but to use it as OO requires modeling that cannot be automated). Still the answer Phil gave me was that I made an assertion, not a question, and that my assertion was wrong. I blame my english.

OMG has two standards, KDM (now an standard) and ASMT (in final stages). The first is to model knowledge, used to obtain a model of working solution. The other one is to model language, so I can pass from a written program into ASMT, do refactoring there (language agnostic) and then save using another language. That way I get language modernization (refactoring since there is no functional change). I think that is great.

Still, I was expecting more discussion about architectural visualization of legacy systems, architectural refactoring and evaluation of legacy solutions.

I will read a little bit more and write another post about that.

Will see tomorrow on the SOA and BPM day.\

William Martinez Pomares.

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.

Neal Ford from ThoughtWorks, recently wrote an article that is the first of a series related to architecturing and design called Evolutionary Architecture and Emergent Design. The first article is a revisit to the architecture and design concepts. In it, Neal describes the evolutionary architecture with these lines:

However, just because you can't allow architecture to emerge doesn't mean that it can't evolve. If you have created a flexible architecture and taken care not to create an irreversible decision, you can allow it to evolve over time as new concerns appear.

Let's talk about that idea...

Pages: 1 · 2 · 3

Hello!

Back from a long time. And that is because there is a new baby at home, our first!

Say hello to Juan Pablo, from now on part of my life.
Oh, Fatherhood... that is a great adventure...

William.

This is a quick post to notify all people out there that there seems to be a lot of people confused about the real meaning of the terms in the title. Let’s see:

Ajax is not a graphical technique. Surprised? Well, it never was. I see lots of Ajax frameworks out there providing graphical gadgets/components and people believe Ajax is just a way to mimic desktop look and feel in the browser.

Ajax was born to be a way of having asynchronous calls to the server, that is without the need of a page load for each new data fetch. That data was supposed to be done using XML (now Json is another option), and the call with HTTPRequest object. The data was helpful for lots of things, one of them loading combo boxes on the fly. Of course, the examples were done in UI to show the technique, and later on everybody was confused, thinking Ajax was just a way to make the UI experience richer.

Ah, and there we got Rich Internet Applications. These applications are real richer in user interactivity (think on Gmail). You can create those things using other tools, not necessarily Ajax techniques (yes, Ajax is not a tool nor a framework, but a technique). You can even (at an extreme) have RIA using Javascript and NO AJAX! A simple Flash site can be a RIA with no Ajax. And another Flash site may use Ajax (actionscript also counts) to make things richer.

Lastly, Web 2.0 is not Ajax, nor RIA! Web 2.0 is about people, the web working all the way around. Instead of the site owner posting and all the other mortals reading, web 2.0 says all the other may contribute to the site, create communities, build collective knowledge, be a part of the site! Now, to achieve this, sites can attract people using flashy pages, actual RIAs, and those may use Ajax to implement.

So, when someone says: “Here is the new tool for Web 2.0!” and you read later on it is a RIA tool, and later on that the tools allows to create rich pages using Ajax, you may note that someone does not know what is he talking about.

William Martinez Pomares

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

This 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 not for all people. Lastly, it not an alternative to architecture, but just another technique to construct the architecture itself.

William Martinez

Hello!
Back again after several months. Sorry, I have tons of posts to write, but also too much work and a baby is coming too! So, my wife has the same priority as before, on top of all, but now she has also more of my time.

Let's see if I can keep a better pace writing the ideas!

William

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.

During all these discussions, in this blog and other forums, I have found some semantic dissonance. This means some people use the same word and even the same concept, but actually understand different things from it.

So, words like architecture and design mean paper to some and process to others; they may be normal, unnecessary or even offensive. This is a little post that tries do define some of the words I use, just to be sure anybody that reads me understands what my meaning is.

Design: As a verb, is the process of decision making towards the creation of a solution. As a noun, it is the one word name of Design Description.

Design Description: The description of the decisions taken toward a solution and their rationale. It can be a document, image or even multimedia.

Code: Sentences, written in a particular language, that describe the solution. It can be at any level, and may (or not) be executable.

Strategic Design: Design that focus on architecturally significant issues, whose majority are global decisions described in an intensional way.

Tactical Design: Design that focus on tactical issues, whose majority are local decisions described in an intensional way.

Micro Design: Design that focus on operational issues, whose majority are local decisions described in an extensional way.

Domain: Is the set of concepts and relations that define a reality. It is not a description, since those concepts may be infinite or unbounded.

Abstraction: Is the result of abstracting: process of elimination of detail without loosing the essence of the concept being abstracted.

Model: Abstraction of a reality from an specific domain.

Modeling: Process of describing a possible reality in an abstraction level.

Architecture: System Structures, the externally visible properties and the relations between them. NOT PAPER.

System: Independent structure of components interrelated.

Software Intensive Systems. Systems where the majority of the components are software based ones.

Solution: Part or whole of a system that solves a problem from a domain.

Meta something: Meta means beyond, above of, self-referring. Using those concepts of the suffix, we may say meta-modeling is modeling models. Meta-data is data about the data. Meta-language is a language that allows us to describe languages. Meta-comments are comments about the comment. And so on.

Now some notes: from the above, we can say interesting things. For instance, modeling is not a paper generation process, but a description process. Modeling can be use to describe a solution, thus it can also be interpreted as coding. And code, it is not just writing executable lines (in fact, they are not executable, they need more work).

When time and other discussions require it, I will be posting more glossary terms.

William.

Paul pointed me to a TSS post I missed. Steve Yegge posted some rants about complexity and got to a conclusion about the how good and clean are scripting languages (Portrait of a NOOB ).

I couldn’t post a comment to it, since it was already closed to comments. So I guess I will answer here.

In this first part of a response to that blog, I will reproduce the post I did to TSS. Probably nobody read it since I posted it one month later.

First, let’s summarize Steve’s post (or what I understood of it):
1. Comments are metadata. Metadata is of no use for the compiler, so it can be get rid of.
2. Noobs are comment obsessed creatures, thus metadata enthusiastics.
3. Modeling is a way to comment intention of code in code language itself. So modeling a metadata creation process.
4. Teenagers are obsessive modelers.
5. Classes and in general OO, are metadata in code itself.
6. Static typing is also metadata since the real thing is memory afterwards.
7. Seasoned Programmer is one enlighten creature that does not use metadata, and thus can see the real thing when coding, not ethereal domain models.

What do I agree with:
Metadata is useless for the compiler. True.
Modeling is a metadata creation process. True.

What do I disagree with:
Metadata (at least not all) is not useless. Metadata is important, although not for the compiler.

Probably one of the things Steve Yegge misses in the post is that a language has much more than just telling the compiler what to do. In the DSL post, we talk about languages oriented to one specific domain, using vocabulary and grammar of that domain only. The idea is languages are there to help you solve a real life problem, not to help the compiler. Languages are for you (and your peers), not for the machine. And maybe not all languages are meant for a computer to read them.

Furthermore: Lack of metadata does not mean better code.

Pages: 1 · 2

Working with developers, I often found them thinking of design as a generic word to indicate "sketch the classes you are going to create".

Of course, I don't share that definition. I think of design as:

"composing the sentences, in a particular design language, that describe the solution of the problem"

That said, I add that there are several design levels and types. That is, you may find out you are designing when you think you are doing something else!

Amnon H Eden and Raymond Turner had some publications where you can read about a proposal for an ontology (using the Intention/Locality). Part of their definition is that the software design should be divided into three categories: Strategic, Tactical and Implementation.

Of course, Strategic design sentences are those for Architectural design, where decisions will impact the whole. Tactical sentences are what we have always call the design, where the focus is local to one part of the problem, and that is abstract enough to be variable. Then the Implementation are sentences that are local, but also the actual execution.

That last one I call Operational design. I also call it Micro Design. That design is the one the developer does when creating the sentences that define the executable solution. Note that the decisions here are also important. Note also there are design patterns to this level too, that are different depending on then selected language (those are called Idioms).

There is another point to this definition of design: We can describe a solution at different levels, and it will be the same solution. The good point here is that each level is an abstraction of the lower level, where details was taken out of the way to clearly see broader requirements. Not all designs can be executed, and not all levels may have all the required details to be able to execute as it should.

Funny, huh?

William Martinez

Hey!
Back after several months!
It is incredible the amount of work a change in your job position brings in its tail!

But for now, let's talk about the title.

I was recently reading a great blog from Michael Stal (which I'm adding to the interesting blog's section). The latest post is referring to Domain Specific Languages (DSL).

It is interesting, the list of examples of what can be considered a DSL. Being as attached to formality as I’m, my take is on the D and the L of the acronym.

First, it should be Domain driven. That means this “tool” will work inside a domain scope, referring to the elements that make sense inside that domain. If used as a communicator (as I will explain later) the reader may have knowledge in that domain. For instance, if you explain your solution to a manager in terms of resources, time and cost.

The second is the language constraint. That is, DSL is a language: a grammar and a vocabulary (plus maybe rules to expand that vocabulary). The language is used to describe things in sentences. Those things could be the problem or even the solution. That description can be read, understood and even executed.

I recall a very old issue of Dr. Dobbs that talked about mini-languages (or was it micro-languages?) that were script languages in essence. An example was the MS Excel macro language of that time. Specifically, the macro language had the typical constructions for conditions and loops, but the vocabulary was focused on cells, rows and columns, selections and texts, formulas and styles. The Domain was very explicit. It also mentioned another languages, some derived from C. those where subsets of the C language with some tweaks. Were those DSLs too?

Pages: 1 · 2

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.

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.

Pages: 1 · 2

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

Hi All!

Very excited that I’m writing my very first post in the blog.
And since this is an Architecturing 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