>|Implementation model >|==================== >|Let's start with the basics. The JMX MBeans in JBoss are all based upon >|the Standard MBean model. This has worked well, and is especially a very >|lightweight and simple way to make components manageable. The downside >|is that you can't add very interesting metadata and custom call >|interception (such as per component security checks) without going > >I agree with the first one not the second one... but that is a minor point. > >You just mean that "invoke()" is a more natural way to String together >detyped services but you could argue that for the price of putting the >Dynamic Proxies right behind the standard MBean interface you can generate >the same invoke() call and thus string a stack behind it.
You can only do that if you are in control over the MBean instantiation and registration. If you want to make generic MBeans that do not depend on the JBoss infrastructure this does not hold. It is not very standard-ish. >|through hoops. I've decided to use a different model that uses all three >|types of MBeans, but which makes use of the benefits of all while still >|being easy to use. > >uh oh... sounds like an "excercise de style" "hmmm let's see if I can use >all of the beans of the specification" It just means that all three models have pros and cons, and the cons of each model is being fixed by one or a combination of the other two. I didn't start out with "let's see if I can use all three models, humdidum". >So the DynamicMBean implements the invoke() interface and the invoke() >interface is then delegated to an instance of RMM which has instances of a >class provided by the programmer. Correct. >The mapping of the invoke() to the POJO... is a bit obscure at this point. This is done by the Model MBean. That is one of the big points of Model MBeans. To map invoke()'s to POJO's. Read the spec please. >|Note that the POJO case in this model does not have to know *anything* >|about JMX. All of the JMX-ery can be dealt with by the ServiceSupport >|subclass. Anyway, so this makes use of all three models and retains the > >Instrumenting without JMX knowledge is good but if that is the goal (which I >doubt) One of the goals is indeed to make the MBeans, or "services", as JMX-ignorant as possible in order to make them easy to write and also to make things about managing the MBean as reusable as possible. > then there are other easier ways to achieve this (see upcoming Juha's >Book ;-) by extending even the *binary* itself. What do you mean by "extending the binary"? >|* The easy-to-use mapping between dynamic calls and reflection >|invocations on the service object of ModelMBean's. > >That I don't see What is obscure? Mapping dynamic calls to reflective invokes is the most important task of the Model MBean model. >|* The easy-to-implement style of Standard MBeans. > >sure. Listen kid, using all the features of the spec is pretty cool, but is >it really necessary. No, nothing is necessary. But doing it makes it as easy to use as possible. >|* Need to map dynamic invokes of Dynamic MBean to reflective calls -> >|solved by ModelMBean model > >I see so the MM calls his POJO by reflection and you build the adaptor in >there. The MM *is* the adaptor. Do you know what ModelMBeans are about at all?? >|* Need to implement dynamic invokes of Dynamic MBean -> solved by >|Standard MBeans in conjunction with ModelMBeans model > >dynamic invokes of Dynamic MBean ;-) huh.... you are going to have to >explain that one Rickard it sounds kind of silly as I read it. If the MBean that is registered in the MBeanServer is a DynamicMBean you will be getting invoke() calls from the server. What do you do with that? Simple: delegate to a Model MBean instance that converts that invoke() to a reflective call on the Standard MBean that contains the actual implementation. It is really really basic stuff here Marc.... >|Configuration >|============= >|The way configuration works in this scheme is a little different from >|how it works in JBoss. In JBoss the Configuration MBean is pretty much >|dictatorial in that all MBeans must be configured through it. This is >|not how the JMX spec intended it to work. The Persistent MBean interface >|is there so that load() and store() can be called, and *if* the MBean > >Does that remind you of anything? come on... What are you referring to here? I've browsed through the new ServiceController/ServiceConfigurator stuff, and it still seems to be the way it used to be, i.e. it mandates that MBeans are configured through the XML mechanism. Am I missing something? Is JBoss indeed calling PersistentMBean.load/store somewhere? I couldn't see it anyway... >|wants to it can ask a central Configuration MBean, but it can also do >|whatever config reading it wants instead or additionally. The >|configuration MBean in my implementation still reads services.xml files >|and creates beans, but then it only calls load() which allow the MBean > >Not exactly. The load() store() is there to allow the component itself to >deal with its own configuration and persisting, well at least externalizing, >that representation through an indirected API. Exactly. Which is exactly what I wrote. So why did you say "not exactly"? > Juha talks about XMBeans >and a possible implementation for JBoss that leverages the local knowledge >of component and delegates the "state" propagation, in this case the actual >configuration of a component, to whatever framework lives behind the API, we >are thinking of Entities to store/share configuration. Sure, that could work. Still, I don't see in current JBoss 3 code where this is left to the individual MBean to decide. It seems like JBoss mandates the configuration to come through the SAR stuff. >See the fact that the component delegates back to the SC is irrelevant, No, it is crucial. Without that you have a "dictatorial" point of view, which is what JBoss 2 does, and JBoss 3 AFAICT. > what >is important is that the component needs to be the only one to make sense of >the semantics of the particular configuration format. For example currently >Jetty uses their dialect to configure and we don't really want to >standardize on that, it would then make sense for them to use the load() and >store() operations to use a persistent store (possibly and entity EJB) to >retrieve their stuff and the byte[] they get back is the xml file they like >so much and then the component that is fielding the call, your plain old >pojo is in fact their own smart parser. Exactly. Where in JBoss 3 are the calls to load()/store()? >yeah you know what I think of work that "essentially achieves exactly the >same but essentially take 1000 more hoops". Excuse me? Not quite sure what you're referring to here... >That being said and again, I think you need to read Juha's mail more >carefully and his forthcoming book, heck you should review it ;-) the load() >and store() of the configuration is kind of interesting as we found out with >Juha as it enables you to do clustered configuration management with a >simple EJB under the call. I know juha answered you already with the XMBean >stuff he has coded in his book (that is really a KILLER part) and I would be >curious to hear your feedback on the idea/implementation he put forth. It seems like what I have done is very similar to what he has done (based on his descriptions anyway). Which makes it kind of interesting why you're dizzing what I'm saying, since you're on the other hand praising the very same approach. I never did understand you dude... >Yes, sure, I am curious to dive into what David Jencks has done since the >"late binding" (if it is really there) is kind of interesting. Due to the pattern-ish use of ObjectName dependencies (simply using the pattern stuff that is in JMX here) that is really what I'm describing, and it *is* indeed kind of interesting since it allows for a very simple "poor mans failover". >yes, the quesitn is what do you do with a service that doesn't have the >dependencies resolved, you wait until he is notified that everyone is up? If an MBean has unresolved dependencies it is not allowed to start. If it wants to be able to start without a dependency having been resolved it can mark it as not-required in the XML configuration. If an MBean is started and a required dependency becomes unavailable it will stop, unless it can find another MBean matching the same ObjectName-pattern (this is the "poor mans failover" part). > I >believe David creates a "graph" of dependencies that is build at run-time I >don't know if your stuff works to be honest. I would have to see it, with >notifications and all. It works. Building a graph is not really necessary, although in a sense I guess my approach also contains an implicit graph. >Ok, I don't know much about JINI but my guts are telling me that to expose >EVERY MBEAN as an RMI object for the rest of the world to see is a bad idea. I didn't say that all MBeans are exposed as RMI/Jini objects. Read what I wrote. >I am trying to know kid... you are fishing for ideas at this point because >the above sounds half baked to me. Ok, if you think so. I don't. The current RH stuff is half-baked, at least concerning the a) dependencies b) configuration mgmt. Both of those issues are handled better in what I propose and with rather simple code too. >Remember that in RH we want to disconnect the invokers from the target >beans. <snip> My proposal has absolutely nothing to do with EJB, if that's what you're referring to with "beans", so I fail to see why you discuss that here. >24x7 of the actual calls. If I understand correctly the way JINI works, if >the service goes down we then remove the service from the "invokable" ones >and essentially you don't call us anymore. Correct, and this can be done on the client side so it can fail over to another implementor of the required dependency. > If we go with the JMX >interposition instead we can "hold the calls" or maybe even reroute to any >available invoker to field the call immediately in case of a clustered high >available solution. On the server side, yes, but that is worse because then the client is never given the option of using another provider of the service. You are essentially saying "yes, sure, we're up, just.. uhm.. hold on.. anytime soon now" instead of letting the client know "ok, we're down, use some one else. we'll let you know when we're up again. sorry". I prefer the latter. > Also it should be stressed that this behavior is >independent of the connector so we could imagine an interceptor in the >dynamic invoke() chain that essentially is a "valve" to the whole JMX node >MBeans... you come in, if you MBean is active (we would have to rewrite and >tweak the JMX Server but that might be Juha's next goal) Why do you have to rewrite the JMX server? Anything that makes use of more than the JMX spec is essentially proprietary and pointless (IMHO anyway). You're not doing JMX then anymore, but is more "based on" than "compliant with". >In that picture, JINI becomes a "watchdog", something that keeps on >monitoring the state of the beans, whether up or down and >register/deregister in their behalf... that is nice plumbing and I wonder is >that is not the real use of JINI in our framework. Only if you do it on the client side. As above, if you do this stuff on the server side only it becomes kind of limited, at least for inter-server MBean2MBean invocations, which is what I was aiming at. >Rickard as usual your insights are welcome, it is always good to hear you >are alive, still somewhat thinking and still "productive"... what I really >recommend Rickard is that you do not disconnect from our flow... this is >PURE juice and you know it... you need to be on that flow you would really >get a kick out of it and it would prevent your ideas from going stale or >staying "half baked"... As is probably apparent from the above I think that a) you have missed some crucial points about how JMX works b) I don't believe what I described is half-baked JBoss 3 is going to be very very cool, but IMHO it could really benefit from using the ideas I outlined, which in essence are: 1) Make the configurator non-dictatorial by exploiting the PersistentMBean interface 2) Make dependencies use ObjectName *patterns*. All you need is already there (MBeanServer.queryMBeans), so just use it 3) Make dependencies have an internal contract as well, i.e. a resolved dependency may involve setting an attribute with the resolved MBean 4) Use Jini to implement a remote MBean gateway between servers That should be a good start anyway. /Rickard _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
