Nick Gall's Weblog
[NOTE: I have moved. My new blog is ironick.typepad.com.]
        

Nick Gall's Weblog

Friday, September 26, 2003

JBI Deals With the Heteregenous Network.
Continuing discussion of Java Business Integration (JBI - JSR 208) and related issues. See my previous comment on JBI. See also the comment thread re the JBI post at Collaxa. I just commented on Carlos' post and I am reposting my comments here:

Carlos, I completely disagree with your analysis. It is only when the network becomes more homogeneous that we make major progress due to the "network effect." Your expectation of the inevitability of network heterogeneity sounded a lot more convincing ten or so years ago -- BEFORE the Internet effectively displaced ALL OTHER internetworking protocols. If network heterogeneity is inevitable, then how did that happen? The same displacement and resulting homogeneity is evident one level up in the Web's universality (HTTP/HTML). HTTP/HTML displaced all other remote-GUI network technologies: Compuserve, AOL, Telnet, Gopher. How did that homogeneity happen. In general, although network homogeneity does take a long time, it does eventually happen. Look at the email network, which settled on SMTP. Or outside of IT, look at the intermodal shipping container, which finally enabled interoperability across the shipping industry.

Web services is simply the attempt to extend the homogeneity of the Internet and the Web even further, and from everything I see, it is succeeding. In my experience, it generally takes five years for a new technology to break though to the 80% use rate. Look at XML. It was ratified in 1998 and it went big this year. That is, it is now in production in 80% of Global 2000 organizations. Also, to say that Web services' interoperability limitations, which are being reduced over time through efforts like WS-I, mean that it has "failed" is like saying HTML has failed due to its interoperability limitations

All that said, there is a role for heterogeneity in the network. Just as the Internet is a set of internetworking protocols (i.e., the Internet standards define no layer one or two protocols) for enabling binary packet interoperation across heterogeneous networks (e.g., Ethernet, ATM, Dialup, Frame Relay), so too Web services is set of internetworking protocols for enabling typed XML Infoset interoperation across heterogeneous transports (e.g., HTTP, MQ Series, SMTP). But if Web services does not succeed, then we are not going to make much progress. I think the major vendors (including Microsoft) all get this, which is why they are so far resisting the urge to fork the core Web services standards.

One thing I know for sure, as hard as homogeneity is in the network, it is impossible (and a very bad thing) at the end points. That is the fatal flaw in the Java vision – that all endpoints should run one homogeneous software model. That is NEVER going to happen, nor should it happen. It is at the endpoint that you want lots of experimentation and innovation.

So while I applaud the JBI JSR, it is akin to ratifying a Winsock or Berkeley Sockets standard API – very useful – but not nearly as essential as the network protocols they drive.


9:16:11 AM      

Wednesday, September 24, 2003

Impedance mismatch in Development.
John McDowall posts:

The problem is not the programming language but rather the infrastructure we have built. To create an application that takes a string as input through a web form and then stores it in persistently a developer must know a wide range of technologies. This is true no matter which particular approach they use. If I use Java it is HTML/JSP/Servlets/Java/JDBC/SQL at a minimum if I use another approach the stack is similar (HTML/PHP/CGI/Perl/DBI/SQL). The number of transformations the simple string goes through from the web page to the database is significant. The impedance mismatch comes from the need to translate amongst datatypes. If it is a real world problem with complex types the problem quickly becomes hard.

...

While XML has its own set of issues it does reduce the impedence [sic] issue if an XML datastore is used. There are still several technologies in play but one data format. (XHTML/XSLT/XML/REST/XML-Store) - are we better off?

If you're interested in one XML-based framework/language end to end, check out the Water programming language. A SearchWebServices interview discussing Water and its approach to the multilanguage complexity issue and the Water approach is available. I've been following Mike Plusch and Water for awhile. It is definitely interesting technology. Question is, can it have an impact in a language saturated world?


7:25:31 AM      

Monday, September 22, 2003

Stunting a Framework.
Ian Rae has an interesting observation on frameworks in this comment thread on Michael Feather's post, Stunting a Framework:

There are two forces pulling on a framework. From above there is feature creep pulling the framework into a larger and larger scope. From below there are portability issues pulling the framework into creating infrastructure.

Sound familiar. The old spanning layer issue. The key here, which the other comments hint at in their mention of "pattterns," is to base the "framework" on a simple set of identifiers, formats, and protocols that can be used for a wide variety of applications and bound to a wide variety of implementations. This is why the emerging Web Services framework is the right approach.


5:01:22 AM      

Sun has no clue, er, strategy, regarding Linux.
Robert Scoble's post re Don Box's post led me to this gem of ignorance and arrogance.
4:35:40 AM      



© Copyright 2006 Nicholas Gall. Click here to send an email to the editor of this weblog.
Last update: 9/21/2006; 6:14:12 AM.