[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

WG: HTTP / EMAIL / FTP / WAP tunneling proposal


in the last weeks I heard very often about SOAP. SOAP is the shortcut for
Simple Object Access Protocol. SOAP is making existing application
accessible to a broader range of users. It seems to concern the same
problematic as Marcel described in his Mail.

SOAP adds a set of HTTP headers and a rich XML payload to enable complex
application-to-application communication over Internet. SOAP defines the
mechanism to pass commands and parameters between HTTP clients and servers.
The requests and response ar formatted in XML. 

Here some web-resources about SOAP:

My knowledge about SOAP is very small but I think it could be a possible way
to solve the proposal. I also heard about Corba vendors (for example IONA)
which are committed to support SOAP in future versions of their ORBs.

thats it

> -----Ursprüngliche Nachricht-----
> Von:	Max Ruff [SMTP:jmruff at bluewin.ch]
> Gesendet am:	Samstag, 11. März 2000 21:33
> An:	xmlblaster-devel at server.xmlBlaster.org
> Cc:	xmlblaster at server.xmlBlaster.org
> Betreff:	HTTP / EMAIL / FTP / WAP tunneling proposal
> Proposal for messaging over connectionless protocols.
> (email, http(s), ftp, wap etc.)
> For messaging in the internet somtimes CORBA may be
> too rigid (firewalls and other reasons).
> It should be possible, for example to tunnel firewalls
> with http, send messages with emails or using ftp.
> So this proposal specifies a xmlBlaster message format
> to be used with those protocols.
> Here is an example, how it could be typed into an email
> body and send to xmlBlaster. I will discuss this with
> xml directly, since DTD (xmlBlaster.dtd) is not expressive enough
> and XML Shemas (xmlBlaster.xsd) are not yet supported.
> <?xml version="1.0"?>
> <xmlBlaster method="publish" sessionId="12aa3z45X"
>                    xmlns="http://www.xmlBlaster.org";>
>    <key oid="myMessageId" contentType="text/plain">
>       <!-- Some user specified meta information for this content
>              which is queryabe with XPATH -->
>    </key>
>    <content link="" xmlns="">
>       <!<CDATA[ Hello world ]]>
>    </content>
>    <qos>
>       <!-- Some quality of service tags, to control xmlBlaster -->
>       <isDurable />
>    </qos>
> </xmlBlaster>
> Here a discussion about this approach
> 1. The 'xmlBlaster' root element encapsulates the xmlBlaster message.
>    The attribute 'method' tells xmlBlaster which method to invoke:
>    one of the CORBA IDL specified methods like 'publish' 'subscribe' etc.
>    The attribute 'sessionId' is the identifier of the sender,
>    it was retrieved by a login with a password message (see below)
>    Another variant could always send the 'loginName' and 'passwd'
> attibutes
>    with each message.
>    The 'xmlns' specifies the xmlBlaster.org namespace as default, so we
>    don't need to prefix each tag explicitly.
> 2. The 'key' element you know already from the xmlBlaster CORBA
> invocations.
>    It may contain some arbitrary user defined meta data about the
>    content (not shown here).
>    Here it specifies the unique message identifier with the 'oid'
> attribute.
>    The 'contentMime' attribute sets the MIME format of the message
> content.
> 3. The 'content' element supplies the message content in the MIME
>    format as specified in the attribute 'contentMime' of the key tag.
>    Here it is plain text "text/plain", which is protected by a CDATA
> section.
>    Not that the token "]]>" in the plain text would make the message
> unparseable.
>    The xmlns="" attribute resets the namespace to nothing,
>    it may be replaced by a message specific namespace if there is one.
>    The link="" attribute allows to specify a location where the content
>    is delivered. For example a binary content could be in the attachment
>    of an email. The empty string tells us that the content is directly
>    embeded.
>    Note that for example a 'subscribe' method invocation does not need
>    to specifiy the content.
> 4. The 'qos' element you know already from the xmlBlaster CORBA
> invocations.
>    It allows a fine grained control of the xmlBlaster MOM behaviour.
> Open questions with this apporach:
> a. How can we specifiy to send BLOB (binary data) contents with
>    http (how to set the link attribute)?
>    Use some sort of multipart request?
> b. Is it possible to express this approach exactly with the coming
>    XML Schema language?
> c. How to do a login?
>    What about this approach (only interesting tags shown):
>    <xmlBlaster method="login" loginName="ben" passwd="sunshine"
>                callbackProtocol="EMAIL" callback="ruff at swand.lake.de">
>       <qos>
>       </qos>
>    </xmlBlaster>
>    This message could respond with the 'sessionId' for a synchronous http
>    invocation (allowing to recognize the client again on following
>    invocations), but it would not be very smart to use with asynchronous
> emails.
>    With emails sending loginName and passwd with each invocation
>    may be more convenient.
>    The 'callback' attribute allows to specify where xmlBlaster shall
>    send its asynchronous callback messages (updates).
>    It may be an email address, an URL to a HttpServlet, a CORBA IOR
>    or whatever protocol xmlBlaster will support in future.
>    Note that the sender and the callback protocol may be different.
> Please comment on this, since there are many out there who know
> more about the different technologies.
> More informations on RPC and XML you find on our homepage under
> 'Internet Resources'.
> If i find time at the end of the week,
> i will implement a little demo with http,
> allowing xmlBlaster messages to be tunneled through firewalls.
> I believe SUN's XmlRpcServlet may be a nice foundation to
> implement it very quickly, see
>     http://developer.sun.java.com/developer/products/xml/examples/rpc
> cu,
> Marcel
> ruff at swand.lake.de