27 Jan 2006 - Remote API’S, Web Services and the GeoWeb

Remember CORBA?  Aside from the attrocious marketing of the OMG (Surely it could have been named COBRA) this was all pretty good stuff - methods would be invoked across the Internet (remember IIOP) - things would interoperate across the web in a smooth fashion without regard to implementation languages at the server or the client.  Some how it did not happen in the way many of us thought and things move on (or back depending on your perspective) to encodings (XML) and messaging (web services).  Of course when you go to implement those web services in practice it is rather useful to have a client API.  This starts to sound again like the CORBA days except that we have less emphasis on the standardization of the API itself for a given application domain or type of service.  The standardization now is at the level of message encoding - messages which enact actions or which carry data payloads. Pretty much everyone has agreed that the messages be encoded in XML - with various "levels" of that XML for different tasks in the interaction - general message transport and routing might for example use SOAP, database requests in the GI world might use WFS, and the message transport in the GI world would likely be GML.

One might wonder why this has taken place?  Why did this web messaging/encoding approach gain near universal support when CORBA (and the Microsoft DCOM) did not?  Will we see a tilt back in the opposite direction?

What the messaging paradigm (messaging and encoding) does is to separate the "client" programming environment API completely from the actions of the server.  While the client API designer might directly refflect the XML message structure of the web service, there is no requirement that this be so.  The client API developer is free to repackage the the messages however they please.  This also means that vendors are free to provide competitive SDK's that are harder or easier to use - have performance advantages etc. - while at the SAME time ensuring interoperability (i.e. compliance with the message encoding).  So we can have vendor differentiation AND we can have standardization.  While some of this was possible in the universe of remote methods (CORBA, DCOM) things were much more restricted.

Comments

No comments yet.