Keith Harrison-Broninski wrote: > > > 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.
The thing is that people ARE inventing syntax with more and more semantic richness. > 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. Don't get me wrong! I'm not actually saying that RMI/Java is the right answer everywhere. I'm saying that there is power in Java's mobile code model that most SOA architects are ignoring. I'm not sure why, except there's probably some ignorance involved, but also just the normal "political correctness" mantra that flows through the less experienced/inexperienced developers and architects. > 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. Right, so Java and the mobile code model doesn't keep you from doing this. If you are using Java, you can use Jini for your infrastructure and management of the related Java systems. To talk to non-java applications, you can "plug-in" an appropriate endpoint/invocation layer that speaks the wire protocol you need. > 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. Well, there is a degree of explicitness that is required. For example, the Java serialization process is explicit enough to allow for completely unambiguous transport from VM to VM. The issues are about lack standardization of typing of native/basic values. At some point, I do believe that everyone will look around at the mess and say, as the Java designer(s) did, if we just fix the types to specific values, everything becomes trivial. It's that virtualization of representation that provides the equalization. > 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. Well, I'm not so sure that it will be a "re-invented" Jini. But, all of the features of Jini will eventually be reinvented/included because they are what's required. > 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. The ignorance of real solutions and the blind invention of new solutions is quite distressing isn't it. > 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? Arbitrary, uncontrolled or unspecified knowledge is what creates job security. This is nothing new in our industry. The next step will be standardization of data types with formal semantics. We've talked about do that in the Jini community for years. The problem is getting people to be willing to buy in to formal specification of simple things. Gregg Wonderly
