OMA

On Thu, Jul 18, 2002 at 12:07:46PM -0700, David Orchard wrote:
> RE: REST, Conversations and ReliabilityHeck, I wouldn't accept a WSA built
> on RPC/OMG OMA principles either.  There's this great stuff like SOAP, XML,
> URIs, HTTP, the web, etc. out there  ;-) No fine-grained tightly coupled
> object/API based binary encoded interchanges and binary encoded addressing
> formats that ignore the network and specify implementation details for me...

You're talking about a particular configuration of CORBA with that
description, not the OMA.  Neither the OMA nor CORBA is necessarily
binary-encoded.  See XIOP;

http://xiop.sourceforge.net/

OMA/CORBA also isn't any more fine grained than typical Web services.  Nor
is it any more tightly coupled, because interfaces are cleanly separated
from implementation.

So are you really sure you're not redoing the OMA?  An easy way to tell
would be to ask you to identify what you see as the architectural
elements for the Web services architecture.  i.e. components,
connectors, and data elements per;

http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm

Or pick another recognized taxonomy if you don't like that one.

> Where the analogy to OMG OMA is useful is in describing the goals and
> objectives of application to application integration, and learning from much
> of what worked and didn't with OMG - because certainly OMG worked in many
> areas.  In particular, the separation of concerns between the application
> and the services of the underlying network infrastructure, like reliability.
> It's probably really useful in other areas that I just haven't thought of in
> my current 2 minutes of thought on the topic.

Well, I've thought long and hard about this for 4+ years, and I've yet
to see any aspect of the OMA that doesn't have a superior parallel in
REST, when evaluated for Internet computing.  Perhaps there's something
I've overlooked, but I doubt it, because OMA/CORBA was never designed
for Internet deployment (despite some believing that it was); it was
designed for Intranets, and curiously enough, that's the only place it
saw any success (and by "Intranet" I include VPNs - anywhere where a
single administrative domain exists, providing an out-of-band
coordination channel between service provider and consumer).

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Thursday, 18 July 2002 23:42:53 UTC