Wednesday, September 29, 2004

SOA Network

The article discusses the requirements for the underlying network for SOA to function according to it's claims. While the author has mostly borrowed from existing white papers, there are a few nuggets of gold in there. Here are my thoughts on a few points the author made.

...."An SOA is a business process-driven application integration architecture in which all functions, activities and actions are defined as services and use standards-based interfaces."

This gets to the core of what a SOA network is all about. Business processes are driven by events and the SOA network likewise has to be driven by events and not just traffic patterns and traffic engineering as is today's network. Pub/Sub event distribution model is more suitable for a small installation but for any size of installation worthy of the name "network", this model is not totally not suitable.

The missing link in today's network's readines for SOA is scalable event propagation to entities on the network and the ability to resolve among those entities. Once this is done, the bit about securely and reliably sending messages is straight forward processing and thanks for web service enabled standards, quite interoperable.

.... "But in the end, the SOA's business benefits will outweigh the cost of implementation. "

Amen to that.

Saturday, September 25, 2004

Application Networks

The PSTN is the world largest network dedicated to one application i.e. telephony. It works really well, has great QoS and costs a few cents/minute. It has a great business model that supports around $800B dollar industry and employs a few million people around the world.

Look at another network the internet. Supports millions of applications none of which have any QoS, costs a bundle, Does not have a business model that works and employs well in tens of thousands.

Is something wrong here?

Wednesday, August 11, 2004

Role of the App Server

Somebody ones wrote "To design is to fit form into a context". Of course, here is the valley, we have been fitting "form into a function".

In the web services world, while designing the SOA, we are ones again fitting a form into a function instead of the context. The context of application servers was just that "Servers". The context of SOA is not a server, but the network. Ones vendors realize that we will actually have an SOA solution that does not cost a arm and a leg.

Saturday, July 31, 2004

Don't use Redhat Enterprise Linux, Use Fedora

This new RHEL from Redhat is a pretty much as proprietary as Window XP.

I can't seem to find any binary packages around and after doing research, I found there are none available like they used to be RH 9.0. Yes, they have SRPMs available, but who wants to compile everything from glibc to libGL. Even Microsoft gives the compiled versions of the libraries for free, no so with Redhat. h

Looks like Fedora is the real open source Redhat OS. Use Fedora!

Wednesday, May 05, 2004

Time for Java OS?

Imagine if code was written an appropriate level of abstraction such that it contained no platform dependencies. In such an scenario, the code could pick and choose at run time the platform it prefers to run on. This choice can be dictated by multiple factors including the enterprise policy. This scenario is like your cell phone call being routed through any network available based on existing arrangement and cost to the service provider. As a consumer you don't care how it is routed as long as it is routed and not dropped.

In such a scenario, what choices would the code want to be offered? Certainly not Windows or Solaris or Linux. It is going to be .NET or Java. The code would expect these two frameworks to interpret the high level declarations in the code and compile it into binaries that are appropriate for the underlying platform.

The point is the code couldn't care less if the system has solaris or linus or windows. All the code cares for is it is given a filesystem to store data, a communication system to send/receive messages and a visual system to display its output or take input. It would like to carry out all these transactions in a secure fashion and if not, it would like to be told that.

So why is Java still be released as a SDK? Isn't it time for Java OS? If you look at JDK, it uses the underlying OSes filesystem, communication system, security system and visual system. In an interoperable world, these would become run-time options for the code.

What has changed is the "S" in the OS. It used to be one system now it is a datacenter system.

Friday, April 16, 2004

Brower based apps and Longhorn

Adam Bosworth writes about browser based apps on his blog. Here is my response.


You caution the world on possbility of Microsoft taking the applications back to the desktop away from the browser. I feel your argument is as valid as some hardware designed skimping of memory because in the old days memory was expensive.

The compelling reason for deploying browser based applications was that such applications are cheaper and easier to maintain thereby saving the enterprise money etc. That was the desktop centric argument. Then came mobile computing and that reasoning was further strengthened because we now have multiplicity of devices.

Those compelling reasons are no longer valid in today's world of falling cost of semi-conductors, software and services i.e. global deflation.

The clients side mobile or desktop is getting richer, cheaper and ubiquitous without sacrificing variety. If the application is not able to exploit this, the application is not worthy of deployment. While you may argue that browser based application lower the cost of deployment and will therefore be deployed not matter what, think again, because the global economics is showing that cost cutting is not the dominant framework but productivity enhance is.

