avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [RT] Management vs. Component Resolution
Date Fri, 30 Aug 2002 13:04:09 GMT
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> 
> Berin,
> 
> basically your criticism is of the type that given 
> publication style, interfaces would be published completely 
> without control.

Very important distinction here:

not *would* be, but *could* be.  First and foremost, we want something
that is architecturally secure.  Security is about keeping information
and control inaccessible until there is a specific need for it.  It
also is about *very predictable* access points.

My point (which you seemed to miss) is that it is out of the control
of the child container has no *predictable* control over how far the
the interface is published.  What's worse, its implications are not
as easily understood as publishing the interface to a global access
point like JNDI.  At least at that point you *know* what you are
dealing with.  If you make a wrong assumption about the publication
model, the consequences can be *really bad*.  Its really hard to make
a wrong assumption about JNDI.


> I'm not advocating that publishing should be automatic or 
> that it should be uncontrolled. One major point is, as you 
> say, to keep components isolated and unaware of anything they 
> do not have the 
> "right to know".

So plan ahead.


> But if publishing is handled at the assembly level - the 
> assembler has to explicitly state that "YOU - CONTAINER! 
> Publish service X!" then your criticism against publishing 
> pretty much disappears. It would also be possible to override 
> the default inheritance style 
> lookup without introducing bizarre side-effects. All you have 
> to do is ensure that everything has to be explicitly stated - 
> otherwise you are right, you will have service interfaces 
> flying around and colliding left, right and center.

Yes, but there are no guarantees that if a team of students at
Podunk University (PU) created their own container that does
not respect the constraints of the interface publishing it would
have disasterous consequences if your container expected it to
act in good faith.

You also missed out on a bunch of good stuff because you have
already decided in your mind that you want to publish interfaces.
You will kill whatever hopes of success you have when you make
up your mind and *refuse* to hear any other conclusion.

> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> >                       -o0 Publication Style 0o-
> >
> > The publication style is the approach that I *think* Stephen
> > and one of the Leo's are advocating.  Basically, the 
> > publication approach exposes a controlled set of services to 
> > a parent component to allow resolution of the service. The 
> > major problem with the publication style is that once you 
> > publish an interface, you loose control over who else gets 
> to see it.
> > 
> > To provide an example of the publishing style pitfall, lets
> > use the container hierarchy of "root/sub2/child1/end".  If 
> > the "end" container decided to publish a service to its 
> > parent, it looses control at that point.  It could be that 
> > "end" intended for that service to be used in 
> > "root/sub2/child2", in which case it would expect "child1" to 
> > republish the same service.  The problem comes when "child1" 
> > republishes, and "sub2" republishes it, and finally it is 
> > accessible at the "root" level.  This is bad.
> > 
> > Another point to consider with the "publish" style is that it
> > must be done *safely*.  That means we only publish a proxy to 
> > the service, and the proxy has to be able to determine if the 
> > client is legally permitted to use the service. Also, the 
> > publication mechanism should not be on the Container 
> > interface at all. It should be moved to a separate interface, 
> > and publication accomplished much like the ServiceManager 
> works today.
> > 
> > The ServiceManager is a peer to both the container and the
> > client, however it affectively isolates the two so that the 
> > client cannot directly control the container.  We would need 
> > a ServicePublisher that the child container would use to 
> > publish the service and its proxy to the parent container. 
> > Another important aspect is that the publishing mechanism 
> > cannot override the natural inheritance style selection.  All 
> > it can do is raise the level where a service is accessible 
> > from.  If a parent can already handle a published service, it 
> > does not need to use the published service at all.  Those 
> > decisions would be an assembly level issue if there are 
> > mitigating circumstances when a published service must be 
> > used in preference to the existing implemenation.
> > 
> >                        -o0 The Conclusion 0o-
> > 
> > Service publication is an extension to the contracts already
> > in place for containers, so we cannot expect others to jump 
> > on the bandwagon. Therefore, you would possibly be able to 
> > embed Merlin inside Phoenix, but I doubt that Phoenix would 
> > ever support the extension.  I really don't think it should, 
> > because Phoenix is designed to be a root level container, not 
> > an embedded one.
> 
> Whether it does or not is not that important. The important 
> part is that if it does, it will do so in a compatible way. 
> This is like saying that since Tweety will probably never 
> support access to services via JMX, it is useless for Peter 
> to create a standard class for Service meta data. (I think 
> one of the reasons was to provide JMX access points.)

There you go jumping to conclusions again.  How does the Service
level meta data mean anything in this conversation?


> > The best options are to use JNDI to publish all the services
> > in a global namespace like the J2EE style
> 
> Just one final comment: Since you think it bad to "lose 
> control" over a service interface, you can not seriously mean 
> that placing that interface in a globally accessible 
> namespace is giving you any more control and that doing so 
> would be a better option?

It is a *predictable* model.  You can *never* guess when it comes
to security.  If you have a global namespace for all published
interfaces which is essentially what JMX and JNDI do, then you
*know* #1 how to access the services and #2 how to protect them.

JNDI and JMX can be protected so that they can only access those
points through a known security gateway.  The developer who is
writing the services that are published globally will not cut
corners with their security model because they *think* their
service won't be accessible to a third party when it is.

The important thing is *predictability* and ease of securing the
access points.  It's a lot simpler to do when you have guarantees.
Inheritance style service resolution *works*, and it is *predictable*,
even if it feels limiting.  Publishing services to a global namespace
*works*, and it is *predictable* even if you feel naked.  Publishing
Services with assembly information may *work*, but it is
*unpredictable*,
so it is not a good mechanism.


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message