In HTTP, the self-description is the MIME type declared in the HTTP header.
Standard MIME types (i.e., registered types) describe the type of content
(image, text, XML, etc), but they typically don't provide semantic
information, such as what's in the image, what's in the text, or what's in
the XML.

As I indicated in an earlier response to this message, I argue that the
qualified name of the root element in a SOAP Body is a much more descriptive
self-description than a MIME type.

You can create your own MIME types, and in fact define a MIME type for an
OASIS UBL document or a private schema negotiated out of band. I haven't
looked it up, but I'd guess that EDI standard documents are, in fact,
registered MIME types.

The probelm with creating your own MIME types is that standard web clients
don't know how to process them. One of the main reasons why the Web works is
that MIME types are standardized, and all web clients know what to do when
they get a JPEG in response to a GET. But what are they supposed to do with
a privately defined MIME type?

Anne

On 2/26/07, Dennis Djenfer <[EMAIL PROTECTED]> wrote:

   Jan Algermissen wrote:


 On 25.02.2007, at 22:55, Eric Newcomer wrote:

 Jan,

In that case I would expect WebSphere MQ to be compatible with the Web
since it has a uniform interface. Correct?


 Messaging systems have a uniform interface[1], yes. I am not sure what
you mean by 'compatible' though. Messaging systems are a different kind of
architectural style than the Style of the Web is. Following one of REST's
constraints doesn't make a style the REST style. The Pipe and Filter style (
e.g. Unix shells) for example employes a uniform interface, too. But that
style is not the Web style either.

 Do massaging systems constrain the messages to be self descriptive (do
they require the payload to be of standardized formats)? Message
self-descriptiveness is also one of the very important one of REST's
constraints.

  Hi Jan,

It seems like you're saying that a message is self descriptive if it's
standardized, right?

I'm curiouse about your defintion of a self-descriptive message:
Is an order message that follows a schema that has been defined by OASIS
UBL self-descriptive?
Is an order message that follows a schema that has been negotiated out-of
band between many organizations in a specific business domain
self-descriptive?
Is an order message that follows a schema that has been negotiated out-of
band between two organizations self-descriptive?
Is an EDI message that follows a structure that has been defined by an EDI
standard organization self-descriptive?


// Dennis

 Jan


 [1] You can of course also abuse those to tunnel commands




Eric
 ----- Original Message ----
From: Jan Algermissen <[EMAIL PROTECTED]>
To: [email protected]
Sent: Sunday, February 25, 2007 2:53:27 PM
Subject: Re: [service-orientated-architecture] SOA Pizza Order Surprises


 Eric,

 your posting 'deserves' a more detailed reply, so sorry for only sending
a short comment (I still have a pile of work on my desk for tonight).
 On 25.02.2007, at 18:23, Eric Newcomer wrote:

It is just hard to believe that the lack of uniform interfaces in SOAP and
WSDL is the cause of all the disconnect with the Web.


 The lack of a uniform interface (the plural doesn't really make sense
here, does it?) is contrary to the architectural style of the Web. That is
just an undebatable
fact. An architecture that does not employ a uniform interface can never
be of the REST style and an architecture that does not specifically
constrain itself to
HTTP's set of methods on all objects is necessarily disconnected from the
Web.

 Jan


 (And, yes, GET /foo/lauchMissile is not HTTP's GET, it is tunneling the
launchMissile invocation through GET)





------------------------------
Bored stiff? <http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.com> Loosen
up...
Download and play hundreds of games for 
free<http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.com>
 on Yahoo! Games.


 ------------------------------

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.4/702 - Release Date: 2007-02-25 15:16


Reply via email to