The Question:
The trickiest one is tool integration: how do you integrate non-Sakai tools into the framework? I know this is complex (probably why I put it off for so long). Are there recognised steps required to integrate a non Sakai tool. I know this also depends on the type of tool and what integration really means, lets assume for now that the tool needs to know enough about Sakai to behave like a native tool.
Of course, Plan B in all of this would be to write a portlet wrapper around the tool and just plug it in to 2. 4. Would this approach introduce any limitations on what could be integrated and the level of integration?

There are three options:
(a) Use the Rutgers Link Tool – this is a tool much like CWebProxy in uPortal – it allows a quick and tight integration into Sakai because it is very REST based and already provides all kinds of groovy Sakai session information so that tools can make call backs to Sakai web services. It has clever two-way certificates that allow very secure interactions between the tool and Sakai to the level that the external tool can submit grades (a very hard thing to do securely because it depends on a combination of user trust and server trust). It is high functionality and easy to use – folks can usually do simple integration in a few hours. The only downside is that it is Sakai unique. But it is the only high functionality choice since IMS Tool Interoperability is so weak.
https://source.sakaiproject.org/svn//linktool/
(b) Use the Sakai IMS Tool Interoperability Tool – Written by Anthony. This is a 100% compliant tool for IMS Tool Interoperability – to use it you must support SOAP. As an example SOAP is pretty crappy in PHP. See http://www.dr-chuck.com/csev-blog/000267.html for my whining about how hard this is. Anthony’s code supports Outcomes which are a weak form of grading – so weak that I would not use it – if I had to grades I would use the link tool. Anthony is also working on the producer end for Sakai for a demonstrator endpoint.
https://source.sakaiproject.org/svn//imsti/
https://source.sakaiproject.org/svn//imsti_target/
(c) Use the Sakai IMS Tool Interoperability Portlet – Written by me. This portlet is *not* 100% compliant with the IMS TI spec – there is no provision for the Outcome service – my opinion is that this is barely worth using in IMS TI 1.0 – I hope we fix this in IMS TI 2.0 and all signs are promising. By dropping the Outcome service I make it so that this can actually work in portals other than just Sakai (Sakai 2.4 supports JSR-168). I hope to have this portlet in good shape by the IMS Learning Impact conference in two weeks. I am also going to use this portlet to experiment with some IMS 2.0 ideas. Ths most important idea is to produce a simpler WSDL for IMS TI and a pure REST binding for IMS TI. These will make IMS TI much simpler to add to an application – these will be non-standard but I hope to feed this back into the IMS TI 2.0 work that Anthony and I are both involved in so I hope these approaches *become* standard in the future. I hope that in two weeks I have the following: (1) The portlet working in Sakai and uPortal (2) the portlet supporting IMS TI WSDL, IMS TI-Lite WSDL, and IMS TI-Lite REST, (3) sample code for PHP that supports IMSTI WSDL, IMSTI-Lite WSDL, and IMSTI-Lite REST and (4) Sakai supporting the producer-end of IMS TI-Lite WSDL so that we can use IMSTI-Lite WSDL to place Sakai tools in Sakai and uPortal. So this is cool but still emergent. If all goes well my IMS Learning Impact demo will be pretty cool – I will also show this at the Sakai track at the JA-Sig meeting in Denver in June. Both Anthnoy and I will be there and we will eb talking a lot about Portlets in Sakai in general.
https://source.sakaiproject.org/contrib/portlets/trunk/imsti-portlet/
I also have built a IMS TI WSDL Endpoint in PHP (oh the pain…)
http://www.sakaiproject.org/imsti-test/