| Author |
Message
|
| fatherjack |
 Posted: Fri Jan 07, 2011 5:09 pm Post subject: Why is Web Services the 'de-facto' integration standard |
 |
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
We all know that web services is becoming the de-facto standard for application integraion but why?
Why do we use such an unreliable transport mechanism? Why not use MQ?
Anybody out there had these discussions? And more importantly won? If so, what was your winning argument?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jan 07, 2011 5:52 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Because Mgmt can spell "SOAP", but stumbles over "MQ". |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jan 07, 2011 6:10 pm Post subject: Re: Why is Web Services the 'de-facto' integration standard |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fatherjack wrote: |
| We all know that web services is becoming the de-facto standard for application integraion but why? |
Is it the de-facto standard?
OK well maybe someone will have a better answer than this.. But here's an opinion.
Web services offer a synchronous way of working.
Synchronous comms insist that the server infrastucture is up and highly available when apps want to get a service. The app asks for a service. It waits. It gets the answer/output.
If you want to serve an online user this model is great.
But if you want to build a batch system that works mainly offline from users and tolerates momentary problems, performance mismatches, latencies, etc. etc. then I don't think that model is so great.
Asynchronous parts of the system (eg. MQ) can help allow processors continue independently from each other, and be tolerant of short-lived communications failures. This fault tolerance can be delivered by periodic retries (cheap to deliver) rather than high availability mechanisms (often expensive to deliver).
(By the way, MQ offers various tricks for online high availability as well as retries! Eg. qmgr clusters, HACMP style HA, comma-separated CONNAMEs)
So I guess you use whatever architecture fits your requirements, and if that includes web services at some points, fine. But maybe it is NOT necessary in your particular system requirements, and you can program to MQ APIs instead.
As ever, use whatever is the right tool(s) for the job at hand.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 07, 2011 9:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I believe that the more potent answer for management here is in the SOAP concept itself: the fact that applications can understand and produce the message even though they exist on different platforms, run under a different OS and have been written in a different programing language. The message (mostly XML) can be looked at as being self defining and can be browsed or looked at by humans as well as by machines. (Imagine the AHA effect of the manager when he reads the XML and understands the meaning of the message instead of having to ask for the help of an IT person to interpret things for him...)
If you look a few years in the past everybody was speaking about CORBA (was that for Common Object Repository Broker Architecture)?
Well CORBA is out and SOAP is in...
Like all fashionable trends this one will run its course and leave us with a new one. Maybe MESSOAP (Media Enabled Streaming SOAP)? Who knows or can predict the future, even 10 years from now?...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| fatherjack |
| Posted: Sat Jan 08, 2011 2:15 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| fjb_saper wrote: |
| I believe that the more potent answer for management here is in the SOAP concept itself: |
I'm more than happy with SOAP. But why not SOAP over MQ rather than SOAP over HTTP?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Jan 08, 2011 6:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fatherjack wrote: |
| ...I'm more than happy with SOAP. But why not SOAP over MQ rather than SOAP over HTTP? |
Because if you are a shop that doesn't use WMQ would you really want to make that sort of investment? SOAP over HTTP is cheap, i.e. free, after costs of network etc.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jan 08, 2011 10:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| fatherjack wrote: |
| fjb_saper wrote: |
| I believe that the more potent answer for management here is in the SOAP concept itself: |
I'm more than happy with SOAP. But why not SOAP over JMS/MQ rather than SOAP over HTTP? |
- because it takes more development effort to do SOAP over MQ than it does to do SOAP over http
- because in this "time to market" economy the fastest, dirtiest POC threatens to become "standard", without consideration to load balancing, time-outs etc...
- because no manager wants to hear about the advantages of SOAP over JMS/MQ when you have to tell them why it did not work, especially when the answer is it works as designed, and some developer whispers it would be easier to fix with http....
- because your manager has a better grasp of load balancing over a hardware piece (http load balancer) than the load balancing achieved by MQ clustering...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Jan 08, 2011 11:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| fatherjack wrote: |
| ...I'm more than happy with SOAP. But why not SOAP over MQ rather than SOAP over HTTP? |
Because if you are a shop that doesn't use WMQ would you really want to make that sort of investment? SOAP over HTTP is cheap, i.e. free, after costs of network etc. |
I'm in a shop with both WMB & WMQ and developers still want SOAP over HTTP. The official reason is "it's lightweight and simple", but I've heard that their management view is that anything IBM is just too 20th Century to be cool.
I understand the more extreme view among the developer team is that only a 100% Microsoft solution is worth developing.
I despair some days.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Jan 08, 2011 12:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| because it takes more development effort to do SOAP over MQ than it does to do SOAP over http |
See also my previous post
| fjb_saper wrote: |
| because in this "time to market" economy the fastest, dirtiest POC threatens to become "standard", without consideration to load balancing, time-outs etc... |
I'd not thought of that but yes, that's my lot too.
| fjb_saper wrote: |
| ]because no manager wants to hear about the advantages of SOAP over JMS/MQ when you have to tell them why it did not work, especially when the answer is it works as designed, and some developer whispers it would be easier to fix with http.... |
Or developers just don't trust any transport mechanism where they can't interogate a TCP/IP return code & handshake. That WMQ "assures" delivery is a concept they can't grasp and/or don't trust.
| fjb_saper wrote: |
| because your manager has a better grasp of load balancing over a hardware piece (http load balancer) than the load balancing achieved by MQ clustering... |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Sat Jan 08, 2011 2:30 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| Vitor wrote: |
| I'm in a shop with both WMB & WMQ and developers still want SOAP over HTTP. |
Yes, this is exactly the sort of scenario I was thinking about. Sure, me, at home, on my PC, needing to access services over the web, then webservices makes absolute sense 'cos I'm not going to install MQ or even MQ client. But major organisations who already use MQ still seem to be clamouring to use web services. Presumably 'cos its cool.
| Vitor wrote: |
| I understand the more extreme view among the developer team is that only a 100% Microsoft solution is worth developing. |
And yes, I'm seeing that too. Dot-Net is apparently fantastic and bug free if you believe everything they tell you.
Will at last, a standard actually become a standard, will webservices see the death of all other integration technologies. Will I need to get some training in other technologies and start looking for another job ????
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Jan 08, 2011 2:44 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
SOAP/JMS is a standard these days.
One thing holding back and making it harder to do SOAP over MQ was the lack of SOAP/JMS as a standard.
No reason to provide tools for it in AXIS or .NET or etc (although how .NET is going to respond to "JMS" is a separate issue) if there's not a standard behind it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 08, 2011 4:21 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fatherjack wrote: |
| Vitor wrote: |
| I'm in a shop with both WMB & WMQ and developers still want SOAP over HTTP. |
Yes, this is exactly the sort of scenario I was thinking about. Sure, me, at home, on my PC, needing to access services over the web, then webservices makes absolute sense 'cos I'm not going to install MQ or even MQ client. |
I wonder how many Java / JMS apps were on the fence between MQ and some other method, and tipped the other way because, officially, we still have to install the complete MQ Client just to use a few jar files? I know its easy to install the full MQ Client. Doesn't change the fact that its still administrative overhead to accomplish this, and based on the amount of red tape at your company, not necessarily a small amount of administrative overhead.
IBM's gotta provide an official way for Java / JMS apps to use MQ Client functionality without having to install MQ Client. Bring back Support Pack MA88 and make it a Cat 3 Support Pack.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 08, 2011 4:27 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| That WMQ "assures" delivery is a concept they can't grasp and/or don't trust. |
Or perhaps don't need?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Jan 08, 2011 4:39 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well... There are two or three "automatic" pre-supplied HTTP<->MQ bridges that require no client at all...
 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 08, 2011 4:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
True. I haven't played with them, but my understanding is that they don't offer the full functionality that the MQ Java / JMS jars do. Not that you always need all that functionality....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
