On Tue, 2004-09-21 at 17:26 +1000, Robert Collins wrote: > On Tue, 2004-09-21 at 16:09 +1000, Andrew Cowie wrote: > > Quick survey: I'm building something that requires a lot of two-way > > (message/event) traffic between clients and servers, and could use some > > help picking a technology. > > Well, in my consulting days, when a client asked me an open ended, > unqualified question like that...
Yeah, yeah. Ok, so I should have provided more context. I've chatted about this project with a few of the SLUG people that I see on regular basis, but for the rest of the mailing list: One part of my work focuses on managing massive changes & upgrades to mission critical systems.[1] I'm writing a tool to help me with that. Specifically: Right now, many of my clients do their procedures in clunky manually generated [paper] documents, but when a group is working through a procedure around a specific point event (say, replacing all the networking gear in your datacenter) there is an intense need for the people involved to collaborate and coordinate their activities. In essence, the problem is one of merging structure (the procedure to be run) and sequence (enforcing the fact that although a hierarchical document, it actually involves a carefully specified sequence of events, and that order must be enforced). See [2] > Are there other constraints, like the use of a specific programming > language on the client or the server, or a specific client or server > platform? No, not really (well, ok, it's not mobile devices - it's a client/server application), Trying to work my way through the various option spaces so as to make these choices has been quite the nightmare (er, "learning experience). I've made good progress, though. I actually gave a presentation about this last weekend... anyone who is interested and still reading is invited to have a look at: http://www.operationaldynamics.com/reference/talks/WelcomeToMyNightmare/ [Summary: I'm working on and for Linux, in Java + gcj, writing a GTK/Gnome app, and Berkeley DB is the back end data store. Wondering what the heck is up with all that? Follow the link, doh! And yes, It'll be open source] That presentation concludes with the specific technical problem that led me to start this thread in the first place: I am trying to decide on an appropriate middleware technology for a problem with these aspects: * Relatively small groups (5-15 people, typically) so low message volume. * Participants are distributed in space (some in the data center, some in the office, vendor reps, contractors, and specialists may be external) [so a solution that works reasonably well across complex network boundaries would be useful] * Events leading to messages, however, are extremely close in time (I check that I've done a step, you check you've done the step right next to it, we both need updates, happens in the blink of an eye, can't loose time from polling cycles ). * Very high consequence if things get out of whack (team is updating a mission critical system, yo!) so don't want to loose messages or history of progress through the sequence. Updates are idempotent, though, so receiving a message twice isn't a problem, which seems like it should help. Last weekend, Ben Ellis suggested to me that I consider XML-RPC. I don't think that's the solution to my problem, but man, what a clean API [3] Julio's suggestion of leveraging Jabber is really intriguing. Stewart Smith made a similar recommendation to me a few months ago, which I'd forgotten about. So, thanks Julio! There were a lot of typically murky complex Java APIs out there, but I found one which seems really straight forward, [4]. If I go down this road, could either build the server as an independent Jabber client, or hook it into a Jabber daemon as a Jabber component. Not sure the pros/cons of that yet... > Funny thing jumped out at me here... I was taught about oop in terms of > message passing: there is no conceptual difference between passing a > message and a 'remote object invocation'. Yeah. Indeed, I don't need the remote object part - I have the data model well under control. I just need to pass events. [yes, of course, a Remote Entity model DOES do what I need - just seems overly complicated is all] Given the relatively small size of the groups involved here, polling doesn't create a resource constraint issue, but it is inelegant at best, and certainly doesn't scale. No, the only real trouble that I can see is that in the wider public network context, the firewall problem gets in the way - clients can connect outbound to some server on the net, but (especially in an HTTP paradigm) the other direction doesn't fly. (oh, sure you can pass messages in response to a poll, but you can't initiate). I don't think I want to write something that is constrained to the immediate LAN only. Onwards and upwards, AfC Sydney [1] See the teaser to the tutorial I gave at AUUG for some idea of Massive Changes and Upgrades are about: http://www.operationaldynamics.com/events/past/MassiveChangesAndUpgrades.php [2] I have an extended abstract for a paper I'm writing about the Merging Structure and Sequence problem. I posted it here (234kB PDF) if you're interested: http://www.operationaldynamics.com/reference/talks/WelcomeToMyNightmare/MergingStructureAndSequence_Abstract.pdf [3] XML-RPC implementation in Java. So simple! http://ws.apache.org/xmlrpc/client.html [4] A Jabber client API in Java. Also really clean: http://www.jivesoftware.com/xmpp/smack/ -- Andrew Frederick Cowie OPERATIONAL DYNAMICS Operations Consultants and Infrastructure Engineers http://www.operationaldynamics.com/
signature.asc
Description: This is a digitally signed message part
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
