|>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.
Either that or you control the JMX infrastructure, a JMX server that includes the externalization of stacks of JBoss would do just that. |> 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"? read the book |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. The stuff that does that is the XMBeans of Juha's upcoming book. |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... 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. I was critizing the rest of the "praise", in my mind the real pro here is the localized semantics. |If an MBean has unresolved dependencies it is not allowed to start. If it sure |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 do you hold a bean until you get an event in case you don't have the bean yet? |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). hmmm interesting is this during run-time? so how does this work you recieve an event and you stop the mbean and you control the reference inside the object (must be exposed) and you set it to the new MBean name... the reference of inter-bean is what? this is not clear. Do you call the bean directly do you call the server? You are talking about stateless stuff here obviously. |>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. What I describe has nothing to do with EJB. Reread it. |>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. Yes but that is inferior to rerouting on the server. Reread my mail. |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 That is not correct. The client knows about different JMX node invokers. |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". think... we add interceptors in JBoss (EJB) with the JBoss infrastructure that takes the jboss.xml. The creation of the stack of interceptor is done by JBoss and we don't "touch" the EJB spec. In a likewise manner, adding interceptors to invoke() MBeans can be done by the JBoss infrastructure at the JMX server level (the JMX server would be JBoss in this case). 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. (of MBeans in this case rickard not ejb) |>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. I am not following you. You keep talking about clients on the web with RMI references to JINI and a "star" of connections from n clients to n services... with RMI... on the web... you crazy? I believe that monitoring the state of the mbeans in the nodes (multi node even, but squarely server side) is the way these services will scale. So the monitoring is good on server only. |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 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. |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 The dependencies stuff is interesting yes. |4) Use Jini to implement a remote MBean gateway between servers ... |That should be a good start anyway. yes What I really want to do is finish the website and then go back to developing sometime next week. I will code the "detaching" of the invokers and we should pick up this discussion when we try to finish the configuration stuff in JBoss3. marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
