Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 45171 invoked by uid 500); 16 Nov 2001 17:39:20 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 45162 invoked from network); 16 Nov 2001 17:39:20 -0000 Message-ID: <00f701c16ec5$82a2e210$9fa17cca@watson.ibm.com> From: "Sanjiva Weerawarana" To: References: <47FD4196C273D411950300508BCF197801656D06@S0001EXC0006> <032501c16e47$328cb4a0$48a17cca@watson.ibm.com> <001b01c16e4a$a9ff9860$b3185480@genesis.adtech.internet.ibm.com> <003901c16ea8$700ebe20$9fa17cca@watson.ibm.com> <000d01c16eb6$8757dc70$8a161818@genesis.adtech.internet.ibm.com> Subject: Re: What do we do with operation types: notification, solicit-response? Date: Fri, 16 Nov 2001 23:38:24 +0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Ben, > Well, transport is not totally an orthogonal issue. Suppose our transport > is Http. And we have a service that provides notification every time event > E happens on the server. We don't want the client to have to have a web > server to receive all the notifications by HTTP PUT. IM provides a much > lighter-weight method for the client to receive messages from the server. OK so you've interpreted solicit-response as event mechanism. That, however, is not the only interpretation - it can also be viewed as a piece of "required" functionality of the service and that the required functionality can be provided by a 3rd party w.r.t. the service client and the provider. There are other possible views too. I agree the transport is not orthogonal to the convenience of implementing events. If the semantic is event semantics, then it can certainly be implemented for HTTP too; yes that would require the client to offer a service to which the event is delivered. > I > wrote the Jabber code for Axis and Soap 2.2. I've been thinking of > comitting it, but I don't have time at school to keep updating my code. > Once a new alpha comes out, I'll update it again. Cool. I thought your name was familiar but couldn't place the context! Its certainly nice to have Jabber transports .. it validates that the transport abstractions can be mapped to a relatively different transport. Sanjiva.