What is SOA?

[Dhurandhar]

I have been trying to read and understand what it means by SOA (Service
Oriented Architecture). Are there any definitive
guides/tutorials/references that I can refer to?

It will be better if the references avoid clutter and fluff and give
some tangible examples about why SOA matters.

I am especially interested in this because of a recent article:

http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1198211,00.html

Thanks,

 

[Oliver Wong]

I have been trying to read and understand what it means by SOA (Service
Oriented Architecture). Are there any definitive
guides/tutorials/references that I can refer to?

It will be better if the references avoid clutter and fluff and give
some tangible examples about why SOA matters.

I asked a similar question in an Eclipse newsgroup, and someone pointed
me to: http://www-306.ibm.com/software/rational/mda/papers.html

I haven't actually read all of the articles there yet, and I still don't
have a clear understanding of what SOA is exactly, but maybe this'll get you
started in the right direction.

- Oliver

 

[Oliver Wong]

I asked a similar question in an Eclipse newsgroup, and someone pointed
me to: http://www-306.ibm.com/software/rational/mda/papers.html

Oops, after actually re-checking the link, I noticed that it only deals
with MDA, and not SOA. Here was the original question I had asked on the
newsgroup:

<quote>
If I'm just a lowly Java programmer, and I'm hearing "SOA is the next
big thing, MDA is the next big thing, if you want to do MDA, you should use
EMF" and I want to find out more about what all these TLAs mean, is there a
document out there for me?
</quote>

So I guess the poster addressed the MDA part, but not the SOA part.
Sorry about that.

- Oliver

 

[Chris Smith]

Dhurandhar says...

I have been trying to read and understand what it means by SOA (Service
Oriented Architecture). Are there any definitive
guides/tutorials/references that I can refer to?

SOA is a marketing term. It has no meaning.

That being said, it generally refers to the applications that use web-
services, and generally SOAP in particular. The word "architecture" in
SOA generally implies that this use of web services is central to the
design, such as it being used for communication between major modules
that are both essential to the core function of the project. In
practice, I don't find that's the case of everything that calls itself
SOA.

 

[Patrick May]

I have been trying to read and understand what it means by SOA
(Service Oriented Architecture). Are there any definitive
guides/tutorials/references that I can refer to?

