XML All-purpose Protocol
Added 2000-11-03
This was writen last spring. I spoke about this at WWW9 Conference,
publicly during questions at SOAP session. And it seems that somehow these
ideas have been incorporated in emerging standards like UDDI (http://www.uddi.org)
and WSDL (http://www-4.ibm.com/software/developer/library/w-wsdl.html).
But it is clear that the XML All-purpose Protocol is a more general mechanism
both for Web services and discovery. By this I mean that UDDI and WSDL
services can probably be expressed as XAP services.
This could also be called XML distributed architecture. For distributed
computing, I expect HTTP+XML to dominate over Corba and COM in the long
term. But SOAP (http://search.ietf.org/internet-drafts/draft-box-http-soap-01.txt)
and XML-RPC are not enough. The need for servers to publish their schemas
for queries and responses is fondamental. Moreover the publication of the
schemas, and their consultation by the client, allows to simplify the subsequent
messages (see here the consequences for SOAP).
I you try to imagine how an application could navigate through
Internet, searching resources, much like us humans navigate on Internet,
starting with a search engine, and surfing from page to page, you can arrive
to this solution:
Axioms:
-
servers must define precisely what they offer, and clients are free to
take anywhere just what they need;
-
every message sent is XML
The proposed solution
Specify an XML service
At a well-known or starting point URL there could be a service specifying
other services. And there the content would be something like:
<serversDirectory xmlns="http://www.w3.org/2000/XAP">
<service xmlns:myVocab="http://myCom.com/">
<url>http://myCom.com/service.pl</url>
<vocabulary>http://www.myCom.com/service.xs</vocabulary>
<keyword>online shop</keyword><keyword>wine</keyword>
<defaults><myVocab:myProperty>my value</myVocab:myProperty></defaults>
<query>
<query-element> myVocab:myQuery </query-element>
<!-- name of an XML element in this vocabulary
specifying the query -->
<result-element> myVocab:myResult </result-element>
<!-- name of an XML element in this vocabulary
specifying the
result of the query (a priori only one
result-element
per query) -->
</query>
</service>
</serversDirectory>
Of course every name beginning with "my" isn't part of the specification.
The XAP specification has (provisional) XML namespace http://www.w3.org/2000/XAP
, and here is is an XML Schema for XAP.
Notes:
-
this offers both great flexibility and clear contract between client and
server;
-
a server can herald service(s) on the same site or others sites;
-
the vocabulary, in XML Schema or RDF Schema (or even DTD for old-timers)
can be on the same site or others sites; it can refer to Schema repositories
like Oasis etc, so that client and server can share a prior knowledge ;
-
it is possible to have a standard name for this file on a Web site, like
index.html
is the starting point for browsing, services.xml
would be the
starting point for an non-human client; or maybe (probably better) doing
without an extra file, and just (using XHTML) having a <serversDirectory
style="display:none"> element in index.html file.
-
it will also be possible to discover XML Schema representing server services
using the future XML-aware search engines, by just issuing a query for
elements <service> in XML namespace http://www.w3.org/2000/XAP
;
-
possibly there is no <query-element>, or it is empty;
-
using the vocabulary of "XML All-purpose Protocol" itself, it is possible
to point to other <serversDirectory>'s, depending on
the query made.
-
a service is not only defined by queries and responses; two services can
be differing only by the domain covered, e.g. one for plants of North America
and one for plants of China; how to specify this in the serversDirectory
element
? Or outside by RDF of Xlink statements? Answer: in the serversDirectory
element;
this is the purpose of the defaults element (could be called context)
-
there are possibly several vocabularies per service, several query-element
per
query,
several
services per serversDirectory
-
Client server protocol
Most of the semantics of the communication is specified prior to the message
by the serversDirectory element described above. What remain to
specify are book-keeping and error managing items.
Session ID
This is similar to the transactionID from SOAP. This is
an identifyer for a session, unique at least at server level. It must be
attributed by the server the first time it encounters a client, and afterwards
should be re-sent by both. The client starts a new session by sending a
request without a SessionID.
Error managing
to be completed.
Protocol for distributed botanical knowledge
This is just an example showing how a system can be made of very independant
data sources, sharing a set of XML Schemas.
Request types
-
request on descriptive characters towards a descriptive data base
-
request on family and/or Genus et/ou epithet towards a botanical
collection
-
request on geographical zone and/or habitat and/or taxon towards a biogeographical
data base
-
request on family and/or Genus et/ou epithet towards synonym and
accepted name management
Response types
The architecture will leave applications free to use informations for their
purposes. These requests will return either simply a number of responses,
or a list of URI representing univoquely taxa. Then another kind of request
will send a list of taxa URI , and will receive data :
-
XML formalized descriptions
-
2D or 3D images
-
repartition geographical maps (in SVG)
-
botanical garden map with localisation of requested taxa