SOA is an architectural style of design that is defined by a set of design principles.
As implied by the name, the primary SOA design principle is service-orientation. This principle dictates that if a piece of functionality is required by multiple applications, then the functionality should be refactored and implemented as a shared, reusable service rather than duplicated in each application.
A service, therefore, is a representation of this functionality that can be shared by multiple applications. A service exposes it functionality through a well-defined interface. Service consumers (i.e., applications) use the interface to gain access to the functionality.The opposite of SOA is monolithic application silos where functionality and data must be duplicated in each application that requires them.
SOA is fundamentally different from integration. SOA is about breaking down application silos. Integration is about reinforcing silos and duplicating data.
ESBs are tactical integration solutions. They don't provide facilities that help you refactor functionality. You can use an ESB to provide connectivity among services, but using an ESB does not give you "instant" SOA. SOA is something you do, not something you buy.
And by the way -- you don't need an ESB to do SOA. Yes -- it's a useful tool to have in your toolbox -- especially if you want to expose legacy application functionality as a service. But it's still just raw materials. It's like lumber. You can have a wonderful stack of lumber, but that won't give you a house. To get a house, you need a design, and you need some hard work.
And Jerry's comment is not entirely accurate. Prior to 1998, you can be certain that MQSeries messages usually carried binary data -- sometimes in a standard format (e.g., ASN1), sometimes not. But there's no reason why MQSeries (now WebSphere MQ) can't transfer XML. And I suspect that most new MQ applications exchange XML now.
Meanwhile, ESBs don't always carry XML. About two-thirds of ESB products are MOM-based, and these MOM systems can carry binary data as well as XML.
Anne
On 5/9/06,
Radovan Janecek <[EMAIL PROTECTED]> wrote:
In SOA, the primary abstraction is the Service. You have good SOA, if you answer yes to questions such:
Is every service uniquely identified?
Can users easily find available services?
Is every service well described from business perspective?
Can any developer easily find all technical specifications of the service (interfaces, policies, etc.) to build a composite application?
Does every service provider have a sufficient control over who is using his/her service?
Is it possible to measure and report service reuse?
Is it possible to define and impose enterprise wide (or just reasonably wide) standards for how services are described? (what business schemas they can use, security mechanisms, SLAs, and similar)
Can you well automate auditing of the services conformance to these standards?
Most (if not all) of these questions suggest to start SOA implementation with establishing a service catalog that provides the visibility of services and their descriptions. Even if you start with ESB you should not miss the catalog part.
Radovan
On 5/9/06, Jerry Zhu <[EMAIL PROTECTED] > wrote:Both MQSeries and ESB transfer messages. The messages
in MQSeries are binary data while the messages in ESB
are XML data. Those messages are, to me, at different
levels of inter software communication.
I hear people say they are using SOA becase there are
XML messages passing around. XML has been around for
a long time but SOA is relative new. SOA is more than
passing XML messages. There maybe minimum
requirements in an architecture to be called SOA. So
how to tell a SW architecture that is SOA or not?
Jerry
--- Stuart Charlton <[EMAIL PROTECTED]> wrote:
> Let me correct myself and say "transfer" protocol
> instead of transport. Utimately, they're a way of
> moving bits with various differences in reliability,
> performance, available message exchange patterns,
> schemes to describe resources.
>
> My point is that an ESB should be independent of
> transfer protocol. It looks at transfer protocols
> in a modular way and can make it quite easy for a
> user to mediate between MQSeries inbound and HTTP
> POST outbound, or SMTP inbound and MQSeries
> outbound, adapting between varying message exchange
> patterns, levels of reliability, credential
> declarations, etc.
>
> Stu
>
>
> ----- Original Message ----
> From: patrickdlogan <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Saturday, May 6, 2006 10:39:39 PM
> Subject: [service-orientated-architecture] Re:
> MQSeries vs. ESB
>
> > In this case MQSeries is just a transport...
>
> Isn't MQSeries more than that? i.e. MQSeries moves
> things from here to
> there, but in various ways, asynchronously, with
> queue-based
> semantics, etc. That seems to be much more than
> "just a transport".
>
> > As is HTTP, FTP, SMTP, etc.
>
> And so aren't these more like MQSeries than they
> are like "any other
> transport"? i.e. they move things from here to
> there, but in various
> ways, with certain rules and expectations about
> sequence,
> sychronicity, identification, etc.
>
> > I found this view drastically simplifies a lot of
> the confusion
> > around an ESB's role in an SOA...
>
> It seems like an oversimplification to me.
>
> -Patrick
>
>
>
>
>
>
>
>
>
> SPONSORED LINKS
>
> Computer software
> Computer aided design software
> Computer job
> Soa
> Service-oriented
> architecture
>
> YAHOO! GROUPS LINKS
>
> Visit your group
> "service-orientated-architecture" on the web.
> To unsubscribe from this group, send an email
> to:
>
>
[EMAIL PROTECTED]
> Your use of Yahoo! Groups is subject to the
> Yahoo! Terms of Service.
>
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
SPONSORED LINKS
Computer software Computer aided design software Computer job Soa Service-oriented architecture
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture " on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .
--
Radovan Janecek
http://radovanjanecek.net/blog
SPONSORED LINKS
Computer software Computer aided design software Computer job Soa Service-oriented architecture
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture " on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
