MDB or Web Service?

[wizard of oz]

At the risk of starting a "preferences war", I often pondered this
question...

When would I use one or the other to implement a set of online services?
What are the pros and cons of using one over the other? Has anyone come
across a good "write up" comparing the different IPC mechanisms?
Assuming there isn't a corporate standard that says "we only use X", is the
choice a personal preference? Other than the "I know X but not Y reason",
what are the factors in that preference?
Does it makes sense to mix MDB's and Web Services to implement a single
service offering or is it better to select a mechanism and stick with it?
Have people looked at these and used something else (e.g. RMI, Sockets,
something else)? If so why?
Does it make a difference depending upon the App Server selected (e.g. one
App server might be able to perform better using one mechanism compared to
another App server that performs better with the other)? Has anyone come
across any benchmarks on this front?

If scope is important to you, I'm primarily thinking of a private service
such as one that an organisation might implement on an Enterprise Bus to
deliver services to a number of different application clients within an
enterprise. However any comment on public services is also appreciated.

TIA

WOZ

 

[Arne Vajhøj]

When would I use one or the other to implement a set of online services?
What are the pros and cons of using one over the other? Has anyone come
across a good "write up" comparing the different IPC mechanisms?
Assuming there isn't a corporate standard that says "we only use X", is
the choice a personal preference? Other than the "I know X but not Y
reason", what are the factors in that preference?
Does it makes sense to mix MDB's and Web Services to implement a single
service offering or is it better to select a mechanism and stick with it?
Have people looked at these and used something else (e.g. RMI, Sockets,
something else)? If so why?
Does it make a difference depending upon the App Server selected (e.g.
one App server might be able to perform better using one mechanism
compared to another App server that performs better with the other)? Has
anyone come across any benchmarks on this front?

If scope is important to you, I'm primarily thinking of a private
service such as one that an organisation might implement on an
Enterprise Bus to deliver services to a number of different application
clients within an enterprise. However any comment on public services is
also appreciated.

I think message queues and web services (SOAP/HTTP) supplements each
other not substitutes each other.

A message queue is: async, intranet only, allows for 1:M interaction.

A web service is: request-response, intranet and internet, does not
allow for 1:M interaction.

Two different solutions for two different problems.

Arne

 

[Corneil]

At the risk of starting a "preferences war", I often pondered this
question...

When would I use one or the other to implement a set of online services?
What are the pros and cons of using one over the other? Has anyone come
across a good "write up" comparing the different IPC mechanisms?
Assuming there isn't a corporate standard that says "we only use X", is the
choice a personal preference? Other than the "I know X but not Y reason",
what are the factors in that preference?
Does it makes sense to mix MDB's and Web Services to implement a single
service offering or is it better to select a mechanism and stick with it?
Have people looked at these and used something else (e.g. RMI, Sockets,
something else)? If so why?
Does it make a difference depending upon the App Server selected (e.g. one
App server might be able to perform better using one mechanism compared to
another App server that performs better with the other)? Has anyone come
across any benchmarks on this front?

If scope is important to you, I'm primarily thinking of a private service
such as one that an organisation might implement on an Enterprise Bus to
deliver services to a number of different application clients within an
enterprise. However any comment on public services is also appreciated.

TIA

WOZ

Message Queue can be seen as the transport layer like HTTP is the
transport layer for SOAP/HTTP which you would call a web service.
You can also use SOAP/JMS which will use Message Queues as a transport
layer.
The biggest difference between Message Queues and HTTP is that
Messages Queues can have higher throughput because a client and server
can remain connected.
Message Queues can be persistent which means the content is written to
disk. You would not want to persist a request if you are actively
waiting for the response because you are able to deal with a failure,
however in the case where you do not want to wait for the response and
expect reliable handling of your request persistent message queues
provide the simplest mechanism for dealing with that requirement.

Message Queues provide mechanisms for managing and distributing the
workload across services.

In some cases you would use an Enterprise Service Bus to configure an
endpoint at a SOAP/HTTP endpoint but that is bound to SOAP/JMS
endpoint on the bottom of the ESB.

You would not expose a Message Queue based endpoint as a public
service. You might use it with select business partners.

 

[Roedy Green]

mix MDB's

what's an MDB? Surely you don't mean MS Access.

 

[Owen Jacobson]

what's an MDB? Surely you don't mean MS Access.

"Message-Driven Bean" -- an EJB that acts as a JMS MessageListener.

-o