FranckenSOA

I wanted to brand this new type of SOA: FranckenSOA.

FranckenSOA is an integration effort where Services adopt a business model which is built by extending elements from the model of multiple service Consumers.


Imagine a ESB which offers an enterprise-wide Service, call it PippoService, to offer a virtualization of your ERP System.

PippoService can we invoked by a multiplicity of Services, belonging to disparate domains of the Enterprise.

This ESB serves a multiplicity of Systems, each with their System-dependent interface.

The question is: which language will PippoService speak?

This calls for the adoption of a Canonical Data Model, an enterprise-wide Data Model abstracting from the individual System, and speaking an Universal Esperanto.

Experiments on the adoption of the Esperanto show us that, apart from a small community of geeks, nobody ever uses it. Simply because it's not natively spoken anywhere, it's not backed up by any Political-Economical-Military superpower, and doesn't have a big corpse of literature like Latin has.

It takes a lot of time to build an Esperanto Domain Model, time to maintain, time to map it to all the external systems.

It's a lot simpler to adopt one of these 2 approaches:

a) Global Dictatorship: instead of Esperanto, the ESB and the services that it offers speak the language of the most important System (today it would be English). Each System has to develop an adapter to turn their Language into the English

b) Local Geopolitical Powers: in some areas of the ESB, people build a local Lingua Franca that serves their purpose, maybe shared amongst akin Systems, and the Most Dominant Systems determine the language spoken by their own facades.


(more to elaborate...)

Asynchronous vs Request-Reply vs One Way

Definition of Asynchronous:

http://www.w3.org/TR/xmlp-scenarios/#DS17

"A sender sends a message asynchronously to a receiver expecting some response at a later time. The sender tags the request with an identifier allowing the response to be correlated with the originating request. The sender may also tag the message with an identifier for another service (other than the originating sender) which will be the recipient of the response. "


Definition of Fire and Forget (aka One Way Message, Request-Only)


http://www.w3.org/TR/xmlp-scenarios/#S1

"A sender wishes to send an unacknowledged message to a single receiver"

Under certain interpretations, the Fire and Forget is a subcase of Asynchronous - without callback.


Definition of Request-Reply

http://www.w3.org/TR/xmlp-scenarios/#S3

Unlike popular belief, Request-Reply doesn't necessarily means the reply is sent back in the same thread. One can have a Asynchronous Request-Reply scenario.

sCrawler, dependency analysis for SOA composites

http://www.oracle.com/technetwork/articles/scrawler-sandeep-phukan-085368.html


http://code.google.com/p/scrawler/


What Sandeep achieved is simply amazing.

Whoever has been working in SOA projects maintenance knows how essential is to have an overall map of the system, showing dependencies and message flows.

My understanding is that products like Amberpoint are aimed more or less at the same target.
Yet I would like to praise a man who singlehandedly managed to do the same.

SOA 100 Questions

http://www.amazon.com/100-SOA-Questions-Asked-Answered/dp/0137080204

On the whole I found this book more useful for managers/ivory_tower_architects than for developers. The amount of repetitions of well known concepts is disturbing, for instance the word "Flexibility" is repeated 116 times in 267 pages; "Reuse" 178 times, "Integration" 166 times, "infrastructure" 266 times...governance 317 times, SOA 1678 times!!!!

Things to retain:
a Service should be: Stateless, Discoverable, Self-describing, Composable, Loosely coupled, Governed by policy, Independent location language and protocol, Coarse-grained, possibly Asynchronous



OSIMM : http://en.wikipedia.org/wiki/OSIMM offers a benchmark to evaluate the SOA Maturity Level of your company.

Read the famous IBM article on SIMM.

This article on SOA is also worth reading.

SOA: the hype is gradually declining

Google Trends is quite explicit: the top of teh searches for "SOA" was 3 years ago...


But a new ghost is wandering across ITLand: the ghost of Cloud Computing:

Bottom-up, top-down, meet-in-the-middle...

nice article on WSDL design - it makes sense and it's practical...

http://www.ibm.com/developerworks/architecture/library/ar-servdsgn1/

SOA stuff to keep you warm in winter

especially if you shove them in the stove :o)

A general overview here:
http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29


Plenty of patterns available here:
http://www.soapatterns.org/


Plenty of podcasts here:
http://itunes.apple.com/podcast/onsoa/id278745478

And the usual book to read before you go to bed:

http://www.amazon.com/Design-Patterns-Prentice-Service-Oriented-Computing/dp/0136135161

I am reading the Thomas Erl book, I am not overly impressed, I think the same things could be said in much less and simpler words.

SOA by the book

Udi Dahan gives a great presentation on common errors of "SOA by the book":

http://www.infoq.com/presentations/SOA-Business-Autonomous-Components

I have taken some notes here:

some skepticism about the term SOA.... "Oriented" means nothing, "Architecture" nobody really agrees on what it means.... only "Service" is left!

Loose Coupling : ok for LC design time, but what about LC Runtime ?

The Tables of the Law:
Services are autonomous
Boundaries are explicit
Share Contract and Schema, not Class and Type
Compatibility is based on Policy

see http://en.wikipedia.org/wiki/Service-orientation

You can end up with extremely complex architectures "everything is a service!" .
Layers on Layers on Layers.
It looks good on PowerPoint, but Hell on Earth.
A simple interaction can trigger zillion of services calling each other.

The entire this is NOT Agile. Any change entails LOTS of changes everywhere.

And if you end up a CYCLE, a service being called twice in an interaction, you are screwed!

Asynchronous invocation only DOUBLE the number of threads blocked.

The longer the interactions last, the more you can have GC problems -> OOM
Long running Transactions generate deadlocks.

Publish Subscribe can alleviate the crazy interdependencies: each service gets a Event notification of the change in other data. No need to ask the price, we are told every time it changes.

SOA is coupled with EDA: Services are coupled with Events.

.... continues ....

Five things to avoid in SOA....

Funny speech and politically incorrect...
Here is his blog http://www.infoworld.com/blogs/dave-linthicum


VDA= Vendor Driven Architecture

Rabbit Consulting.... you bring in a couple of guys from a consulting company, then 2 more show up, then 4, then 6...

Architecture is not something to BUY, it's something to BUILD, there is no magic bullet... it takes a lot of hard work.