Proposed meeting at HUH Friday Sep 2008 11 am-3 pm
Agenda (too much)
- Do current message abstractions at FP_Messages adequately cover the use cases at Use cases?
- Can current message abstractions be implemented in the proposed message schema at File:Message.xsd?
- Are the message abstractions and schema sufficiently abstract as to be independent of Hadoop as platform?
- Are the interfaces implied at Prototype design general enough to be (a)independent of network platform and (b)ready for specification as Java interfaces?
Began with #1 and #2: message schema. Abstraction of MessageT containing a Body element and some concrete typed message body seems appropriate and able to extend to the multiple FP_Message types without severe constraints on implementation (and with potential RDF compatability).
Header itself is problematic in both Specification of Destination and Specification of Sender.
Specification of Destination
Several models were discussed, including: 1) send to specified recipient, where specified recipient is a network node or specified recipient is entire network. 2) Query the network to identify Interested subscribers, include them in the destination header, 3) Publish-subscribe where information needed to identify interested subscribers is included in the header, but the actual subscribers aren't itemized in the header, or 4) publish-subscribe where the message header doesn't include any destination routing information and the receiving API node examines the message body to match the message to subscribers.
Substantial discussion around including destination in header or examining body to infer destination (which could also be explicitly specified in body element). Potential scaling implications of publish-subscribe would want to limit the list of subscribers to a shorter list of something reasonable rather than each herbarium sheet being a subscriber. Potentially heiarchical handling in a cascade. Discussion of rules for the handling of a message by a network node when it can't interpret the body. Discussion of similarities to depth of inspection of schema agreement in the UMB work on data privacy for NatureServe. Discussion of similarity to deep packet inspection by malware scanners.
Conclusion seemed to be that examination of body provides the fewest limitations on addressing by the message design, the fewest limitations on implementations of the client API, and best allows hiding network internals (such as finding and addressing subscribers) from the clients.
Specification of Sender
Specification of sender: Problematic use case, James and Rich both inject FP annotation messages using a Morphbank FP client. How does morphbank know how to handle a response, do they send it to James or Rich.
Requirement: Asynchronous messaging (or perhaps that should be, there is no requirement for Synchronous messaging).
Proposed: publication-subscription model where the client specifies the response address information.
Analogy with JMS Request-Reply, Requestor=client, replier=FP Node API.
Requestor, the client needs to specify a service endpoint to reply to a message - end point of a chain of processing.
Message Header Reply Requirements Failure Handling Requirements Client provided "In Response to this do" Body Concrete Body
Node api adds wrapper with timestamp, messageid, recievedfromnode, etc, examines Body and determines the appropriate recipient(s). Producing something like the following where the wrapper's Internal Header and Destination Address elements are purely examples of some of the sorts of information that the Node API might add on receiving a FP_Message.
FP Network Internal Message Internal Header Recieved By Node Recieved from client Recieved at timestamp NetworkMessageID Message Header Reply Requirements Failure Handling Requirements Client provided "In Response to this do" Body Concrete Body Destination Address Send to Reply to
Examine 18th, 19th century British banking messaging protcols for letters of credit and introduction and similar social protocols (including agents, clarks, butlers etc).
For #3, probably.
For #4, need to look more closely at implementation independence.