Embrase.. Expand.. Extint..

[Didier PH Martin]

Hi,

You have probably noticed that two new spots appeared recently in the XML
world radar. Did you?
- E-speak
- Biztalk

These two universes have even an early SDK or Jumpstart kit.

Let's first examine Biztalk (I am still studying E-speak)

What is Biztalk?
-----------------
Biztalk is basically a message system. It is a XML based message system.
Several tools are provided in the Jumpstart to create VB objects from
X-Schema. In this sense, Biztalk may be perceived as a middleware like CORBA
or DCOM. Why? The IDL gets replaced with X-Schema and tools are provided to
create COM objects from X-Schemas. The marshalling format between the
objects is the XML format. An XML document named a biztalk document
encapsulate an XML fragment. The XML fragment is the message content, the
biztalk document the message's container. Microsoft defined the envelope,
the container, you define the contained fragment.

What is important to notice here?
---------------------------------
Two facets:
a) A message based middleware using SMTP, HTTP, XML and X-schema as ground
base. So far so good...
b) A subtle movement from an internet based messaging system to a Microsoft
based messaging system.

WHY?
Is this the conspirator theory again :-) No, just a simple analysis of facts
and implications of these facts in the market place.

A) What is the actual notion of an internet message?
----------------------------------------------------
The actual notion of an internet message is simply a text beginning with a
set of headers (ref: RFC 822)

This format is quite simple and is the base for both the internet mail
system and the HTTP system. For both, a message begins with a set of headers
like below:

<attribute>: <value>

Example:
--------------------------------
content-type: text/xml
from: martind at netfolder.com
to: xml-dev at ic.ac.uk

....this is the message body....
---------------------------------

Thus,  both HTTP messages and SMTP messages are formatted the same way. Only
the property set or the set of headers differ. There is a set of headers
particular to HTTP and set of headers particular to SMTP. Some are common
for both

The message's content is distinguished from the headers by a line feed
between the headers and the message body (as shown above).

B) What is a biztalk message?
-----------------------------

An XML document that could contain a "route" element. This latter specify
the "to" and "from" and other information about the document "routing".
On the windows platform, Biztalk messages will be processed by a Biztalk
server acting as a middleware tool to "route" the Biztalk documents. If both
ends are equipped with a Windows machine and more preferably with a Win2000
platform, the following scenario may occur.

a) the biztalk message is received by the recipient biztalk server
b) The message body is matched to a message handler. The matching process is
based on the name space Identifier.
c) if a matching message handler is found, this latter is instantiated and
given the biztalk message for processing. In fact, its interface member
named ProcessMessage is called and given the received biztalk message as
parameter.
d) The message handler does its job.

The message handler is a piece of code such as a Visual Basic piece of code.
The message content is encapsulated with a generated piece of code from an
X-Schema. Thus, the x-schema can be seen as an object interface definition
language and the generated piece of code as an objects like a CORBA or DCOM
object. The Biztalk message can then be seen as the marshaled format between
the objects.

C) What can be the consequences?
---------------------------------
Obviously, on windows, a rich set of tools will be available to process
biztalk messages.
a) Object creation generator from X-Schema
b) biztalk server
It will be, most probably be less expensive to have a windows platform on
both the client and server side.
But...
We moved from an internet based messaging system to a Microsoft based
messaging system. The major implication is that the message is now more
easily controled by Microsoft.

Why then the message properties are not encoded in RFC 822 format? The
answer may be that the biztalk server may choose the most appropriate
transport mechanism. For instance, that certain messages types are accepted
on a particular recipient only through SMTP. That encoding the message
information in XML provide some independence from the transport layer.

Is this flying? I do not know. But what I do know is:
A message server could be based on the internet messaging format. Here is
the possible scenario:

the sender prepares a simple RFC 822 encoded message as follow:

content-type: text/xml
from: martind at netfolder.com
to: xml-dev at ic.ac.uk
... imagine here other headers that can provide more info.....

<my-e-business xmlns=" a URI here ">
<?xml-stylesheet href="mystylesheet.xsl" type="text/xsl" media="screen"?>
... my e-business content....
</my-e-business>

The message headers could contain enough information for both a HTTP or SMTP
server. Or the message headers can contain a X-something header (X-something
header are proprietary headers - but an IETF workgroup or group of
developers can add new headers for middleware).

To provide transport independence, an IETF workgroup (or a group of
developers like for instance, this present group) could define a new header
like for instance "recipient" or "x-recipient". This latter having a URN
value. The URN could be resolved into one or several URLs like for instance
the URL of a HTTP server or the URL of a SMTP server. This implies that a
message like below:

sender: urn:DUNS:364824948
recipient: urn:DUNS:12635948

<my-e-business xmlns=" a URI here ">
<?xml-stylesheet href="mystylesheet.xsl" type="text/xsl" media="screen"?>
... my e-business content....
</my-e-business>

is transformed into the message below if the middleware server gets from its
database that the sender prefer that its business partners responds to it
with e-mail and that its business partner prefer an asynchronous transport
protocol like e-mail. Thus, the message is transformed for transportation by
the middleware server into:

content-type: text/xml
from: martind at netfolder.com
to: xml-dev at ic.ac.uk

<my-e-business xmlns=" a URI here ">
<?xml-stylesheet href="mystylesheet.xsl" type="text/xsl" media="screen"?>
... my e-business content....
</my-e-business>

We just separated the document from the message. The message is still an
internet message based on RFC 822 and extensions. New headers could be
proposed through the IETF mechanism. As you know, IETF requires that at
least two different implementations should be in place for standard
approval. It means that, contrary to the biztalk project where only a
Microsoft server is sufficient, to be called an IETF standard, Microsoft
would have to find an other partner who would do also an implementation. Do
you think it is easy for a monopoly to convince an other player in the
industry to do an implementation knowing that Microsoft is doing one also
and that this partner knows about what are the advantages of competing
against a monopoly :-)))

So , now the implications:
Moving from an internet based messaging system to a biztalk based messaging
system: Is it gaining more freedom from a monopoly?

Where are our interests?

Now, who is interested to work on a document (created from the industry, not
proposed by a monopoly) to specify new internet messaging headers to
transport XML documents. The goal is to have the messaging system
independent of the transport layer (synchronous=HTTP,
asynchronous=SMTP/POP3/IMAP4). This middleware knowing the recipient
prefered transport preferences can translate some message headers into the
right one for transportation. Like for instance changing the "x-recipient"
for the "to: xml-dev at ic.ac.uk" header because the recipient prefers the
email as a comunication mechanism.

Hoops...The workflow server has something to say...what? He just said that
part of the solution he was searching is present in an internet messaging
based system. Why? because the message sender can include its style sheet so
that its contained XML message could be rendered if there is a need to do so
at the receiving point. The scope is resolved with the actual XSLT specs.
The scope is its document.

If nobody is interested to discuss the issue or at least to help create this
document, then let's the monopoly decide for us :-))
Any volunteers ? (of course the final document is co-signed by everybody who
participated to the discussion and the elaboration of the document).

Cheers
Didier PH Martin
mailto:martind at netfolder.com
http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)