As long as we are talking about Java client/server technologies and POE, I'd like to expand the topic slightly to include IPC, namely JMS.
Has anyone ever created a JMS bridge to POE? Where I work all the Java people now use more of JMS than RMI. I figure it would be easier to figure out than RMI, because it's not invocation, just messaging. It might work better and be more useful than RMI, considering the services that POE could provide in such a solution. There is a POE::Component::Spread, and Spread has a JMS4Spread implementation, but I don't know if these two parts could be hooked together successfully. It might help me make more Java developer friends if I could start to service their JMS requests from POE. They may not even be able to tell that they are getting data from a Perl server instead of a Java one (that would shock them good.) - MW -----Original Message----- From: Erick Calder [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: RE: RFC: Persistent Object Client/Server Scheme if what you develop is a perl RMI interface, POE programs could be written to interoperate in Java environments, allowing those of us who prefer it to code in perl rather than Java. I see that as big positive :) -----Original Message----- From: Phil Crow [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 6:11 AM To: [EMAIL PROTECTED] Subject: RE: RFC: Persistent Object Client/Server Scheme Since some discussion has started I think it is time for my true confession. Though I love Perl, I am really mostly a Java programmer. My intent with the project I mentioned is to provide schemes like Java has, but with a heavy Perl spin. With them I might some day convince my employer that Perl is ready for prime time. While I think Perl is ready, they don't see it, hence the need for more tools. In this case the scheme is RMI (Remote Method Invocation). In case you aren't familiar, I'll bore you with details. An rmiregistry daemon keeps track of all registered rmi services on one host by name. As service daemons start, they register. When a client asks the registry daemon for a service, the daemon connects the two. This allows the client to make calls on persistent objects in the remote registered service. The protocol is proprietary (but published) and travels over TCP sockets. So, my current scheme is RMI for Perl. The clients instantiate remote objects and use them without worrying about event call backs. Simply say $result = $remote_objet->method(@args). The servers use POE, but without having to think about it. This means (among other things) that the exposed objects don't explicitly know they are exposed. This creates modularity since the same code can be used locally or remotely. The primary purpose for an RMI like scheme is to allow separation of application components across servers (what patterns people call layering). That's what the current project allows. It does so with simplistic API's. My goal is to eventually provide the kinds of functionality that has made the Java platform successful without introducing the unPerlish complications that dominate the Java frameworks. In this case that means no rmic (rmi compiler), no interfaces or stubs, etc. It also means a clean Perlish set of support modules. Currently there is a server module, a client module, and a registry daemon which just uses the server module. Thanks for all comments so far. I'm interested in hearing more and in working with anyone. Now back to my Java programming job :(, Phil Crow __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
