| Author |
Message
|
| Vitor |
 Posted: Thu Mar 15, 2012 9:46 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| There are circumstances where direct connections are useful. |
Name 3. 
| lancelotlinc wrote: |
| Not all Web Services traffic has to make the intermediate stop in the ESB. |
If it doesn't, how do you replace / revise one of the web services? Isn't one of the key points of an ESB that it's the bus on which all of the services in the enterprise are located?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Mar 15, 2012 10:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| lancelotlinc wrote: |
| There are circumstances where direct connections are useful. |
Name 3.
| lancelotlinc wrote: |
| Not all Web Services traffic has to make the intermediate stop in the ESB. |
If it doesn't, how do you replace / revise one of the web services? Isn't one of the key points of an ESB that it's the bus on which all of the services in the enterprise are located? |
Again, the point I'm making here is that it's all well and good to say "Just throw up a quick web service". But that has to, at some point, be demarked and you have to say "This is the web service that is *actually* going to do some work". And there's no reason to suspect that the decision on that has already been made, and it is *the message flow* that is the web service that is *actually* going to do the work!
Let's please try and stop with one layer of turtle under the elephants, shall we? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 10:09 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
@Vitor. The general rule is that traffic should flow through the ESB. In some cases, some may choose not to adhere to that rule. One example is for extreme latency considerations. We have a GUI app written in WAS that collects a bunch of data and submits it to the ESB for processing. For one part of the data collection (ie. prior to ESB submission), the ARB (Architecture Review Board) felt that response time was more important than purity for this one piece. A purist approach would be to send all requests through the ESB. I tend to like that rule. But the ARB chose response time over purism.
As you correctly pointed out, Vitor, if the WS changes, and direct connections exist, those connections may break.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 10:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| As you correctly pointed out, Vitor, if the WS changes, and direct connections exist, those connections may break. |
And if someone has decided that this mission critical app needs to make a direct connection because their app is mission critical & can't tolerate latency, it's going to be embarassing when it breaks unexpectedly because the web service owners decided to make a change & didn't know this direct connection exists.
So you need a mechanism by which web service owners know and can notify all non-ESB consumers of their service. Which couples them to their consumers, removes a key benefit of the ESB & add a whole layer of administration & control to the organisation. I imagine your organization manages this as well as it manages everything else, but the ARB I "answer" to reviews between 35-40 of the 1500 projects in train here due to time constraints. If we allowed exceptions (like direct connections to web services) they'd be chaos.
It's bad enough when we find an exception. Typically when something breaks.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 10:44 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Yes, yes, yes. Even my powers of persuasion are not yet strong enough to overcome the dark side of the force of the ARB. Hopefully, with your help, I will become a stronger advocate.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Thu Mar 15, 2012 10:51 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| lancelotlinc wrote: |
| Your statement about replicating data is true for many organizations. They should not do that. |
Imagine a company has stores or subsideries around the country/world.... Each with their own IT-System. During business they will happily exchange orders/invoices/receipts (with the headquarter (as the central hub)) and once a night/day the full stock/inventory. You say that they should not do the Inventory/stock part ?!
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Mar 15, 2012 11:01 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqsiuser wrote: |
| lancelotlinc wrote: |
| Your statement about replicating data is true for many organizations. They should not do that. |
Imagine a company has stores or subsideries around the country/world.... Each with their own IT-System. During business they will happily exchange orders/invoices/receipts (with the headquarter (as the central hub)) and once a night/day the full stock/inventory. You say that they should not do the Inventory/stock part ?! |
If I read Vitor's post correctly, I think he was referring to copying data from DB2 instance A to DB2 instance B simply because thats the quick and dirty way to have data to build views, etc. This would be in shops where DBAs rule the world and know little about SOA.
IBM produces industry-specific packages that help unify data. For example, many companies have multiple definitions of a customer record. Some older programs with older definitions have Address Line 1 to be 28 chars. Later, the company decided to support an Address Line 1 of 55 chars. Rather than go update the original customer record structure (in Cobol)_, they defined a new Customer record structure. Some programs use the old, some the new. Both versions are replicated many places to be concurrently available.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 11:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| If I read Vitor's post correctly, I think he was referring to copying data from DB2 instance A to DB2 instance B simply because thats the quick and dirty way to have data to build views, etc. This would be in shops where DBAs rule the world and know little about SOA. |
No, I was talking about your web service example, where someone has a web service which performs some function used by a mission-critical app. Due to perceived latency issues. the mission critical app invokes the web service directly rather than via the ESB.
At some future point the web service is redesigned / rehosted. The ESB is reconfigured to account for this. Unless a mechanism exists to inform the mission critical app of the change, it will break.
No databases or DBAs involved.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 11:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| Imagine a company has stores or subsideries around the country/world.... Each with their own IT-System. During business they will happily exchange orders/invoices/receipts (with the headquarter (as the central hub)) |
There is no hub in an ESB. There may well be a central repository, which may be hosted at the headquarters. All the stores should be updating this repository via the ESB, placing orders via the ESB, etc, etc.
Or what's the point of the ESB? You could have all the stores or subsideries updating their own systems, replicating that data to a central hub, that data being consolidated and replicated back out. It's cumbersome, time consuming and worked fine in the 1980s.
Then someone said "this is cumbersome & time consuming" and invented messaging. Years later someone wrapped the messages in SOAP and invented web services.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jacquesvdm |
| Posted: Thu Mar 15, 2012 9:31 pm Post subject: |
|
|
Apprentice
Joined: 18 Jan 2012
Posts: 29
|
Hi all
Thanks for the healthy debate, at the end I do still like the Web services idea as the PABX system most likely would not co-exist with the broker instance. I also do not want a "badly written" third party API effecting the broker execution.
It also seems to make allot of sense hiding the different PABX vendor's complexities in the web service and expose a common interface to broker and in this scenario any other application that wants to consume PABX methods.
This debate really helps me allot.
Thank you all. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Mar 16, 2012 7:43 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
