| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Question about Transport of Services in a SOA/only with MQ ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| dprogwmb |
 Posted: Mon Aug 20, 2012 9:03 am Post subject: Question about Transport of Services in a SOA/only with MQ ? |
 |
|
Voyager
Joined: 19 Jul 2011
Posts: 96
|
Hi all
I'm in a project where the "SOA Architect" has defined all of the inputs to the message flows of the broker thru MQ Queues.
The application that consumes the Broker "Services" is an J2EE app (web app that runs on WAS), that invokes those each service putting a message in an MQ Queue.
The services are synchronous , so I'm thinking it's not a SOA... and it's not the best way to represent the services (only the interface would be the .xsd of the service)...
The "SOA Architect" says it's an excellent design, because thinking in a production environment, he can use MQ Clusters instead of Load Balancer (thinking of using webservices )... And he says that because there will be an Registry and Repository for Services they will be described there...
I'm not agree with him in nothing  ... I'd prefer the Webservices for the publication of the interfaces, the synchronicity of the problem, and so on.
So , what do you think about this "SOA architectural approach"?
We are using as ESB the Websphere Message Broker and as Registry and Repository the WSRR... And for monitoring IT CAM for SOA
Any opinions? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Aug 20, 2012 9:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
SOA is an architecture - a set of methodologies and practices.
It's not a set of technologies.
SOAP over JMS is still SOAP.
SOAP calls are always synchronous, unless you explicitly make them asynchronous. Again, this has nothing to do with whether they are over JMS or over HTTP.
It's great that you disagree with the architect, it means you're thinking about things. But he or she is still the architect. |
|
| Back to top |
|
|
| dprogwmb |
| Posted: Mon Aug 20, 2012 9:16 am Post subject: YES, but he's not using SOAP Thru JMS :( |
|
|
Voyager
Joined: 19 Jul 2011
Posts: 96
|
But the technologies you use must adapt to that principles and metodologies (SOA).
He is not using SOAP thru JMS ... in that case would be fine (only the transport is changing from traditional webservices over http)...
He is using simple MQPUT and MQGET (with CorrelId) of standard JAVA MQ API ... and he's using xsd's to define the schema of the messages...
For me it's not a real SOA , because you can't "publish" that xsd as a service with operations , so the consumers can locate and invoke that service as they wish....
And the worst is that he's using MQ (naturally asynchronous) as Synchonous... (with the wait and use of the CorrelID to identify the original message)...
Sorry but I'm still thinking it's not a good architectural practice for a SOA...
I would have used Webservices over http (or over jms... altough it may have some performance issues).
I know he's still the architect, but I don't understand why he is...
Is anybody agree or disagree with me?
Regards everybody!
| mqjeff wrote: |
SOA is an architecture - a set of methodologies and practices.
It's not a set of technologies.
SOAP over JMS is still SOAP.
SOAP calls are always synchronous, unless you explicitly make them asynchronous. Again, this has nothing to do with whether they are over JMS or over HTTP.
It's great that you disagree with the architect, it means you're thinking about things. But he or she is still the architect. |
|
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Aug 20, 2012 9:59 am Post subject: Re: YES, but he's not using SOAP Thru JMS :( |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| dprogwmb wrote: |
| "publish" that xsd |
I agree with your point about having a contractually obligated data format through XSD.
This contract can be exercised over all forms of transport.
I would tactfully suggest that each data package be described by XSD (assuming the data is all XML) and that content and value validation of payloads be enabled at the WAS side.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 20, 2012 11:28 am Post subject: Re: YES, but he's not using SOAP Thru JMS :( |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dprogwmb wrote: |
He is not using SOAP thru JMS ... in that case would be fine (only the transport is changing from traditional webservices over http)...
He is using simple MQPUT and MQGET (with CorrelId) of standard JAVA MQ API ... and he's using xsd's to define the schema of the messages... |
Granted that it's not leveraging the advantages of full SOAP over JMS, and it's valid to question that. But the XSD can be considered a "contract" in that's it's an agreed data format.
| dprogwmb wrote: |
| For me it's not a real SOA , because you can't "publish" that xsd as a service with operations , so the consumers can locate and invoke that service as they wish.... |
Granted that you can't publish this with WSRR or similar. But you can manually publish them by a variety of methods. Are they as good as using WSSR et al?
| dprogwmb wrote: |
| And the worst is that he's using MQ (naturally asynchronous) as Synchonous... (with the wait and use of the CorrelID to identify the original message)... |
IMHO WMQ is not naturally asyncronons. It's an assured transport mechanism and if perfectly suited to syncronous.
| dprogwmb wrote: |
Sorry but I'm still thinking it's not a good architectural practice for a SOA...
I would have used Webservices over http (or over jms... altough it may have some performance issues). |
It's not great, but it's workable. As I said, you could validly ask why not go the whole hog & use SOAP over JMS.
| dprogwmb wrote: |
| I know he's still the architect, but I don't understand why he is... |
Because he's not that wrong, and probably knows someone.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
