--On April 23, 2007 2:21:46 PM -0700 Qin Zhang <[EMAIL PROTECTED]> wrote:
OK, in case of REST, the most important thing is to specify service call
contracts, be it an xsd schema file or some other mechanism. Since
Hackystat is moving to a service oriented architecture, I guess one thing
to avoid is to be too java centric (e.g. using sensorshell.jar inside
.net client). Have you thought about how other language might be bound to
the service?
One thing that's good about moving to REST is that inter-service
communication is much more language and technology independent; you don't
even need a SOAP/WSDL library, all you need is HTTP. So, moving to REST is
a big leap away from the admitted Java centricity of Version 7. For
example, in Version 8, it will be just as easy to write an Analysis service
in C# as it would be to write it in Java. This is not the case in Version
7.
In the case of the SensorShell, I see the following:
- The SensorShell will no longer provide client-side SDT verification, or
the client-side "convenience" functions for a specific SDT. This is
because there will no longer be a programmatic definition of an SDT in
terms of a "wrapper class". In this sense, the sensorshell is less "java
centric".
- The SensorShell will continue to provide client-side offline storage,
buffering of data, interpretation of the sensor.properties file, and
logging.
I think the net of it (the .NET of it? :) is that in Version 8, it will be
much, much easier to write a sensor that communicates directly with the
SensorBase without going through the SensorShell, and we will probably
start to see sensors implemented that way. On the other hand, some tools
will still decide to use the SensorShell in order to take advantage of
storage, buffering, sensor.properties, and logging.
Cheers,
Philp
