marc fleury wrote: > Well the more I think about what we are doing and the more I see the future > of the webOS starting with the management of modules invocation stacks that > are put in it. This is the magic of the detyped invocation chains it allows > for arbitrary stacks of interceptors, even dynamically arbitrary. There is > replication of them across nodes (with full URL as in RH (what reads it is > the XMBean domain)) and clustering and distribution at that layer.
True. > Reading your stuff I realize we are talking about the same invoke() stuff > that we plan on putting in the new RH invocation chain of beans. From the > JMX standpoint the target beans are irrelevant, whether they be ejb or mdb > or what have you as long as they all present an MBean invoke() face they are > candidates for meta-programmation in stacks in front of them. Yes, if the EJB's are exposed as MBeans it is more of a special case than anything else. (And not so special anyway, which is the whole point) > Then the question of the stack of interceptors becomes interesting. > Metaprogrammation is interesting in many aspects the simplest ones at this > point being the transaction and security but really any interceptor that we > can plug in there (monitoring perf is another that comes to mind). Where we > manage these interceptors and how we do it is definitely at the JBoss > infrastructure level and it could very well be at the JMX layer in between > bus invocations. It should be doable as MBeans, i.e. no real need to change the bus. The interceptor stack map fairly well to JMX Adaptors. > You talk about management invocations in your mails, I talk about ANY > invocation in the target beans (including EJB) Correct, there's no need to make a distinction if you put the EJB's on the JMX bus. > |that you don't think it's worth the effort to answer properly, or that you > |don't know? > > Both, I think reading the book is the best, juha has made just amazing > progress in his understanding of the JMX specs and its usage. As you saw in > his email response I think he might even be one step ahead of you there, > well he has been thinking and writing for 4 mo. Yup, he's got it covered, that I gathered :-) If he's one step ahead of me, well that remains to be seen ;-) (who cares anyway..) > |>well relax... I am not dizzying you. I am praising the load and store in > |>both approaches. The important thing is the beans dealing with their > |>configuration semantics. > | > |Which is not how JBoss 2/3 works today. > > I know, the first place juha talked about it was in relation with the Jetty > request for esoteric configuration and storing of it. We discussed (he > presented) the XMBeans in London and his interesting idea was putting an EJB > behind the load store semantic. The reason is that you have free clustering > of the configuration, this is very powerful. Good point. > |In my case the client is another server, i.e. I'm referring to MBean2MBean > |communication where the MBeans can reside on different servers. How is it > |inferior? > > ok client is another server, that is better, still not optimal if all the > beans are individually talking about their state but at least not in the > "crazy" category. There are a couple of important points to lessen the "crazy aspect": 1) There will not be nxn connections where n is number of services. The *worst* case will be sxs connections where s is the *number of servers*. RMI connections can be shared by MBeans in the same server. 2) I seriously doubt that any given system will be a complete graph, i.e. that all servers will use all others. In practice there will probably be layers of servers, or clusters of servers where each server within a cluster will not use servers in the same cluster, only servers in other clusters. > |>Either you do it there or you do it in the bean, either way you need a way > |>to describe the stack of interceptor to the bean (that would create it) or > |>to the JBoss-like deployer. > | > |Correct. And if you do it in the server the MBeans that makes use of it are > |tied to the JBoss server, i.e. they are not portable to other servers. By > > That is correct, portability of the invoke() is lost, but doesn't preclude > you using the inside bean version as well. You don't really lose something > and you gain standard configuration of stacks. And in fact the interesting > part is that you offer people a way to generically describe externalized > stacks of interceptors. That is truly powerful. > > If you don't do that, the client has to come up with something that > essentially DOES EXACTLY THE SAME THING. No, all you need to do is place this configuration of stacks in an MBean, just like you do today (in what used to be ConfigurationMBean. Is it the ServiceConfigurator or ServiceDeployer now? anyway..). Think JMX Adaptors. But you do have a point in that it might be the case that configuring the stacks can be done *more efficiently* if done inside the server. Maybe, maybe not. > The thing that is even more JUICE in there is that you now have a way to > manage the stacks through the server *and dynamically*. For example imagine > you want to add a metadata interceptor to a given bean. The thing that is > interesting is that you can for example add a "valve" interceptor that gets > in the chain somewhere (say beginning) and freezes the invocations and then > you can put a new interceptor that does advanced security and defreeze the > invocation and *remove* the interceptor. All through the servers > infrastructure. That's important for the "five nines", indeed. Or six or seven or how many nines you want. ahw wtf, nine nines.. that'd be something :-) > Maybe one thing that is missing in the descriptions is that I view the > "invoke()" of the beans not only as administration operations but really for > ALL operations invoked in components residing in the server. +1. > What we both like then is that the stringing of stacks together in front of > the target bean is a task that can be taken care of in a generic fashion in > the server (JMX/JBoss base).As an application example, putting together an > EJB is no different that putting together any type of bean and essentially > means, put the following stacks in front (the role of the container factory > today). Meaning that any MBean can take advantage of the tx and security stacks. NOW WE'RE TALKING. Because the EJB model, as some of the listeners are aware of (Hi Sean), does have some serious flaws as a *practical programming model*. Can you say "over engineering". Knew you could... If you can make the EJB interceptors - which is really what is the real deal with EJB - available as a generic MBean stack that will be very useful. (understatement of the day) > More straightforwardly, making the "MBeans more self-contained" ranks a 2 > (on a 10 scale) on my "good idea for administration" list. We could use the > MBeanInfo to describe the stack but the mechanisms to do it gain enormously > by being in the JMX base. Don't you agree? I think I'm still leaning more towards doing what you describe as MBean Adaptors, but the problem with that is that you'll practically flood the MBeanServer with interceptor stack Adaptor MBeans. Which is not good. Hm.... > we agree then. > > Using jini as a server side watchdog, might be a nice thing as it automates > the lifecycle -> event generation plumbing. Precisely. > I will take a look at it in > this frame of mind. As a way to expose services to the wider world I think > it absolutely sucks (I could be wrong). 100% agree. It wouldn't scale. > |For the *end-user client* stuff your invokers et al becomes much more > |interesting. Absolutely. > > Refine this... it is interesting even on the server side, where you can for > example schedule asynchronous shuttle-bundles between nodes for messaging. > Meaning there are a lot of optimizations that you can do at the > communication level with a DETACHED/ABSTRACTED invocation layer inter-JMX > nodes. What I meant was that for the end-user client your stuff is interesting, and it's interesting for server2server talk *too* :-) The Jinification I talked about is just one method of intercepting, one possible stack, and not a replacement for you describe. /Rickard -- Rickard �berg Software Development Specialist xlurc - Xpedio Link�ping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
