[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: CORBA services]

Attached is an interesting observation on COS services.

Konstantin

-- BEGIN included message

Mike Holligan wrote:
> I'm having a lot of trouble understanding how these services are meant
> to be used.    When I first encountered Corba COS, I sort of took it
> for granted that they represented an essential toolkit and that we
> really would expect to be able to buy some sort of ORB + services
> package and start creating applications.
> 
> It doesn't seem to be working out that way.   The industry seems to be
> delivering up "solutions" which take only minimal function from Corba
> and "leverage" existing parts such as Object databases (and new
> "better" Java ideas which don't suffer from the already-legacy Corba
> understanding already!)
> 
> One problem with this  is that unless one fully grasps the
> architectural implications, all sorts of difficulties can later emerge
> from incompatibilities between the objects "inside"  the database (OO
> - database would be my temptation) and the objects "outside".
> 
> I haven't found that any of the Corba books really help me with this.
> 
> This is especially the case with query, relationships and associated
> services.    Either the ideas behind the proposals are trade secrets
> or they are too dimly understood to be clearly explained.  Its the
> classical "cockup or conspiracy" question. ( I reject utterly the idea
> that it is all in some sense obvious and that I must be stupid not to
> understand it.  )
> 
> I notice that the O2 database claims that it implements these
> services.   It seems to me that the expectation that it would only be
> ORB vendors who would supply these services isn't correct.
> 
> Otherwise, is it possible that the intention of these services is that
> one should implement these interfaces as features of  some application
> or service in order to provide a standard way of querying and of
> manipulating relationships within the application?

In general, you are right.  Some of the services are delivered as
standalone "applications" by ORB vendors or third parties, some can be
considered toolkits that help you build applications, while other
services are more "design patterns" that should be reused by
applications to improve the interoperability of CORBA applications, but
must be implemented mostly by the end user.  Here is a list of the
services and my position on what category they are:

Naming:
	Standalone.

Event:
	Standalone.

Persistent Object:
	Obsolete.  It was underspecified and too complex.  The OMG is working
	on a replacement.

LifeCycle:
	This one is a design pattern.  There are some practical difficulties
with
	the move() operation, but ORB vendors could provide some support to
help
	make it easier to implement.

Concurrency:
	Pretty closely tied to the transaction service, and difficult to use in
	a distributed environment without it.

Externalization:
	Not portable enough to be really useful, since there is no standard for
	how an object lays out its data.  You have to externalize and
internalize
	using the same implementation.

Relationship:
	Could be standalone, but would be more efficient when used as a library
	bound into the application.  There doesn't seem to be a huge demand for
	this service.

Transaction:
	Toolkit.  Very complex to implement.  Requires integration with the ORB
	using internal, non-standard interfaces.

Query:
	Design pattern.  There isn't much here that can be implemented
	independent of the specific application.

Licensing:
	Underspecified and non-portable.  I know of one commercial
implementation
	but there isn't much call for it.

Time:
	Toolkit.  Appropriate as a library along with a standalone application
	to deliver timestamps.

Security:
	Must be implemented by the ORB vendor, since the replacable interfaces
	are not sufficiently standardized.

Trading:
	Standalone.

Collection:
	Toolkit.  Could be a standalone application, but would be more
efficient
	as a library of object implementations (or design patterns) that are
	bound into the end-user's application.

-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

-- END included message