I sympathize with your views, Gregg.
I use Java for most of my own development work. I am also a long-time
Jini fan, and support your efforts to proselytize it. Finally, I think
XML is a very poor language, being essentially a _syntax_ developed from
a convenience technique for use by publishers (SGML). XML has no true
_semantics_ - which is the heart of the problem, isn't it.
Like it or not, the world hasn't settled on RMI, of any other technique
designed for _object_ exchange. Rather, XML-over-HTTP in some form,
whether you use REST, SOAP, XML-RPC, ATOM, RSS or anything else to
achieve this, has become the de facto standard for _data_ exchange.
So a computer program consuming services needs to construct XML data for
parameters and make sense of XML data received back, which means mapping
program objects to and from XML text. And for complex objects, an XML
schema or DTD does not provide enough information to do this - there are
many possible mappings each way.
The object-XML mapping problem is analogous to the (more
well-recognized) object-relational mapping problem. And in both cases,
there is no magic bullet - no unambiguous way to do the mapping, which
means there is no algorithm for achieving it without human involvement.
Developers still have to mess around configuring property files at both
provider and consumer ends.
So I agree Jini would have been a better solution. But unfortunately I
don't share your optimism (if this is the right word) that XML will
gradually become a re-invented Jini. I don't think this is possible,
for the reasons given above.
It's an unholy mess. It would have been bad enough if services
exchanged relational data between provider and consumer - at least then
we'd have only one horrendous mapping problem. As it is, we have two,
and no prospect of either problem going away.
And to my mind, the XML mapping problem does pull the rug from under the
feet of many widely-touted claims for SOA. How can providers and
consumers be truly independent if they have to share object declarations
not found in a service definition - i.e., share a code base?
--
All the best
Keith
http://keith.harrison-broninski.info
Gregg Wonderly wrote:
Keith Harrison-Broninski wrote:
> But what client technologies allow you to call services from anywhere,
> without access to the producer's code base, and utilize
programmatically
> the complex objects that are returned?
>
> I have asked exactly this question before to this group
>
<http://tech.groups.yahoo.com/group/service-orientated-architecture/message/2400
<http://tech.groups.yahoo.com/group/service-orientated-architecture/message/2400>>,
> since I have been looking for solutions since 2001. And the _only_
> practical suggestion I got was from Aleksander Slominski, whose XSUL
> project <http://www.extreme.indiana.edu/xgws/xsul/
<http://www.extreme.indiana.edu/xgws/xsul/>> includes a "Super
> Dynamic Invoker" (based on WSIF, which I also used in an earlier
attempt
> to deal with the problem).
But, as you know Keith, mobile code platforms such as Java make this
trivial to
do. It's only because you are demanding that the client and server be
completely arbitrary that you can't utilize the simplicity of mobile
code to
just share the interfaces.
There are so many places in XML where more semantics are being
defined, at some
point, there will probably be a very refined expression language for
math as
well as a logic language for control (there are fragments everywhere)
that is
universal. At that point, I'll throw my hands up and ask "why didn't
we just
pick Java instead of reinventing everything?"
Gregg Wonderly