The pendulam had swung too far into the browser based apps domain and I hope Microsoft bring it back to the desktop domain a little for those of us who hate to use browser based applications because of it very unproductive UI.

Thursday, April 15, 2004

Jini and Jxta and Grid Services

So I keep getting asked why not use Jini for grid discovery and Jxta for network independence in grids. Most of the folks who asks actually are not able to tell me what is the distinction between Jini and Jxta. Anybody have a real simple way of explaining? I will give it a try below

Jini is a technology for communication in a distributed computing environment. At the time it was formulated, platform independence was all the craze and thus Jini was born to essentially make RPC platform dependent. But like Java platform it is dependent on the Java language. Like RPC, I believe Jini's communication model is synchronous. The new JavaSpaces builds on top to give a shared memory asynchronous model for communication.

Jxta is a technology for extending distributed computing across a WAN which by definition is heterogeneous. Therefore Jxta involves network protocol routing and is based on asynchronous communication. The problem I see is that it does not use existing IP infrastructure for addressing and therefore not very scalable.

If doing a global grid, I would just move to globus. It solves most of these issues and has a wider following.

Tuesday, April 13, 2004

.NET getting complex

The more I see Microsoft and its .NET today, the more I am reminded of Sun during the early days of Java.

Not a week goes by that Microsoft and its .NET team don't announce a great new WS_* standard or a library or platform for .NET. Just like the early days of Java most of the stuff is quite complex and more likely to be preached by evangelists rather than implemented by developers. Portions of Java that were widely adopted are a very small subset of all the packages that one has to download to get the SDK. I feel the same fate is destined for .NET. Eventually, it will become another souped up web server with server side application execution technology (Java's Servlet). Of course, there will be lots of books, mugs, t-shirts and those pesky evangelists.


I wonder when the .NET balloon deflates, we will hear their CEO harp on their cash position too ;)

Monday, April 12, 2004

Brower based apps and Longhorn

Adam Bosworth writes about browser based apps on his blog. Here is my response.


You caution the world on possbility of Microsoft taking the applications back to the desktop away from the browser. I feel your argument is as valid as some hardware designed skimping of memory because in the old days memory was expensive.

The compelling reason for deploying browser based applications was that such applications are cheaper and easier to maintain thereby saving the enterprise money etc. That was the desktop centric argument. Then came mobile computing and that reasoning was further strengthened because we now have multiplicity of devices.

Those compelling reasons are no longer valid in today's world of falling cost of semi-conductors, software and services i.e. global deflation.

The clients side mobile or desktop is getting richer, cheaper and ubiquitous without sacrificing variety. If the application is not able to exploit this, the application is not worthy of deployment. While you may argue that browser based application lower the cost of deployment and will therefore be deployed not matter what, think again, because the global economics is showing that cost cutting is not the dominant framework but productivity enhance is.

The pendulam had swung too far into the browser based apps domain and I hope Microsoft bring it back to the desktop domain a little for those of us who hate to use browser based applications because of it very unproductive UI.

Redhat Free?

So if you do up2date on Redhat, you have to pay $20 for a yearly subscription. I thought Redhat was free?

Even Microsoft does not charge for a windows update!

May be Sun should charge charging for those Java updates..

Friday, April 09, 2004

.NET and J2EE Interoperability

So I found this company mainsoft at http://www.mainsoft.com. It offers this toolkit which allows you to develop applications on VS.NET for J2EE.

You think MSFT and SUNW made a deal to put mainsoft out of business ? ;)


Thursday, April 08, 2004

Java Community Fragmentation

Java community's fragmentation will lead to .NET taking over the developer mindshare and skillshare.

These marketing guys don't know much about marketing to developer world. It is not marketshare or mindshare that matters. What matters is skillshare. .NET through its VS 2005 or whatever they are going to call Widbey will enable a 60% of the programmers out there to enter the world of webservices. Only about 20% of the programmers in the world are Java programmers.

The response from Java community is further fragmentation of Java. Visual Cafe, JBuilder, JDeveloper, Sun Studio and Eclipse. And they say Java should remain in JCP to prevent fragmentation. IDEs have already fragmented the Java community.

Costs in Training LLMs

 I went through the Llama-2 white paper that was released with the model by meta. I was hoping to learn some special technique they may be ...