Thursday, October 14, 2004

NanoCorps

NanoCorps or Micro ISVs (Independent Software Vendor)

Now it is almost two years since i have started working and i have had a jumbled software life. I started out with InstallShield, got a bit into VC++, then some testing, ASP.Net, C#, Tibco Rendezvous, BizTalk 2004 and MSMQ 3.0. I have had the opportunity to work with fine minds in these two years and learnt a lot.

tent-at-pangpema

Now i do keep a catalogue of product ideas which i can use to start my own Micro ISV. So somewhere in my career path i definitely see myself being a part of a organization which i would build.

A good way to start is what these pioneer ISVs recommend:
Eric Sink (http://software.ericsink.com/) calls them "Micro ISVs" and Thomas Warfield (http://www.asharewarelife.com/) as NanoCorps.

Friday, October 01, 2004

Web-Services and document model

Web-Services are all about achieving loose coupling, Its obvious that web-services will be used across organizations and you cannot assume that the service definition wont change

Today in most implementations, classes (stubs) are generated based on the WSDL which delegate the call from the client to the service. The problem is that the WSDL sort of acts like a interface and if this interface changes your generated classes have to change, which in turn means you can no longer use the service!

The fundamental problem is with the way web-services are being used. Right now they are following a pure RPC model. (ok internally they might use SOAP/XML over http, but it does not matter).

girl-cooking

When we say 'SOA' the model should be closer to a document exchange model instead of RPC model. What i mean by this is that service should define a simple interface probably with one method like:
string processDocument(string xmlDocument);

There is not much in the interface itself, so it won’t change :)
The intention is that the client should pass all the information that is required as a XML document. XML has the flexibility that it is easily extensible. So if your service adds some more functionality and requires more parameters it can be easily included in the xml document.
Your old clients will still work it wont break them. Your new clients can still happily send the xml doc that includes the new parameters and still work.

This is fundamental to how we should define and use web-services. There are more intelligent guys there who have thought of this and explained this in much more easier and clearer way than i have explained :)
Adam Bosworth explains this concept beautifully.