users@glassfish.java.net

Re: JCA Connector for deployment in glassfish

From: <glassfish_at_javadesktop.org>
Date: Tue, 12 Oct 2010 11:44:57 PDT

Thanks for the pointer. I've made some headway relative to creating and deploying a JCA resource adapter and a java bean that implements a "message listener" interface.

Let me summarize what I think I've learned. This may help others but I'm also hoping to stimulate some ideas/suggestions from the experts. For example please redirect me to an alternative solution if indeed JCA sounds inappropriate for my task.

Let me start by describing the end goal:

Goal: Creation of a web framework that will faciliate in the control/monitoring of one of our home-built (non-java) systems. In JCA terms I'd refer to this home-built non-java system as an EIS. I'll refer to this homebuilt system as HBEIS (home built EIS).

EIS Interface Details: An instance of our HBEIS system publishes its status to a multicast group/port. Also the HBEIS listens for control messages on a different multicast group/port. Different instances of the HBEIS might use different multicast addresses.

Initial Consideration: Use JCA to build the java components that will receive status messages (via UDP multicast) from home-built EIS. Towards this end I've been reading through the JCA Specification found here <a href="http://java.sun.com/j2ee/connector/">http://java.sun.com/j2ee/connector/</a>. I've actually downloaded and been reading a 1.6 spec.. However this link seems to reference 1.5 as the current latest (perhaps I've been reading a draft of a not yet accepted release).

Steps Accomplished:
1] I created a resource adapter. This does not use the @Connector annotation since indeed I'm looking (as a starting point) as an input only mechanism that would accumulate status from multiple instances of a HBEIS. (I found an e-mail example in the J2EE baseline, however this was more complicated that I wanted as a starting point since it addresses a full bi-directional resource adapter). There were not a lot of other examples that I found online. This one did help me however: <a href="http://www.ibm.com/developerworks/websphere/library/techarticles/1007_klinger/1007_klinger.html?ca=drs-">http://www.ibm.com/developerworks/websphere/library/techarticles/1007_klinger/1007_klinger.html?ca=drs-</a> Search for "downloadable archives".

2] Deploy the resource adapter to glassfish. As part of this I used several debug tools to get to the point where I understood the interactions between glassfish and the resource adapter. Specifically I logged debug messages within the "start", and "stop" methods of the resource adapter. Once I debugged my ra.xml file then voila I was able to deploy the ".jar" file containing my resource adapter to netbeans and see the start method debug message in the glassfish server.log file (found under domain1/logs). I would have preferred deploying a ".rar" but I still dont know how to tell netbeans to build a ".rar" instead of a ".jar". Glassfish seems ok with the erroenous ".jar" extension.

3] Now I jumped into building a "message driven bean" that implemented a "message listener". This message driven bean (once successfully deployed) is passed to the resource adapter through invocation of the resource adapter endpointActivation method (again a good method to drop some diagnostics into). Successful deployment of my MDB was again a real task particularly in the context of nailing down working deployment descriptors. My bean currently includes two descriptor files: "ejb-jar.xml" and "sun-ejb-jar.xml". The latter the one that must include a reference to the resource adapter (using the mdb-resource-adapter tag). Interestingly for the couple of hours I struggled with deploying my MDB I actually had an appropriate sun-ejb-jar. The issue I ran into is that because I used netbeans "in-place deployment" on the resource adapter jar, the glassfish server did not seem to recognize that the resource adapter was deployed (at the time that I tried to deploy the MDB). I eventually figured out that as long as I first deployed the resource adapter jar as a "production deployment" then the MDB that referenced this resource adapter would find it. So lesson learned (be wary of the netbeans "in-place deployment").

4] Now that I am able to see the message listener MDB registered with the resource adapter (via endpointActivation method), I went ahead and used the BootstrapContext provided by glassfish to the resource adapter (via start method) to get a reference to the WorkManager. I used the WorkManager to start a worker thread. Currently I'm calling this worker thread PollingThread (just as in the e-mail sample). However its not clear to me that this thread should poll for status messages from the HBEIS status port, or if the MDB should poll this port. I'm currently thinking that the PollingThread in the resource adapter might poll one or more ports for one or more HBEIS, and then on receipt of a status message this message would be passed to the MDB "onMessage" method. Does this make sense?


Ok at any rate this has been sort of verbose. I wanted to start to capture my learnings/mistakes in the forum to help others past this hurdle.

If you have any expertise in JCA please provide some guidance. Right now my biggest question is "is JCA the right way to go for this type of status/control interface". Is there an alternative that I should be considering? Assuming that JCA is a reasonable way to go please provide more guidance relative to a reasonable design for an "inbound only status processor" (one that needs to monitor multiple ports - one per HBEIS - and eventually to drive the status into a database). I was assuming that my resource adapter polling thread would monitor ports and then deliver this data to an "onMessage" method within an MDB. This MDB could then deliver the data to a mysql database (also part of the monitoring framework).

Thanks in advance for any further advice.
[Message sent by forum member 'dsargrad']

http://forums.java.net/jive/thread.jspa?messageID=484977