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.