My comments inline with JGH. I haven't really done much documentation on this yet, which is what I wanted to do in the next few days or so. I just wanted to get the initial codebase committed so we can have the benefit of others looking at it.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Wednesday, February 19, 2003 3:41 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss Remoting Commit Woo hoo!! Thanks! This looks great!!! Will you guys mind if I fix minor oversights I notice (such as making handler names consistently upper case in ServerInvoker)? Partly so I don't forget and partly to think out loud as I read the code, here are my initial comments: 1. There's kind of an impedance mismatch between the remoting invoke method and all the interceptor invoke methods. The interceptors all have some kind of invocation object that includes method name, args, sig, and extra params: these are separate arguments in the remoting's invoke method. I think the same signature everywhere would make integration everywhere easier. In particular, I'd like the Invoker to implement whatever Interceptor interface we finally come up with. I'm mildly in favor of a single Invocation argument, even though it is not the most natural for the original jmx remoting use case. JGH: I think this is fine, and we just did an initial commit w/o fully knowing the other invokes. There are a handful of things that the remote invocation needs to have, such as the classbytes. But, one object (or at least a base object that the remoting can extend) would be much cleaner for all. 2. I need to have essentially client and server side invoker interceptors (e.g. the InvokerXAResource). I'm sure others will think of uses for this when it is available. If we decide one way or another on (1) I can implement this possibly using an adapter that could be removed if we decide to go with a single Invocation argument. JGH: That's fine if I understand what you're saying. 3. So far I've just looked at the socket server invoker. I want to be able to plug in a thread pool (implementing a standard interface). I also want the stuff that's done in the thread to be set up as an interceptor chain. For instance, I want the "extract the xid from the invocation and import it or prepare/commit/rollback/recover/forget" to be in one or more interceptors. I think most of this is taken care of by the selection of ServerInvocationHandler: I can make these be my interceptors. I wonder if a clearer architecture would move the ServerInvoker invoke(byte[]) method into a separate class that the transport mechanism runnable classes subclass. This object would then be the standardized object submitted to something like the jca 1.5 work interface. [this is the jca 1.5 thread pool, and it provides for both synchronous and asynchronous execution of a Work object. I like the idea of always using the same kind of object, but the Work interface itself is not appropriate since the contents of the ExecutionContext (tx context or xid) would not be determined until the thread starts processing. I'd like to build the jca 1.5 implementation out of more basic units.] JGH: There is a ThreadPool using the concurrent package in the SocketClientPool I believe. Are you doing this for client side async invocations? The reason both client and server invokers extend from abstract is to get the basic classloading/marshalling/unmarshalling logic since both sides have similar logic. 4. I haven't found yet how the client invokers get set up in the client. Are there situations in which they are obtained through rmi? Should they be mbeans in a client-side jmx server? Should this be optional? Working on the TrunkInvoker I made the client side piece into several mbeans that got created/registered when the first one got deserialized as a remote object. This considerably simplified keeping track of the pieces. Is something like this a good idea here too or at least compatible with what you have? JGH: So, an implementaiton of a ServerInvoker represents a physical wire transport - such as Socket, IIOP, SOAP, RMI, etc. An ServerInvocationHandler represents a invocation context subsystem handlers, such as JMX, JMS, etc. The relationship is 1..* ServerInvoker-ServerInvocationHandler. When the client invoker builds the invocation, he will tell the invocation which subsystem he is invoking against - since the client side Invoker will represent a subsystem context from the callers context (i.e., in JMX it's a dynamic proxy that looks like a MBeanServer). Currently, the way I'm setting it up is via JMX attribute in XML. There's an example in the javadoc of ConnectorMBean (I think). I'll try and check in a service.xml file as an example in the next day or so. So, my thought is that the connectors (ServerInvoker implementations) would be registered in the jboss-service.xml *before* any of the subsystems along with the subsystems supported. Then, the Connector will create the appropriate server side ServerInvocationHandler instances and register them with the ServerInvoker. The other important part of all this is the InvokerLocator, which is a URI-like string that describes where the physical transport can be reached. This is broadcasted as part of the detection framework - so that remote servers can be located based on their InvokerLocator string. Then, as a client needs to "find a server", it can query the NetworkRegistry for any servers (that match the protocol, etc.) to create the ClientInvoker (via the InvokerRegistry) back to the server. So, you can either us discovery or directly using the URI make invocations against a remote server - and it's painless. Discovery is pluggable, so right now we just have Multicast. Tom is currently working on Unicast/HA JNDI. We would like to add UDDI as well. 5. Since I think it is possible that jmx could be used without aop and aop without jmx, I'd like to suggest that we make a new module "invocation" that has the interceptor interface, and the Invocation and InvocationResponse objects in it. Otherwise I don't see how to unify our view of these fundamental classes without intruducing artificial dependencies. JGH: I like this idea personally. I'd like to get to work on the interceptor stuff I mentioned, so I'd like to get comments on this soon so at least I'll know how much I'll have to fight:-)))) JGH: Can we start a separate development forum to continue this?? BILL/MARC?? This is awesome work. JGH: Thanks! Thanks again david jencks On 2003.02.19 00:54 Jeff Haynie wrote: > I commited the jboss-remoting code tonight. There is now a separate > module named jboss-remoting, and it is aliased in jboss-mx and > jboss-head (because mx needs it). > > It looks like all 3 modules are compiling fine. There is more work > that Tom and I are doing this week to try and wrap up the initial > testing - however, the code should compile fine and the code isn't yet > referenced at all anywhere in the server so shouldn't cause any > problems. If it does cause problems in the next day or so, please let > me or Tom Elrod > ([EMAIL PROTECTED]) if you have any issues - or just fix them > and let me and him know. > > -Jeff > > http://www.freeroller.net/page/jhaynie > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; > charset=us-ascii"> <TITLE>Message</TITLE> > > <META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD> <BODY> > <DIV><FONT face=Arial size=2><SPAN class=323323305-19022003>I commited > the > jboss-remoting code tonight. There is now a separate module named > jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx > needs > it).</SPAN></FONT></DIV> > <DIV><FONT face=Arial size=2></FONT> </DIV> > <DIV><SPAN class=323323305-19022003><FONT face=Arial size=2>It looks like > all 3 > modules are compiling fine. There is more work that Tom and I are > doing > this week to try and wrap up the initial testing - however, the code > should > compile fine and the code isn't yet referenced at all anywhere in the > server so > shouldn't cause any problems. If it does cause problems in the next > day or > so, please let me or Tom Elrod (<A > href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>) if > you > have any issues - or just fix them and let me and him know. > </FONT></SPAN></DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2></FONT> </DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN > class=323323305-19022003>-Jeff</SPAN></FONT></DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN > class=323323305-19022003></SPAN></FONT> </DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2><A > href="http://www.freeroller.net/page/jhaynie";>http://www.freeroller.net/ page/jhaynie</A></FONT></DIV> > <DIV dir=ltr align=left><FONT face=Arial size=2></FONT> </DIV> > <DIV> </DIV></BODY></HTML> > ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
