[SATLUG] SOA Meets The Cloud

Robert Pearson e2eiod at gmail.com
Sat Jun 19 06:43:44 CDT 2010

A couple of blogs I like to read are---
(1) "David Linthicum's - Where SOA Meets Cloud"
David has been around since MOM (Message Oriented Middleware) and
helped develop EAI (Enterprise Application Integration) as an
improvement to MOM.
I still own all his books. Very good but EAI never caught on.
[A Brief Bit of History]
EAI (enterprise application integration) is what it sounds like;
application integration. EAI emerged from MOM (message oriented middle
ware) offerings, which provided messaging between applications. EAI
vendors have built a toolset on top of MOM’s that facilitate matching,
sequencing, transformation within a user friendly interface.

Enterprise Application Integration vendors have gone through some hard
times due to slow adoption of application integration standards. The
lack of integration standards forced EAI vendors to build and maintain
expensive proprietary application connectors. Although said connectors
were/are a source of income, their maintenance causes significant user
administration hardship.

With the advent of XML, J2EE, and .Net, application providers are
beginning to build their suites with native standard based
connectivity. This means that EAI vendors will no longer need to
develop proprietary connectors for every application they integrate
with, and can concentrate on increasing tool functionality that makes
application interconnectivity easier. Admittedly, EAI vendors provide
a valuable service to the IT industry in the area of application
integration, but are just beginning to realize their dependency on
human interacting workflow. This oversight has opened up a tremendous
opportunity for competitors providing more holistic EAI-Workflow combo
solutions. EAI vendors have realized their oversight and are
scrambling to converge on what many call BPM (business process
management), which is the marriage of EAI and Workflow mentioned

(2) "Service Oriented - Joe McKendrick"
Joe's blog caught my eye when he gleefully proclaimed the death of
SOA. Now he writes a great deal about SOA.
SOA got caught in the time warp between SOAP and REST. When SOA was
designed SOAP was the only reasonable way to implement it.

"REST vs. SOAP – The Right WebService - Monday, August 24th, 2009"
[Article excerpt]
Web Services are the key point of Integration for different
applications belonging to different Platforms, Languages, systems. It
wouldn’t be wrong if you call Web-services as the “Rendezvous point of
the Business”.
I’ve been using HTTP and SOAP since several years new. REST is rather
new. SOAP revolutionized RPC and loose coupling  beyond the
restrictions posed by  earlier protocols. However off late I have been
giving APIs and interfaces considerable thought and am leaning a lot
more towards simple HTTP based APIs with an XML or JSON response
format as opposed to SOAP. Let’s try to discuss all the aspects one by
Before we start, Let’s do a basic terminology headsup -
SOAP refers to Simple Object Access Protocol
HTTP based APIs refer to APIs that are exposed as one or more HTTP
URIs and typical responses are in XML / JSON. Response schemas are
custom per object
REST on the other hand adds an element of using standrdized URIs, and
also giving importance to the HTTP verb used (ie GET / POST / PUT etc)
Although, in alst ffew years we saw growth of large no.  of Web
Services, despite that the hype surrounding the SOAP has barely
reduced. Internet architects have come up with a surprisingly good
argument for pushing SOAP aside: there’s a better method for building
Web services in the form of Representational State Transfer (REST).
REST is more of an old philosophy than a new technology. But a
realization that came later in technology. Whereas SOAP looks to
jump-start the next phase of Internet development with a host of new
specifications, the REST philosophy espouses that the existing
principles and protocols of the Web are enough to create robust Web
services. This means that developers who understand HTTP and XML can
start building Web services right away, without needing any toolkits
beyond what they normally use for Internet application development.

More information about the SATLUG mailing list