It depends on your definition of ESB. I see an ESB as a piece of software to quickly configure intermediaries between mismatched service interfaces and/or contracts, manage the lifecycle of these dependencies, and monitor/operate what's happening at runtime.
If an interface is generalized to be seen as nexus of transport (how docs get moved between consumer & producer), format (how docs are represented), semantics (what the doc means to others), and runtime policy (rules of engagement), then transport is just a feature of the interface. Transport could be a protocol, or it could just be a messaging-oriented API, or perhaps one layered by the other.
In this case MQSeries is just a transport. As is HTTP, FTP, SMTP, etc. I found this view drastically simplifies a lot of the confusion around an ESB's role in an SOA, though it admittedly doesn't fit every vendor's spin. Caveat lector, I work for an ESB vendor...
Cheers
Stu
----- Original Message ----
From: Jerry Zhu <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, May 5, 2006 8:01:03 AM
Subject: [service-orientated-architecture] MQSeries vs. ESB
Are MQSeries and ESB are mutual exclusive or they can
coexist? I didn't see the two in the same
architecture anywhere. Please help.
Jerry
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.
