[Standards] Feedback on I/O Object Forms

"Julian Kölle" aliban at gmx.net
Fri Mar 16 09:35:26 UTC 2007



-------- Original-Nachricht --------
Datum: Thu, 15 Mar 2007 18:02:25 -0700
Von: "Chris Mullins" <chris.mullins at coversant.net>
> [Overall Impressions]
> According to the author, they are trying to:
> 
> -          Discover Support Using Disco
> 
> -          Retrieve a list of support Ad-Hoc Commands along with enough
> metadata to call those commands (via XSD, in a way similar to WSDL)
> 
> -          Call the Commands in either a synchronous or async way. 
> Essentially (this is me talking, interpreting what I think the XEP
> author said), they're looking to replace SOAP Based Web Services with
> XMPP Based services. They're looking to do this due to the nature of
> their very long running transactions and the ability of an XMPP Service
> to send an "all done" message, and for the client to get it at some
> point in the future. The Async Nature of XMPP is really the main reason
> for things.
> 
Yes, beside this we like the Disco Mechanisms a lot as it allows the dynamic discovery of web services available through XMPP on the fly. The information returned in a Disco Browser GUI is sufficient for a programmer to know what the webservice functions do.


> So, the overaly purpose of the XEP is to build a framework for a SOA
> style Service. I'm not quite sure how this differs from XML-RPC over
> XMPP, or even SOAP over XMPP, but that's the case. I think it's primary
> difference is the desire for an async result due to a long running
> process. 
> 
Exactly. In addition to that XML-RPC is very limited in what data types it supports (the reason why SOAP was invented).

>  
> 
> [Object Spaces]
> 
> The XEP author is defining a custom namespace, called Object Spaces, in
> which parameters can be passed to & from the Service. These are defined
> to look like:
> 
> <x xmlns='http://xmpp.org/protocol/io-object-form' type='submit'>
>         <in>
>                 <proteinname>CAB08284</proteinname>
>         </in>
> </x>
> 
> I don't understand how this differs from an X-Data Form. The author
> keeps saying that X-Data won't do the trick, but either I'm missing
> something or the author is missing something. I don't understand why,
> during discover, the service wouldn't send back a data form (this is the
> required argument list):
> 
... 
> The resulting message would also have an X-Data from sent from the
> server back to the client with the results.
...
> 
> I can see defining some new field types:
> 
> -          Base64 Binary Data 
> -          XML Data
> 
> I understand the argument, "This is machine to machine communication,
> and X-Data is meant for human-to-machine communication", but I think
> it's flawed. X-Data (to me) seems to allow machine-to-machine with no
> trouble. 

We thought about extending X-Data, too. However, as I pointed out and as you mentioned here, X-Data is for human usability. X-Data is just *one* data envelope, not *the* data envelope. As pointed out in XEP-0050, Ad-Hoc Commands is thought to support other Data Envelopes then X-Data - X-Data was just the example.
As we said IO-Object Forms is for machine-to-machine communication. The current data types of X-Data are too limited for our needs. For example we want to transport CML documents or INSD documents or many other XML documents or even non xml data.
You suggested to extend X-Data with new fields. Indeed this would work.
However - as X-Data was thought to be used for human interoperability - we fear that we would break many existing X-Data client implementations due to an overload of possible complexity within the "extended" X-Data. How would a client X-Data GUI react on a XML object tree that contains the phylogenetic tree of a protein, including several protein sequences? Someone who codes a script against such a services would know how to handle the return (documented) objects. A dynamically generated GUI wont be able to handle. it.

We think that it makes sense to define an input-output namespace, where we can put arbitrary XML objects in, for being handled by the programmer/script developer and not by a client mechanism that renders a GUI around it (they could hold binary data too, if needed). A service may support even both namespaces, X-Data and IO-Object Forms. One that may be used by a Human directly by rendering a GUI around X-Data, the other to be handled as a complex XML DOM by a programmer/script developer.

>  
> 
> [Async Results]
> 
> I'm not sure the proposed mechanism for Async Results will work the way
> they're intended. Sending a Message to a bare JID to indicate, "I'm
> done" is (in my experience) somewhat bug prone. It's possible 2
> resources for that JID are online, and there's no guarantee the right
> resource will get the result. The Offline delivery mechanism is nice and
> almost gets us what we want, but it's still not quite right. 
> 

Of course the service must respond to the JID+Resource. If the resource is offline, for example because the client script crashed, you are right, the message might get lost because it is forwarded to another (GUI) client.

We thought that when a script crashed and gets restarted it is responsible to check for the results it is waiting for anyway: it would have stored the Ad-Hoc SessionIDs in a database and use them to get up-to-date with the calculation statuses of the web services. This use case (getting up to date/checking the status of the Ad-Hoc-webservice) is defined within the XEP IO-Object Forms proposal.

We don't think we should create a new client connection for each service call as the script might want to start many 100 of web service calls. But maybe I did not get what you suggested here.

Of course we are open and happy for suggestions to make the Async-Method better. Maybe we missed something :)

I hope this mail clarifies the questions and intentions a bit.

Best regards,
Edrin
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer



More information about the Standards mailing list