What is robust? Every CORBA service is designed to work in the perfect world
where programmers don't make mistakes, users don't go poking around the
network and no one ever decides to try and mess anything up. They basically
depend on the programmers getting everything right.
A very good example of this can be illustrated with the Event service.
There is no way for that service to know if a given individual entity should
be presented with the topic list. The Event service "trusts" that since the
entity has the appropriate interface, they must know what they are doing and
hence should have access to the topic list. Every "off-the-shelf"
implementation of this service works this way. Not one of them is tied to
any security model. In fact, the expectation is because every environment's
security needs differ, they must find their own way to protect the service.
I have spent the better part of the last four years of my life working
issues like this out for Sabre (the company which runs the Computer
Reservations System as part of their Strategic Architecture group. They have
a distinct need to keep people from even seeing capabilities for which they
are not granted access (The EC has very strict rules about this). In order
to conform, Sabre has chosen to provide proxies for each service and only
provide direct access to the proxies. In some cases, they are using orb
specific interceptors for security. This is not really ideal as they did not
want to bind themselves to a particular orb vendor. While these techniques
will work, the interfaces projected for developers are not exactly the CORBA
defined ones. They are extended in order to provide Sabre's capabilities.
The facts are that CORBA service implementations work really well as long
as you don't try to use them beyond an immediate enterprise environment. (I
will grant that Sabre's enterprise environment is rather unique). Once you
extend beyond a trusted arena, the "robustness" of the services fall apart
quickly. Just try to offer a service across a NAT'ing firewall! B2B? Without
a common security implementation, CORBA forces the applications to use the
security framework to negotiate their own specific protocols.
----- Original Message -----
From: "marc fleury" <[EMAIL PROTECTED]>
To: "jBoss Developer" <[EMAIL PROTECTED]>
Sent: Tuesday, August 01, 2000 6:02 PM
Subject: RE: [jBoss-Dev] rmi,transactions,orbs [was: TransactionImpl]
>
> > While it is true that these frameworks can be utilized for creating
> > "value add" services to jBoss, they do not present a strong
> > enough case for
> > marrying the container to a given distribution technology.
>
> It wouldn't tie us. But I find interesting that you don't view most Corba
> services in general as robust enough... or presenting value add
>
> marc
>
>
>
> -------------------------------------------------------------------------
> This email server is running an evaluation copy of the MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: www.mailshield.com
>
-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info: www.mailshield.com
