RE: Bindings : a quick cut at an abstract definition

All, 

I have compared Glen's abstract approach with my "proposed sections"
approach.  It seems that my detailed sections are what is missing from 3, at
least in part.


>>1. A name (URI) for the binding

concept from our binding framework approach. Not covered in my sections.

>>2. A specification of the binding's "private" facets. 

An example would be a specific use of MDN's as receipt acknowledgements,
which could include SOAP content as part of the returning MDN.  
Am I correct in assuming that unique usages/behaviors of features listed
under (3) would be captured here, as well?

>>3. A specification of the binding's "public" SOAP facets.

MEP - Message Exchange Patterns Supported
Message Addressing
Message Correlation
SOAP Encapsulation - MIME, etc
Compression
Security 

Reliable Messaging
	Sending Message Behavior
	Receiving Message Behavior
	Generating an Acknowledgement Message
	Resending Lost Messages and Duplicate Filtering 
	Duplicate Message Handling
	Failed Message Delivery
	Message Order Preservation
	Message Delivery/Failure Notification
	Split Messages

Error Reporting and Handling
	Error Types (Bound Protocol Delivery) and Handling
	SOAP Fault Types and Handling
	Reporting Errors


Regarding the "Distillation of Sorts" thread:

>We can pick operational semantics and define them in terms of named
>components, pieces of data, and communication patterns.  

To map this to my binding outline, am I correct in making these comparisons:


1)Named components are analogous to features (like security, compression,
correlation)
2)Pieces of data would be the meta data or infoset data associated with
these features
3)Communication patterns are message exchange patterns (?)


Thoughts?  Shall we discuss this at today's TBTF?

Highland

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@macromedia.com]
Sent: Monday, July 30, 2001 4:51 AM
To: xml-dist-app@w3.org
Subject: Bindings : a quick cut at an abstract definition


This is a quick take at what a high-level "binding" abstraction might
look like.  I start off by presenting a little context, then take a
stab at a (very small) abstract binding framework.

A couple of things to note first:

The message infoset is an entirely abstract notion, and the actual
representation of the infoset in memory or on the wire is entirely up to
the application.  An example: we may define an infoset item which
indicates that a given message is an RPC request.  One possible
implementation might actually insert a block into the message which
carries this information.  Another implementation may implicitly "know"
that this information is "virtually" in the message by virtue of the
fact that an API such as "call(method, arguments)" was invoked in the
execution path.

To send or receive a SOAP message, a binding must be selected.  Therefore,
it seems likely that the binding name itself is an item in the message's
infoset.

Bindings supply "facets".  Some of these facets may be entirely internal
to the binding in question, and in this case they do not need to be
specified in any particular way.  Some facets, however, may be expressed
in terms of the message infoset - doing this allows the definition of
concepts that are shared or referenced across multiple bindings or other
extensions.

OK, so a proposal for a binding framework might look as simple as this:

A binding should include:

1. A name (URI) for the binding

2. A specification of the binding's "private" facets.  This would be
any binding features/behaviors which do not have a well-defined
normative representation in the SOAP infoset, but still must be
clearly specified so that multiple implementations of the binding may
interoperate.  An example might be "this binding uses TCP port 4999".

3. A specification of the binding's "public" SOAP facets.  These would
be descriptions of how the binding generates, consumes, or in some
other way relates to particular normatively defined pieces of the
message infoset or other extensions/bindings.  This might include
message exchange patterns, security, or anything else that has been
defined by the WG or by extension writers.

... and that might be it.

I am still unsure about how to characterize the difference between
"encapsulation" bindings and "transport" bindings, and so have left this
intentionally vague in that respect.

Item 3 certainly could/should be expanded into more detail.  I also
note that it seems to me that the difference between a binding and
any other SOAP extension becomes somewhat unclear if we head down this
road - bindings, I think, are the only extensions allowed to specify
"private" patterns as in item 2, but aside from that it's very similar.
This may be a good thing or not.

Glen Daniels
Macromedia
http://www.macromedia.com/
                                Building cool stuff for web developers

Received on Monday, 30 July 2001 13:09:04 UTC