> -----Original Message----- > From: Kevin Moran [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 5:42 PM > To: Slide Users Mailing List > Subject: Re: First Cut of a Revised Slide Architecture > > > James, > I like your layered approach to the APIs. Thank > you for putting it together. While I understand most > of it, I'm still a little fuzzy on the JMX interface > you envision. Would it essentially initialize Slide > on start-up of JBoss? Call Domain.init()?
I guess for JMX there would be 2 levels of usage for the Slide mbean. The first would offer general management access via the JMX specification - things such as reporting on the current configuration, allowing on the fly configuration changes via settings in domain.xml, etc. etc. This would include the initialization of Slide on startup of the mbean service, as you mentioned, and post startup configurations and statistics. The second would be actual invocation of the slide kernel using the JBoss jnp network protocol (which is essentially RMI for this discussion) that would allow you to invoke our course-grained API. > Also, how > would my EJBs that use Slide's low-level APIs access > this kernel? Direct calls or some kind of JNDI > look-up? Good question, and I'm not sure I've thought this through fully so feel free to jump in with suggestions. My original plan was to allow the more course grained API to be transport agnostic. However, I haven't determined how to enable remote invocations of the lower-level Slide API. So, maybe here is a slight change to my first email: 1) The current concept of the low-level API is the API that becomes transport agnostic (not the course grained level). As an example, that would enable the entire Slide low-level API to be invocable from within the same VM as the kernel, over jnp for a JBoss mbean service, or via a J2EE container's transport in the case of an EJB. 2) The course grained API would utilize the low-level API to enable more interesting units of work to take place in one call, such as the locking of a resource, its assoc actions, etc. (see LockMethod.java as a good example of a more complex interaction scenario with the low-level API). 3) In the case of the webdav servlet and assoc xxxMethod classes, you could do some interesting scenarios: a) the servlet uses a direct invocation transport to talk directly to a locally-hosted kernel b) the servlet uses the JMX transport to talk to the slide kernel (would be direct invocation if JBoss recognized it was in the same VM) c) the servlet uses the JMX transport to talk to the slide kernel on another machine, allowing for more scalable solutions to be implemented by offering the distribution of tiers (more likely for rare occasions, but its an interesting side affect none-the-less) 4) Applications can opt to talk directly to the kernel via the low-level APIs, or talk to the course-grained APIs. An application would talk to the course-grained API to do things that would be considered WebDAV-compliant such that it could ensure external WebDAV clients can interact with the kernel via the HTTP transport while another actor in the system talks to the kernel from another process without WebDAV/HTTP. (does this make sense?) 5) The revised Struts/JSTL taglibs talk to the course-grained API as a matter of ensuring that anything designed using these tags would operate at a more "WebDAV client" level without the overhead of HTTP 6) If someone wants to build a simple Swing application that uses the Slide kernel for local CVS/RCS-like content and revision management, they can by simply installing the kernel in the VM and talking directly to it via the direct invocation "transport" Does this all make sense and clear up some of your questions/issues better? Taking into account my "on-the-fly" design, you would install the kernel as a JBoss mbean service and invoke the APIs from your EJB over the JBoss JMX transport, or by looking it up via JNDI. What is nice about JBoss is that mbeans can take part in the same transaction as J2EE components, so they are by extension tx enabled. Thus, the J2EE store of Slide would mingle just fine with a servlet who initiates a tx, then invokes an EJB that talks to several resources including the Slide MBean and finally commits the tx safely. Another considering later on would be to offer the Slide kernel, using the J2EE store, as a J2EE Resource Adapter, properly fitting it into the J2EE world as the original architects would have preferred. Thanks, James > > Thanks in advance, > -kevin > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
