axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jung, Eric (Contractor)" <>
Subject RE: Notification style operation
Date Thu, 22 Aug 2002 21:31:39 GMT
Just to throw some more options into the mess, you could also do
asynchronous callbacks using pushlets.

Although some of these sites refer to the client as DHTML or an applet,
there's no reason why the client can't itself be another servlet or, for
that matter, any endpoint using any protocol.


-----Original Message-----
From: Byrne Reese []
Sent: Thursday, August 22, 2002 5:11 PM
Subject: RE: Notification style operation

I think there is one thing that is clear to me in reading this thread...
as Edoardo Comar from Cape Clear pointed out, but did not necessarily
spell out... and that is the benefit of having someone in the middle, or
for a Web Services Network.

One thing a Web Services Network provides is mediation between various
protocols... I mean whether you are speaking JMS, HTTPS, FTP or SMTP, a
WSN to a certain degree obviates the need for you to worry about what
the person on the other end is "speaking" because the network mediates
the differences between the two.

Ok, I work for Grand Central, so take what I say with the appropriate
grain of salt, but one value I have seen Grand Central deliver to the
people connecting to us is just this sort of mediation.

As far JMS is concerned, or some kind of queuing... again, take a look
at Grand Central (cough cough). Much of what GC does is done
asynchronously, in fact all of our internally implemented services are
asynchronous. Conceptually it works just like a POP mail[/soap] server.
Simple SOAP interfaces allow you to fetch messages off of your queue,
acknowledge them, etc. Plus, there are alerts and notifications which
people can elect to receive if things go wrong somewhere in the middle.

IMHO asynchronous messaging makes notification type messages so much
easier to wrap my head around. Without a queuing mechanism, HTTP (which
seems to me to be the preferred SOAP transport protocol) does not really
support notification sytle messaging. At least with a WSN, every
interaction with a queue becomes a request/response; even if you are
receiving a notification - making talking over HTTP much more intuitive.

Byrne Reese

Grand Central Communications

On Thu, 2002-08-22 at 12:51, Maciejewski, Vincent (GMI - NY SWAPS)
> Too true. You would loose some interoperability. That would depend of
course on the actual protocol underneath JMS. However, we should think about
why we are using SOAP to begin with. There are two
> reasons as far as I can see. The first is that we want to integrate
businesses accross firewalls. In that case HTTP is a good choice. The seond
reason we want to use SOAP is to integrate enterprise
> applications. In this case it makes sense to standardize on a point to
point messaging platform from one vendor. The benefit being that a point to
point messaging protocol may be _significantly_
> faster than HTTP. Also I see no reason why a SOAP server should be locked
into a protocol. It make sense to be able to access a server using HTTP and
a point to point at a clients discretion. So is
> there a JMS handler for axis anywhere out there?
> -----Original Message-----
> From: Steve Loughran []
> Sent: Thursday, August 22, 2002 2:09 PM
> To:
> Subject: Re: Notification style operation
> ----- Original Message -----
> From: "Ricky Ho" <>
> To: <>
> Sent: Thursday, August 22, 2002 10:35 AM
> Subject: RE: Notification style operation
> > Are we losing the benefit of SOAP (heterogeneous language and runtime
> > environment) when we run SOAP over JMS (which is an API but not
> > ?  Because now both sides has to be JAVA, or even they have to be using
> the
> > same JMS vendor.  Maybe OK for an intranet environment where both ends
> > controlled by the same organization.  But in such a well-controlled
> > environment, why using a less efficient XML protocol ?
> this is a similar issue with .NET and remoting; if you want callbacks you
> have to use the non-interop protocol
> > I see an evolving trend of using async messaging over HTTP.  In this
> > the request and response are two separate "one-way" operations,
> > in a certain way.
> But http is a) synchronous and b) wont go through firewalls. So you need a
> proxy outside the firewall that you are bound to, IM style, or only do
> callbacks in a closed environment.
:/ byrne
(415) 344-3139

View raw message