From: Brian P. C. <bm...@bm...> - 2006-05-05 11:34:25
|
I have to disagree here. The IMS TI is flawed in concept (unless you really morph the concept). WSDL Web services are the result of a long painful process towards interoperability. They are not perfect, but they're the best that we've got. Anything you place in the space between consumer and producer must not diminish the interoperability. This is what the TIR would do by bringing in the requirement to be involved in extra Web service conversations. (It would also introduce loads of extra tiresome work for developers.) My next point is that all the aims of TIR can be carried out from the WSDL. There will still be a lot of out of band stuff to sort out with anything but the simplest services - but sort this out another way - another deployment descriptor (the WSDL is a dd, too) won't supply the answers Space on the client side is precious. Tracking and logging projects might want a widget on the client side. Reliable messagers might want one. Security might want one. Transport adapters might want one. Data transformers might. So rather than have a raft of client-side widgets building up, best to have a widget that is a configurable multi-tasker. This is essentially what JBI does - it's a beautiful spec and almost every JISC Web service project should be using it, I respectfully suggest. The JBI container reminds me of the Borg Collective. Cut orff from the Hive, a Borg still has functionality, but plug in to the Collective and that's where the real power lies. The Borg entry in the Wikipedia is interesting: "..their relentless pursuit of what they want to {HYPERLINK "/wiki/Assimilation_%28Star_Trek%29"}assimilate, their rapid {HYPERLINK "/wiki/Adaptation"}adaptability to almost any defense, and their ability to continue functioning after what may seem a devastating or even fatal blow seemingly unaffected." Change this just a bit and you have the qualities of an enterprise service bus - assimilation of diverse applications, adaptable interfaces, and limited self- healing properties. The ESB as Hive. The JBI containers as drones. The Queen might be JMX (or the service registry). So, having JBI containers attached to service nodes is a good starting point for ultimately creating a management structure using JMX which would allow remote configuration of the Collective, er.. bus. This might seem flippant, but there is a strong analogy present. Regards, Locutus of Bus On 5 May 2006, at 08:49, Adam Marshall wrote: > > > Bodington would certainly like to be able to include Sakai tools, > > so yes, > > that does sound interesting. > > > > Was it your intention to use IMS TI as a framework? > > > > No! Our view of IMS TI is that the best thing about it is that it > exists. > > By that I mean that the problem of how to get portability of an > _application_ rather than content between learning management systems > is being addressed by open-source and commercial suppliers. The > version 1.0 does very little that is useful, but it is a start. With > it we will be able to test the concept that a specialised application > we may develop for teaching modern language say, can be taken by a > Bodington University or a Blackboard University or a Moodle > University or a WebCT University and be run without major integration > issues. > > If this turns out to be something people want to do a lot, we expect > a lot of development of the specification to make it more useful. I > would almost call it a research prototype of a spec. > > Another issue is that we don't know how engaged Blackboard will be > now they have merged with WebCT. They may take the view that Chalkbox/ > PowerLinks now has critical mass not to need interoperability with > other (competitor) solutions. > > John > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |