axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Thomas Manes <>
Subject Re: XML "Event Channel"
Date Sun, 13 Nov 2005 12:17:40 GMT
Sounds like a very inconvenient interface.
I don't know of a tool that can help you develop a client for a raw socket
protocol. I think you'll just have to write a socket client that listens for

You might suggest to the service provider that they upgrade the event system
to RSS.


On 11/12/05, Steve Cohen <> wrote:
> I think this may be the wrong list to post this on, but I am hoping that
> someone will see this and be able to direct me at the right place.
> I am charged with developing an interface to a system with the following
> characteristics:
> There is an XML-RPC interface with which one can exchange synchronous
> messages via XML-RPC. I know this is not the same as SOAP or Web
> Services but it it close. I know there is an Apache XML-RPC project
> that provides the tools that could handle this, but I am not directing
> this to their mailing list because I find it doesn't get much traffic.
> Anyway, this is not my question but a mere preliminary to it.
> As an adjunct to this synchronous XML-RPC service, this system also
> provides for an "event channel" to which a logged on user may
> subscribe. The XML-RPC response to the initial logOn request provides a
> host and a port number back to the requestor. The requestor can, with
> this information register for the event service and open a TCP/IP socket
> connection to that host and port.
> From that point on, various xml-coded event messages will be sent back
> along the event-channel to the subscriber. The xml in these messages is
> similar to what one might receive via xml-rpc, but it's not coming in an
> HTTP wrapper. It's just random defined bits of XML coming at
> asynchronous intervals.
> I may be dense here, but what kind of client must monitor this event
> channel in order to receive the events? The P in HTTP defines a
> protocol that presumably includes logic that delimits the beginning and
> end of HTTP packets so that the reciever knows when to begin actual
> processing. This is what is used by systems such as XML-RPC and SOAP.
> But this service does not run over HTTP. It runs over TCP/IP. Is there
> a tool available that handles the "packetizing" of such a packet without
> forcing me to write a tool that watches the socket byte for byte and
> determines when a message has been wholly retrieved before submitting it
> for processing?

View raw message