I like this general idea. I have been becoming more and more concerned
that doing everything through moving code around is, in several ways, a
problem rather than an advantage.
I see the movable code idea as being most powerful for providing
versions of services that reduce communication cost by doing more work
on the client. That could be done in parallel with basic versions of the
same services that do not require code movement.
For many issues, such as negotiating trust, finding suitable services,
and performing basic operations in a simple way, it seems to me to be a
hindrance.
Patricia
Dan Creswell wrote:
...
On 14 February 2011 12:41, Sim IJskes - QCG <s...@qcg.nl> wrote:
On 14-02-11 13:22, Dan Creswell wrote:
Android and the consequences is one angle certainly. I was thinking
something maybe a bit more sacred like:
All services exposed via REST and dynamically discovered (properly as
opposed to the more traditional definition of dynamic discovery used for
the
web which involves having a specific URL to start from and some feed or
another to parse).
If one goes wholly REST the idea of movable code everywhere is less
relevant
though not eliminated (it's still an attractive proposition for certain
platforms/environments).
REST, big leap, lets try. Are you talking about dictionary based exchange
of parameters and result? Textual (or value) data is easy serialized, but
how about references to exposed services. Serialize by url?
Sure, could be JSON or XML (shudder) for parameters (although not everything
has to be considered a parameter - how about streams of data and such?)
Serialize by URL? Probably - certainly have to express contact details and
this is one way to do it. DNS or similar is also somewhat possible with SRV
records and such.
What do we validate on going from dynamic structures to statically typed?
Can you say more about this one - not sure what you're asking.....
Closest I can get is that service and client must understand each others
contract. They may or may not bother with enforcement of such a contract and
thus they may or may not validate.
Do you envision a multi language/platform solution here?
I certainly envision multiple platforms. Multi-language kind of falls out as
a gimme, once one drops away the requirement for movable code. As I said
elsewhere, that doesn't mean movable code cannot still be used. No reason
one couldn't build such a layer in front of REST services if that's "nicer"
in various cases.
