Скачать презентацию Apps Messaging Issues IVOA Beijing Interop May 15 Скачать презентацию Apps Messaging Issues IVOA Beijing Interop May 15

cb2aa8ad8bab19790c8e97d0a0ad9af9.ppt

  • Количество слайдов: 8

Apps Messaging Issues IVOA Beijing Interop May 15 -16, 2007 Apps Messaging Issues IVOA Beijing Interop May 15 -16, 2007

Message Concept n Message Classes n NOTIFY n n REQUEST n n Request action Message Concept n Message Classes n NOTIFY n n REQUEST n n Request action from another app, rejection OK (e. g. load. From. Url) REPLY n n Informational, no response/confirmation (e. g. app (dis)connected, logging, etc) Returns status code or result of a REQUEST Msgs have attributes defining the meaning, some required, some optional IVOA Beijing Interop, May 16 -17, 2007

Message Attributes n Sender n n By Name or ID? Recipient n n By Message Attributes n Sender n n By Name or ID? Recipient n n By Name or ID? (Hub is a well-known name) Filter mechanism n n Subscription group Advertised capability General broadcast Message ID n n Permits async response No harm to synchronous messaging model IVOA Beijing Interop, May 16 -17, 2007

Message Attributes n Reference ID n n Mtype n n n Receiving app assigns Message Attributes n Reference ID n n Mtype n n n Receiving app assigns to object it creates for later reference (e. g. a table subset, intermediate filename). Allows sender app to refer back to that in a later message Acknowledged as generalization, but no consensus on priority UCD-like string giving message meaning Replaces PLASTIC ivorns IVOA Beijing Interop, May 16 -17, 2007

mtype Explained n UCD structure creates message classes n n Image display (display. image), mtype Explained n UCD structure creates message classes n n Image display (display. image), table operations (load. table), administrative (get. icon, reply. status), etc Specify core set of mtypes that describe existing app functionality, allow apps to create “private” mtypes as needed. E. g. n n display. image. frame Core (controlled) mtype class Subtype used by convention App-specific message Intended to map easily to existing Plastic ivorns for backward compatibility IVOA Beijing Interop, May 16 -17, 2007

Issues n In-line data n n Task invocation n n Protocol a minefield, but Issues n In-line data n n Task invocation n n Protocol a minefield, but have current use cases (can we solve with appropriate mtype classes? ) Legacy environment support n n Message carrying a payload of data (complicates? ) XML-RPC+Other gives us options Exploiting specific (negotiated) capabilities between apps n Don’t want to hinder collaborations between developers IVOA Beijing Interop, May 16 -17, 2007

Issues n Messaging Models n n n n n Current Plastic assumes GUI, what Issues n Messaging Models n n n n n Current Plastic assumes GUI, what about distributedapplications model? Future inter-desktop messages? Pub-Sub message model P 2 P vs Broadcast delivery Sync vs Async or Both Message groups Multiple instances of an application Failure modes and Error handling User-configurable message handlers What level of security is practical to implement? IVOA Beijing Interop, May 16 -17, 2007

Issues n Missing from mailing list discussions: n The HUB n n n Client Issues n Missing from mailing list discussions: n The HUB n n n Client API n n General agreement on concept (and name) No discussion of what it really does in SAMP Actually a definition of Hub interface, e. g. we describe the Send() method but in the spec we must describe the conversation with the Hub, e. g. send() returns a message. ID even if final client API doesn’t show it to the user Language-neutral interface description What is keeping groups from Plastic adoption now? Does new proposal satisfy current apps providers? Are they willing to change? Will be buy new friends with it? IVOA Beijing Interop, May 16 -17, 2007