Berin, basically your criticism is of the type that given publication style, interfaces would be published completely without control.
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". 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. > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > -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.) > 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? /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
