Sponsored Link •
|
Summary
I've been an active user of Jini and Java for the life of these platforms. The distruption that Web Services is causing in the software industry is amazing. Is this an investment for good, or a cost that we'll wish we'd skipped?
Advertisement
|
In a recent service-orientated-architecture yahoo group posting, there was this text
Robin wrote: > But there is a more fundamental thought. Java, C# are not XML, these > languages are object oriented and you will likely use internal object > models in your implementation. You will have to map your XML to > objects. > On the other side of the service, you will likely use a relational > database. Guess what, Java, C# are not relational minded either. You > will end up with a mapping between the Java code and the database too.What is most disturbing about this issue, to me, is the fact that the primary focus for web services is to use so many impedence dependent tools to solve a problem that is more easily solved without such tools. The problem is not an impedence problem. I think it's a wrong tool problem.
Everyone seems dead set on investing in XML to create an impedence match at the network level. The problem is that it is creating huge impedence mismatches with programming languages that are being patched from all directions.
Don't get me wrong, I am not against using XML where it makes sense. I'm just wondering if we are going after the right solution. For unrelated IT infrastructures, selecting a common transport that is easily mapped to standards makes sense. So, all of the new "business" relationships that the internet is allowing, can perhaps benefit from using XML document exchange. But, is that the only solution for distributed communications. And/or is this just what is visible in the industry press and people are doing lots of other things besides XML.
I'm using Java Serialization through Jini based RMI style RPC. Of course their is no impedence mismatch for object to object calls. JERI lets you plug in an alternate transport, so technically you can talk from Jini in Java to some other language environment, including XML web services. I don't do this, but others do.
Java's dynamic code downloading and associated late bindings make it really powerful and easy to create powerful RPC based applications using whatever level of granularity you need. If you need to send large amounts of data, you can use a smart proxy to stream data under the covers and then hand it to the client with a object representation if needed. You can turn a stream into an SQL result set etc. There's also the ability to join multiple services into a new, single API at the client so that you don't have to change the services, you can just deploy a smartproxy as a new service that coalesces multiple services of differing granularaties.
What's everyone else doing to manage distributed communications infrastructure?
If you could have a new tool to solve a problem you're having with developing your distributed application what would it do?
Have an opinion? Readers have already posted 22 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.
Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments. |
Sponsored Links
|