There is a very active Yahoo! Group that discusses SOA
(http://groups.yahoo.com/group/service-orientated-architecture/).
Disclaimer: It's run by a friend of mine.

Here's a quick summary I put together for a client:

"Service Oriented Architecture" (SOA) is a term that describes any
distributed, enterprise scale software system having a design with
four core characteristics:
- Functionality is exposed as a set of services.
- Services make themselves available by registering with a lookup
mechanism.
- Clients find services only via the lookup mechanism.
- Clients bind to services dynamically.

A service is a cohesive set of business functionality aggregated into
a single interface. That interface is implementated by one or more
software artifacts, which may be local or remote. Implementing an SOA
enables an enterprise to define the essential services it requires to
meet its core business needs efficiently, and to adapt rapidly to
changing business conditions.

The loose coupling inherent in SOAs results in resiliency
(self-healing), scalability, deployment flexibility, and increased
reuse. Loose coupling also makes it possible to incorporate existing
components with minimal intrusiveness to working systems. SOAs can mix
and match implementation technologies, using the options that are best
for each service (e.g. synchronous vs. asynchronous communication,
participation in distributed transactions, idempotency, etc.) without
impacting the decisions made for other services.

The technical benefits of SOAs, in turn, provide real business
benefits, including business agility, the ability to leverage existing
software investments, and support for Business Process Management
(BPM). These benefits come from the elimination of "silos" and the
increased availability of business functionality previously locked in
legacy systems.

Regards,

Patrick

PS: Some people will try to convince you that SOA is synonymous with
Web Services. This is usually because those people are trying to sell
you a Web Services product or Web Services consulting.

 

[Oliver Wong]

Oops, after actually re-checking the link, I noticed that it only deals
with MDA, and not SOA. Here was the original question I had asked on the
newsgroup:

Okay, after a bit of googling on my own, I found these:

http://en.wikipedia.org/wiki/Service-oriented_architecture
Wikipedia article on the topic.

http://java.sun.com/developer/technicalArticles/WebServices/soa3/
"Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK"
By Gopalan Suresh Raj, Binod P.G., Keith Babo, and Rick Palkovic, May 2006

It sounds like a fancy name for a pretty simple concept: A bunch of
computers communicating to each other over the Internet. More accurately,
you have a bunch of servers on the Internet, each providing some high-level
service. For example, Google offers the service of letting you search the
web. Amazon offers the service of letting you buy stuff. Previously, it was
mostly humans using this service, but there isn't any reason why you
couldn't write a bot to do the web surfing for you, and act as a consumer of
those services.

So it sounds like SOA basically a formalization of that idea. You've got
Google Maps, which provides a nice UI for map-related services, and exposes
a useful API for web developers. You've got eBay which lists auctions along
their approximate locations of the sellers. You've got FedEx which lists
estimated shipping costs and time from one location to another.

You could write a new service (in PHP, J2EE, RubyOnRaisl, or whatever
you want) which consumes those three services and provides a new one: An
local-availability auction-searching tool. Let's say I want to search for an
XBox360 near my city, Montreal Quebec. This new service will show a map
(using Google Mapses service), and put icons at each of the approximate
location of the sellers who could be in Canada, the United States, Great
Britan, Japan, Australia, etc. (using eBays service), and have arrows
flowing from those locations to my locations with estimate shipping charges
and time (using FedExs service). Maybe a little table on the left hand
corner so I can sort by ascending total cost (including shipping), or
ascending duration of shipping.

That's my understanding of it, anyway.

- Oliver

 

[Danno]

Okay, after a bit of googling on my own, I found these:

http://en.wikipedia.org/wiki/Service-oriented_architecture
Wikipedia article on the topic.

http://java.sun.com/developer/technicalArticles/WebServices/soa3/
"Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK"
By Gopalan Suresh Raj, Binod P.G., Keith Babo, and Rick Palkovic, May 2006

It sounds like a fancy name for a pretty simple concept: A bunch of
computers communicating to each other over the Internet. More accurately,
you have a bunch of servers on the Internet, each providing some high-level
service. For example, Google offers the service of letting you search the
web. Amazon offers the service of letting you buy stuff. Previously, it was
mostly humans using this service, but there isn't any reason why you
couldn't write a bot to do the web surfing for you, and act as a consumer of
those services.

So it sounds like SOA basically a formalization of that idea. You've got
Google Maps, which provides a nice UI for map-related services, and exposes
a useful API for web developers. You've got eBay which lists auctions along
their approximate locations of the sellers. You've got FedEx which lists
estimated shipping costs and time from one location to another.

You could write a new service (in PHP, J2EE, RubyOnRaisl, or whatever
you want) which consumes those three services and provides a new one: An
local-availability auction-searching tool. Let's say I want to search for an
XBox360 near my city, Montreal Quebec. This new service will show a map
(using Google Mapses service), and put icons at each of the approximate
location of the sellers who could be in Canada, the United States, Great
Britan, Japan, Australia, etc. (using eBays service), and have arrows
flowing from those locations to my locations with estimate shipping charges
and time (using FedExs service). Maybe a little table on the left hand
corner so I can sort by ascending total cost (including shipping), or
ascending duration of shipping.

That's my understanding of it, anyway.

- Oliver

Yep, and on top of that there are transaction specs so, you can
effectively make a roll back processes across multiple servers. There
are security specs, and on and on. One thing that has me perplexed
though is Monsol-Haeffel's (sp?) latest schtick about how SOA will
destroy Java EE. Java EE sounds great in developing SOA systems.

 

[David N. Welton]

A service is a cohesive set of business functionality aggregated into
a single interface. That interface is implementated by one or more
software artifacts, which may be local or remote. Implementing an SOA
enables an enterprise to define the essential services it requires to
meet its core business needs efficiently, and to adapt rapidly to
changing business conditions.

Yeah... did you get the memo about the TPS reports?

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

 

[John Gagon]

There is a very active Yahoo! Group that discusses SOA
(http://groups.yahoo.com/group/service-orientated-architecture/).
Disclaimer: It's run by a friend of mine.

Here's a quick summary I put together for a client:

"Service Oriented Architecture" (SOA) is a term that describes any
distributed, enterprise scale software system having a design with
four core characteristics:
- Functionality is exposed as a set of services.
- Services make themselves available by registering with a lookup
mechanism.
- Clients find services only via the lookup mechanism.
- Clients bind to services dynamically.

A service is a cohesive set of business functionality aggregated into
a single interface. That interface is implementated by one or more
software artifacts, which may be local or remote. Implementing an SOA
enables an enterprise to define the essential services it requires to
meet its core business needs efficiently, and to adapt rapidly to
changing business conditions.

The loose coupling inherent in SOAs results in resiliency
(self-healing), scalability, deployment flexibility, and increased
reuse. Loose coupling also makes it possible to incorporate existing
components with minimal intrusiveness to working systems. SOAs can mix
and match implementation technologies, using the options that are best
for each service (e.g. synchronous vs. asynchronous communication,
participation in distributed transactions, idempotency, etc.) without
impacting the decisions made for other services.

An example would be nice. Let's say we have a time of day service, a
current weather service and a stock quote service on a server of mine
and everyone loves it at Groupiesoft. How does loose coupling (I agree
it's inherent in a generic xml interface) result in resiliency (self
healing?). If it simply means failover that's been in J2EE since 1999
technically and earlier practically. What about the xml being a loosely
coupled interface have anything to do with whether that system is going
to alert or automatically do something to stay online or bring back
online? Is this implying a requirement that SOAP is also used to tell
other servers to reboot if they don't respond in time? Is there a
standard for that which is part of SOAP or associated web technology,
web service or "set of services with lookup" available somewhere that
is identifiable that we're not mentioning out of say, not trying to
drop a vendor name or something or does it just sound smart to the
listener in a kind of Sokal Affair kind of way?

 

[Danno]

http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf

found this diagram....very cool

 

[Chris Uppal]

http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf

found this diagram....very cool

Or, as I would prefer to call it, "horrifying".

-- chris

 

[Patrick May]

An example would be nice. Let's say we have a time of day service, a
current weather service and a stock quote service on a server of mine
and everyone loves it at Groupiesoft. How does loose coupling (I agree
it's inherent in a generic xml interface)

Before answering the question, I'd like to emphasize that XML is
not a requirement for an SOA.

result in resiliency (self healing?).

Self-healing arises from the dynamic register-find-bind
characteristics of an SOA. If an instance of a service becomes
unavailable for whatever reason, the clients of that service can
simply acquire a reference to another instance. Either manual or
automatic monitoring tools can bring up new instances as necessary.

If it simply means failover that's been in J2EE since 1999
technically and earlier practically. What about the xml being a loosely
coupled interface have anything to do with whether that system is going
to alert or automatically do something to stay online or bring back
online? Is this implying a requirement that SOAP is also used to tell
other servers to reboot if they don't respond in time?

SOAP is also not a requirement for an SOA. The SOAs I've
designed typically expose external interfaces used by business
partners, suppliers, and customers as Web Services but use Jini
(http://www.jini.org) internally.

Is there a standard for that which is part of SOAP or associated web
technology, web service or "set of services with lookup" available
somewhere that is identifiable that we're not mentioning out of say,
not trying to drop a vendor name or something or does it just sound
smart to the listener in a kind of Sokal Affair kind of way?

Just the opposite, in fact. SOA is basically a name given to a
set of practices that have, individually, been around for quite a
while. Pulling them together provides a useful, practical means of
better aligning IT with the business (yes, it sounds like marketing
speak, but it's true in this case). A number of vendors are
attempting to appropriate the term for their own products, which is
why it is important to emphasize the generic features.

Regards,

Patrick

 

[John Gagon]

Before answering the question, I'd like to emphasize that XML is
not a requirement for an SOA.


Self-healing arises from the dynamic register-find-bind
characteristics of an SOA. If an instance of a service becomes
unavailable for whatever reason, the clients of that service can
simply acquire a reference to another instance. Either manual or
automatic monitoring tools can bring up new instances as necessary.


SOAP is also not a requirement for an SOA. The SOAs I've
designed typically expose external interfaces used by business
partners, suppliers, and customers as Web Services but use Jini
(http://www.jini.org) internally.


Just the opposite, in fact. SOA is basically a name given to a
set of practices that have, individually, been around for quite a
while. Pulling them together provides a useful, practical means of
better aligning IT with the business (yes, it sounds like marketing
speak, but it's true in this case). A number of vendors are
attempting to appropriate the term for their own products, which is
why it is important to emphasize the generic features.

Yes, that's a rather helpful reply and one which my further reading
confirms. I realize it can be any kind of "protocol" for server to
server data exchange or "client type agnostic" even. It would be
interesting to know if there is a formal definition to these "sets of
practices" but they sound similar to a J2EE stack of technologies if
you ask me. Being able to automatically go down the list in a registry
seems more like a mirrored cluster.

'Self healing' sounds misleadingly better than what it is. It sounds
like a protocol might be able to diagnose and restart offline mirrors
in so many cases. What it seems like it really is would be the simple
ability that is found in TCP/IP and that is routing around or perhaps
"self healing" the connection if the connection breaks. Perhaps
"session" is involved. I'll have to look up more on jini.org but this
seems to contradict what is being said on Java World about SOA soon to
replace J2EE. What I think might be more true would be multiple core
support and SOA might give some languages and advantage over others as
these two new trends take a foot hold in enterprise. It's clear there
is support for SOA and all kinds of projects for various CPU
architectures, real time etc etc. out there in Java. It comes across as
a mere whinge about J2EE's complex set of technologies.

 

[Danno]

Or, as I would prefer to call it, "horrifying".

-- chris

Eh, if they put all the packages from java.* and javax.* in a single
diagram, it would be just as scary to noobies.

 

[Mike Schilling]

Or, as I would prefer to call it, "horrifying".

You think the diagram's horrifying? Try reading most of the standards.

 

[Chris Uppal]

Eh, if they put all the packages from java.* and javax.* in a single
diagram, it would be just as scary to noobies.

Java class libraries are /supposed/ to be made up of lots of small classes
which interact in potentially complex ways -- that's how we manage the
necessary complexity of programming.

Standards are /not/ supposed to be complex assemblages of interacting
documents.

When I look at a chart like the one linked to above, I see a
design/standardisation process gone horribly wrong.

-- chris

 

[Chris Uppal]

You think the diagram's horrifying? Try reading most of the standards.

You mean to say they don't have the relative simplicity and orthogonality of
the classes in java/javax ? That's a crushing disappointment.

;-)

-- chris

P.S. my personal "favourite" standard is RFC 2543 ("Session Initiation
Protocol") -- 150-odd pages of impenetrably complicated and intricate design to
achieve almost nothing.

 

[Danno]

You mean to say they don't have the relative simplicity and orthogonality of
the classes in java/javax ? That's a crushing disappointment.

;-)

-- chris

java.util.Date, java.util.Calendar, java.util.GregorianCalendar,
java.sql.Date, java.sql.Timestamp, java.sql.Time.

C'mon, we are java programmers who love our language but let's be
realistic, many java and javax classes are not a) simple or b)
orthogonal. Take managing a date in java for example.

 

[Chris Smith]

Java class libraries are /supposed/ to be made up of lots of small classes
which interact in potentially complex ways -- that's how we manage the
necessary complexity of programming.

Standards are /not/ supposed to be complex assemblages of interacting
documents.

When I look at a chart like the one linked to above, I see a
design/standardisation process gone horribly wrong.

The other interesting thing worth noting is that the "standards" there
range between several different standardizing organizations, or in many
cases none at all. A lot of the basic stuff is W3C-based, but then the
others (including most of them that I haven't heard of before now) are
documents published by one vendor or another, or standardized by OASIS,
which is a standardization body that appears to have popped up for the
*sole purpose* of writing and approving yet more specifications for web
services. Good thing we can ignore all that and just write relatively
straight-forward web services with SOAP and WSDL.

 

[Mike Schilling]

The other interesting thing worth noting is that the "standards" there
range between several different standardizing organizations, or in many
cases none at all. A lot of the basic stuff is W3C-based, but then the
others (including most of them that I haven't heard of before now) are
documents published by one vendor or another, or standardized by OASIS,
which is a standardization body that appears to have popped up for the
*sole purpose* of writing and approving yet more specifications for web
services. Good thing we can ignore all that and just write relatively
straight-forward web services with SOAP and WSDL.

And even the SOAP and WSDL specs seem to have been written by two groups who
have never spoken with each other.