Things get ugly when we start using terms that imply a specific deployment architecture when showing logical diagrams. Personally, I don't like refering to this as hub and spoke or a bus. I prefer terms like Service Network or Service Fabric when trying to illustrate the processing that should occur "in the middle." Whether it winds up being a bus architecture, a hub and spoke architecture, a grid architecture, or anything else should be determined based upon the needs of your particular situation. How much do you want to avoid agents/drivers on your endpoints? How much do you want to focus exclusively on WS-* based communication? How centralized do things need to be? How much custom development are you comfortable with? How much have you already invested in EAI systems or MOM systems? These are all factors that must be weighed.
I don't get too many hangups on presentations like these, because I look past the terms like bus or hub, and think of things from a logical view. The other thing to keep in mind is that most of this stuff is more about marketing spin than anything else. ESB has a high "buzz" factor, just like "governance." IBM is playing the game to try to take some of the "buzz" away by associating ESB with EAI (which is certainly true for many vendors). For the record, I view EAI systems as an endpoint/node on the service network, not as an intermediary. As for ESBs, the biggest problem I have is that if I were to write down the union of all capabilities that all of the varieties provide, I would wind up with some capabilities that belong at nodes on the service network and some that belong in intermediaries. This mismatch creates a dilemma. Note, that I have the same dilemma with intermediaries that are trying to expand their capabilities. If too much emphasis is given on the grey areas, I may wind up with a product that doesn't do a good job on the core competencies in the black and white areas. Unfortunately, the grey areas are the ones that drive marketing buzz.. high risk, potentially high reward. My advice: Break the problem space down into a list of capabilities. Decide where you want those capabilities handled, at the endpoints/nodes, in the network, or both. Then find products that match your approach, regardless of what the marketing staff are calling them. -tb -----Original Message----- From: William Henry [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 2:53 PM To: [email protected] Subject: [service-orientated-architecture] oh dear. IBM story gets worse. Okay so I read another article form the same author as my last post about IBM's strategy/story. in it the author claims that IBM equate SOA to EAI hub-and-spoke and ESBs are the hub. Article here: http://www.regdeveloper.co.uk/2005/12/06/ibm_soa_comment/ My comments here: http://www.ipbabble.com/2005/12/soa_does_not_equate_to_eai_hub.html I hope all is not lost. It's enough to drive a person to drink .. and it's only Wednesday. Can we have a voice of reason here from Anne (T.M.)? Any comments on this Anne? Regards, William Henry William G Henry [EMAIL PROTECTED] http://www.ipbabble.com Yahoo! Groups Links ------------------------------------------------------------------------------------- A.G. Edwards & Sons' outgoing and incoming e-mails are electronically archived and subject to review and/or disclosure to someone other than the recipient. ------------------------------------------------------------------------------------- ------------------------ Yahoo! Groups Sponsor --------------------~--> AIDS in India: A "lurking bomb." Click and help stop AIDS now. http://us.click.yahoo.com/9QUssC/lzNLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
