Distributed SOA

Nice article on distributed SOA

It's hard to turn anywhere today without seeing something about
service-oriented architecture, or SOA, and a debate about the "right"
way to do it. That's not surprising, I guess, since every new
computing trend generates debate and every vendor tries to promote
their technology as the right technology – the right product – that
will allow customers to take the most advantage of a new approach.
It's a scramble as vendors try to aggressively reposition their
existing product suites to take advantage of customer interest in a
hot IT trend. It's unfortunate, though, because this behavior often
creates a lot of confusion and potential disillusionment, as promises
made often do not turn into promises kept and technology solutions
sold as appropriate for SOA may turn out not to be.

To set the right perspective on this, it's important to note that SOA
is, by definition, distributed. The purpose of a service is to
communicate remotely with another service, typically to share data.
The purpose of an SOA is to change the approach of IT from building
bespoke, monolithic applications to building applications that are
developed and integrated more and more using assets from a collection
of shared, reusable functionality, i.e. services.

A distributed SOA infrastructure represents the easiest way to deploy
and consume shared, reusable services, facilitating incremental
adoption (both economically and technically) and enable greater
deployment flexibility, adaptability and maintainability (e.g., single
services can be certified for update more easily than an entire
application) .

Unfortunately, centralized approaches to SOA infrastructure continue
to be developed and proposed. Vendors will go to great lengths to
convince the technology buying public that what they're offering is
already SOA compliant, always was, always will be and was truly
designed from the beginning to facilitate their customers' move to
SOA, no matter whether it was originally designed to be a JEE
application server or EAI system.

In other words, vendors taking an opposing view to distributed SOA
infrastructure often do so because that's the nature of the software
infrastructure they already have. A refried EAI hub or JEE-based stack
or any other solution that requires request messages to be passed
through a central control point, cannot be considered truly
distributed since all access to services must be routed through a
central hub or a server. This centralized approach to SOA adds cost,
limits reuse, reduces flexibility and introduces a potentially
expensive bottleneck. In the worst case it could even negate the
reasons for moving to SOA in the first place. People are bound to be
disappointed if the flexibility of their SOA infrastructure does not
meet their requirements.

One only has to look to the World Wide Web to see an example of a
distributed application that very successfully meets its users'
requirements. The Web is the largest distributed application ever
built and it's distributed by nature, like an SOA should be. When you
use a browser to click on a link to a URL, your request is not routed
through some kind of central controlling authority deployed in a
server or a hub. Your request goes directly from your browser to the
Web server hosting the page you have requested. This approach works
fine for the Web and it also works fine for an enterprise's SOA. Web
endpoints can be updated individually without breaking clients,
affecting other sites or requiring any update to a central hub or
server, since requests do not have to pass through one in the first
place. A good SOA infrastructure also supports these capabilities.

Fortunately, an infrastructure solution exists that embraces the
distributed nature of SOA. The distributed approach to SOA
infrastructure uses smart endpoints that service enable applications
and allow them to find and directly communicate with other services.
Enterprise qualities of service, such as high availability or advanced
security, can also be included in the endpoints to preserve the
capabilities upon which existing mission critical applications rely.
Distributed SOA infrastructure is about creating an IT environment
that is platform neutral, standards-based and highly flexible, so that
it can respond better to an ever-changing technology and business
landscape. A distributed SOA environment is therefore better able to
support the technical and economic requirements of an SOA based
application. Finally, a distributed approach to SOA infrastructure
allows you to move at your own pace, deploying services one or two at
a time, adding features such as orchestration, registry/repository ,
management and so on as needed and not before.

I'm not saying that EAI systems, hub and spoke based applications or
JEE server centric approaches to SOA infrastructure are all bad or
wrong. Many times existing corporate application functionality depends
upon one or more of these implementation styles. All I'm saying is
that a good SOA infrastructure shouldn't constrain your design options
to what any one of these things can do – in fact a good SOA
infrastructure embraces and includes them among the collection of
reusable service assets.

A parallel between the benefits of distributed SOA and the airline
industry can be seen in the way in which the low-cost operators are
challenging the established carriers. The approach of the established
operators is based on an expensive hub and spoke model that funnels
passengers through a small number of dedicated travel hubs. Large
planes that cost more to operate, fly from spoke airport to hub
airport, where passengers are processed for further travel to their
final destinations. In this model the planes cost more to operate and
airport facility charges are higher. With the rise of low-cost
airlines, which operate on a more distributed, point-to-point model
(smaller planes directly flying to smaller airports), the airlines
that are tied to the traditional hub model are taking a significant
financial hit.

SOA customers do not need more of the same old bloated and expensive
software stacks. Customers need better software specifically designed
for the requirements represented by the SOA trend – to improve the way
in which existing (and new) IT functional assets are provide to
applications. SOA designs need a good way to create and deploy
reusable services that can be called upon simply and directly when and
where needed. Customers need low cost options that allow them to start
small with incremental adoption, using point-to-point communication
solutions that avoid expensive new servers and hubs, adding quality of
service and other features as required. In short, they need SOA
infrastructure that really meets the inherently distributed nature of
an SOA.

You can read the above article here