|>Either that or you control the JMX infrastructure, a JMX server that |>includes the externalization of stacks of JBoss would do just that. | |That's true. So, you want to replace the RI then?
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. 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. 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. You talk about management invocations in your mails, I talk about ANY invocation in the target beans (including EJB) |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. |>The stuff that does that is the XMBeans of Juha's upcoming book. | |.. which is similar to what I have described, right? yes, the XMBeans is similar to what you describe, take a look at the persistence and what we will plug in the persistence is interesting. |>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. |Yes, that MBeans can deal with their own configuration semantics. Right? |*Which is what I said*....geeezz... Well I will be direct, you said a lot of things, including that it will eradicate war. The fact that they can deal with their configuration is the important thing at this 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. |>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. 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. Dynamic scripting of invocation flows in 24.7 meshes is the key to it all (jboss.net) imho. 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. 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). |placing the logic in the MBeans instead, i.e. in between the invoke() and |the actual call handling, the MBeans become more self-contained. I prefer |self-contained, unless there is a big win with putting it in the server |itself. Yes and no, depends what you are talking about. If you are talking about extending the invoke() through stacks (like in EJB/JBoss implementation (and please don't come back with "buuut I aaam not taaaalking about EJBeeeee" rise above yourself)) then the mechanism to put that in place is generic enough to be abstracted (creation and lifecycle). The actual interpretation of the configuration still falls on the bean. I think you need to refine that view with examples from the web-services world. 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 the main difference between what we're saying is that in |my case the |"clients" are other JMX servers, and the MBeans in them. In that sense this yes ok, it was scary in your previous mails. |>you crazy? | |Not that I know of, no. uh rickard, you are absolutely crazy... and I truly believe you are an alien. |>the monitoring is good on server only. | |As above, my definition of "client" is not "end-user client" but rather |other servers that host MBeans using MBeans in other servers. we agree then. Using jini as a server side watchdog, might be a nice thing as it automates the lifecycle -> event generation plumbing. 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). |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. In fact <soap-box> the future of web-services and Jboss.net sort of depends on that. We all know the price of serialization and the optimization at this point are going to make the difference between a good and a bad stack of products </soap-box> |>Yes, agreed in development for the book, the XMBeans. If you want to |commit |>your stuff there today, feel free. At least read the XMBean chapter from |>the book would be interesting. | |Will do. Juha, interested? I think it is interesting to have your work and ideas there, let's talk offline. marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
