| [hyades-dev] Data Collection protocol -- performance concerns and suggestions |
|
I have concerns about introducing too much XML parsing into the DCE protocol. I'd like to keep things as streamlined as possible so that the DCE will remain fast and light, while at the same time adding flexibility and extensibility. On the other hand, I recognize the need of some components to have WSDL support.
At the base level implementation, rather than require components to completely describe their supported command sets, I would like to see us use something based on defined interfaces. In this case, the client would be able to determine at run-time whether or not a component supports a given interface. Once the client and a component agreed on an interface, the client would send commands (and get responses) whose format depended on the commonly-known definition of that interface.
I would imagine that communication between agents would be substantially similar to communications between the client and the DCE.
For performance reasons, I would like to see common interfaces be very simple, requiring minimal processing. All messages would need to have a common stub to be used for routing by the DCE. Beyond the details of the interface could be customized to meet the specific needs involved. If the client is more performance oriented, the interface would be in a binary format. Is it possible to meet the needs of WSDL-seeking clients by layering something on top of a simple binary interface?
Also for performance reasons, I would like there to be some way for the client and the server to negotiate communication format issues such as ASCII/EBCDIC and big-endian/little-endian so that the necessary reformatting can be minimized.
What I'm proposing is quite similar to the existing DCE protocol, but it would be extensible (via new interfaces). This similarity to the current protocol would allow much of the existing client code to be reused.
I was picturing a command format something like this:
Header ID -- (identifies the format of the header, in case we want to change it in the future) Target -- (a unique identifier that the DCE would use to rout the message) Target Host -- (allows for communication between agents of different systems) Source -- (will later become the target if the message requires a response) Source Host -- (again, communication across peer DCEs) Interface ID -- (tells the object receiving the message what the command ID means) Command ID -- (identifies the command to be invoked) Context -- (as currently, used to correlate commands with their responses) Data Size -- (tells the DCE how big the command-specific data block will be) Data -- (command-specific data)
This is just a rough sketch and is probably missing a lot of things.
The interface ID here needs to uniquely identify the interface at run time. I was thinking we could get unique IDs using something like the Java class naming scheme (e.g. "org.eclipse.hyades.dce.agent"), but because we wouldn't want to have to do a bunch of string compares for every message, I thought maybe the DCE could provide a service to translate a string ID into a run-specific unique integer (kind of like Windows' RegisterWindowMessage function).
The command ID would be an interface-specific constant. The object receiving the message would use the interface ID and the command ID to determine what the contents of the data block would be. For performance critical interfaces, the data would map to a structure. In other cases, it could be an XML block.
I would imagine that the mechanism of the header block could be made completely transparent to Java agents, which could receive an XML data block as if it were the entire content of the message. |