Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Embrase.. Expand.. Extint..
 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@n... to: xml-dev@i... ....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@n... to: xml-dev@i... ... 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@n... to: xml-dev@i... <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@i..." 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@n... http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
