[infod-wg] Notes from F2F on 3 October 2005 in Burlington
Susan Malaika
malaika at us.ibm.com
Wed Oct 5 02:03:27 CDT 2005
Summary of Actions:
- Action by 15 Oct 2005: Dieter to fix section 2 of the
specification and make it consistent with section 3.8.1
- Action by 15 Oct 2005: Shailendra to remove body from the the
message header section and to add comments for every attribute
- Action by 15 Oct 2005: Shailendra to describe the two
approaches:
(1) Re-packaging a message at each hop in a new header
(2) Removing the header and adding a new appropriate message
header after transformation
- Action by 15 Oct 2005: Shailendra to put mandatory properties
together in the message structure
- Action by 15 Oct 2005: Shailendra to describe the behavior of
DestinationEPRs and MessageIds in an INFOD system
- Action by 31 Oct 2005: Shailendra and Vijay to justify message
structure and to map to the patterns.
- Action by 31 Oct 2005: Arjun to learn from Shailendra and
Vijay's work.
- Action by 31 Oct 2005: Shailendra to define sequence number,
operationalCharacteristics more clearly
- Action by 31 Oct 2005: Shailendra to reconsider the manifest
name and to give it a name that is consistent with its content
- Action by 31 Oct 2005: Shailendra and Vijay to explain the need
for incorporating information in the INFOD messages to deal with the
integration of SOAP and asynchronous messaging
- Action by 31 Oct 2005: Abdeslem to add a subscriber id to the
create subscription interface
- Action by 31 Oct 2005: Vijay to explore the use of the
subscription interface with the registry manager to notify publishers and
consumers of changes to the contents of the registry manager (e.g.,
changes to subscriptions, changes to publishers, changes to consumers) -
in other words explore the registry manager acting as a publisher
-Action by 31 Oct 2005: Vijay and Shailendra to explore the
message layout for create subscription, etc ...
- Action by 10 Oct 2005: Steve Fisher to revise and place use case
template on GGF WebSite
- Action by 15 Nov 2005: Create use cases in accordance with new
template
Ronny Fehling to create ChS (Chemsecure) use case
Steve Fisher to revise RGMA use case
Stephen Davey to revise media use case
Dieter to revise the car use case
Arjun to revise sensor use case
Susan to revise third party delivery use case
- Action by 15 Dec 2005:
Susan to assemble the use case and pattern document
.......................................................................................................................................................................................................................
Attendees:
Steve Davey, Vijay Dialani, Ronny Fehling, Steve Fisher, Dieter
Gawlick, Susan Malaika, Shailendra Mishra, Shankar Mallikarjun, Aravind
Yalamanchi,
On the phone:
Chris Kantarjiev (part), Cecile Madsen (part)
Dieter introduced the day:
- Shailendra on Message Structure
- Aravind on implementing an INFOD registry
- All on mapping Use Cases to Interfaces
Dieter said we would leave at 5pm to get to the data streams session.
Arjun and Vijay would leave earlier to get to the airport
Shailendra reviewed Section 3.1 (The XML description of a message)
- Observation: section 2 in the specification is not consistent with
section 3.8.1
- Action: Dieter to fix section 2 and make it consistent with section
3.8.1
- Action: Shailendra to remove body from the the message header section
- Selectors are modeled on Java attribute type - name,value
- Discussion: Are these messages used for defining subscriptions and
consumptions as well as the message content? Yes
- Discussion: what is optional?
- Abdeslem Q: How does the message id here tie in with WS-Addressing
message id?
- Steve Fisher Q: What is message length?
- Shailendra R: Message length of body. Message length of header can be
computed
- There are three kinds of message
1. Self-Described (type accompanies the message)
2. Pre-described (the middleware on both sides know hats in the
message)
3. Un-Described (the application understands the message but not
the middleware)
- Much discussion about message id which was deferred until the manifest
discussion later
- Abdeslem urged the review ws-addressing message ids
- We summarised the compulsory items in the message so far
- Length
- MessageID
- Type
- The discussion on message restarted and stopped
- The correlation id is a user defined field whereas the message id is
system assigned
- Ronni: Can use correlation id to filter
- The optional items so far are:
- selectors
- correlationID
- priority : Directive to INFOD middleware
- retry : Directive to INFOD middleware
- senderEPR
- destinationEPR
- sequenceNO
- signature
- encryption
- characterset
- form (char or nchar)
- operationalChar (exactly once recovery)
- userProperty
- flags
- manifest (grows as the nessage moves along)
- Shailendra : SenderEPR and DestinationEPR are useful to achieve
non-repudiation
- Steve Fisher: is destinationEPR the final destination even when targeted
to multiple destinationS? What about if it is goes to a mailing list?
- Shailendra: We've modeled this system on email. So the message first
goes to the mailing list. then it gets split up into multiple messages
with multiple ids and multiple destinations. An alternative can keep
slapping on more headers. We are not inhibiting either approach.
- Action: Shailendra to describe the two approaches (1) Re-pacakaging a
message at each hop in a new header (2) Removing the header and adding a
new appropriate header after transformation
- Shailendra then discussed the originalId. The ID assigned by the creator
of the message
- MessageIds endure for one dissemination hop only. So everytime a message
is forwarded it gets a new MessageId.
- Action: Shailendra to describe the behavior of destinationEPRs and
messageIds in an INFOD system
- There was a discussion about destinationEPR and propagators. The
specification assumes:
- local disseminators (home disseminator) for publishers to target
messages to
- consumers for publishers to target messages to
- local disseminators for subscribers to subscribe to
- local disseminators and POBoxes for consumers to consume
messages from
- Interim disseminators are not covered in the specification. In
other words there is an interim disseminator cloud. At the edges of the
cloud, there are: Publishers, Consumers, Subscribers, POBoxes and Home
Disseminators
- An attempt was made to define a cloud formally. Some compromise between
an email and queuing approach!
- A point was raised to review how correlation affects the flow of a
message through the cloud
************************************************************************************************
We took a lunch break with two sandwiches between 4 vegetarians and lots
of lovely cream cakes. We later had cheese scones for tea.
************************************************************************************************
- Shailendra described the sequence number. There were questions about the
context of the sequence and an action for Shailendra and Vijay to clarify.
- Only things that are preserved as a message moves around are messageId
and the manifest
- Suggestion to move messageID into manifest because the manifest is the
only part of the message that doesn't change
- We then moved on to the message body
Arvind session on registry:
- The registry makes it possible to find publishers that one can
speak to with a common vocabulary with desirable properties
- The registry contains core properties of entity an community
vocabulary
- Constraints include minimal properties of interest to consumers.
- Arvind introduced the Oracle expression data type (which
apparently is patented)
- He described the object-type that's needed with an expression
type (analagous to the Oracle data type)
- The object type can refer to columns in other tables
- The use can supply the expression instance in a query as
name-value pairs
- Constraints on consumers and publishers, and subcription
information can be placed in a registry.
- The purpose of the talk is to explain the use of mutual
filtering through the expression data type.
- There was a lengthy discussion about how to handle vocabularies.
- Consumers can specify constrainsts on subscriptions and on
publishers
- There was a discussion on CREATE Publisher promoting the idea of
not differentiating between INFOD publishers and community publishers.
- There was a discussion about how subscriptions are created. We
took the action of adding a subscriber id to the create subscription
interface
This is the Oracle query that the disseminator or publisher issues
to do the pattern matching to figure whether messages should be published
looks something like this:
SELECT s.INFOD_Data_Constraint,c.* FROM INFODPublisher p, INFODConsumer c,
INFODSubscription s WHERE p.INFOD_Identifier ='CA_FF' and
s.INFOD_DataVocab = 'Car' and
EVALUATE(p.INFOD_PropConstraint_S, s.rowid) = 1) and
EVALUATE(p.INFOD_PropConstraint_P, p.rowid) = 1) and
EVALUATE(p.INFOD_PropConstraint_C, c.rowid) and
EVALUATE(c.INFOD_PropConstraint_S, s.rowid) = 1 and
EVALUATE(c.INFOD_PropConstraint_P, p.rowid) = 1 and
EVALUATE(c.INFOD_PropConstraint_C, c.rowid) = 1
There was a discussion about seeing the impact of adding new publishers
Steve Fisher asked what would happen when a new car was for sale.
Subscriptions already exist. The car dealer assumes that all the queries
have issued and bound.
We moved on to the planning session.
Dieter then outlined the key points of INFOD:
- Distinguishing events from messages
- On Demand Publishing
- POBoxes
- Matching subscribers and consumers through common
vocabularies via the registration manager
These were the main steps we proposed:
Step 1 Focus on basic interfaces (ignoring disseminator,
propagation) - for GGF16
- Focus on section 3 on managers ....
Step 2 Layer on WSN
Step 3 Add extra functionality
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20051005/ebbdced1/attachment.htm
More information about the infod-wg
mailing list