Talkback
E-mail
Printer Friendly
Reprints
And, yes, you can debug the portlet as it executes in WebSphere. Mainsoft instruments the generated bytecode so that lines of C# (or VB.Net) source are properly associated by the debugger to the corresponding Java bytecode. In other words, while you single-step through C# or VB.Net source, it's Java bytecode that's actually being executed. You have to be careful where you set break points. While I was testing this capability, I occasionally caused WebSphere to interpret the paused process as an unavailable portlet.
|
|||||||||||||||||||||||||||||||||||||||||||
WebPoint ShareSphere
Where Mainsoft's Portal Edition connects ASP.Net to WebSphere, the SharePoint Federator brings Microsoft's SharePoint into
the WebSphere tent. The Federator is more or less a pair of premade portlet templates that are added to the Visual Studio
IDE when you install the Federator SDK. (Because the Federator SDK builds WebSphere portlets, to use it you must first install
Mainsoft's Portal Edition.)
The two portlet templates are the SharePoint List Viewer portlet and the SharePoint Item Viewer portlet. Put the pair together, and you have what amounts to a database browsing kit, the database in this instance being a SharePoint site. The List Viewer portlet provides a WebDAV-style interface into a SharePoint site's data. It lets you navigate into SharePoint folders and subfolders, and select content within those folders in the same way you would do when normally connected to SharePoint.
Select an individual file – a text document, say – and the Item Viewer comes into play. Though it is called a viewer, it is not limited to simply reading or downloading documents, but operates with SharePoint's check-in/check-out protocols. You can configure the portlet to either download a selected document, or allow the user to work with that document directly on the SharePoint site.
The core engine of the two portlets is the SharePointDataControl. This is an ASP.Net control whose design-time wizard lets you configure the portlets' connection details to a SharePoint server. The wizard also lets you fine-tune how portlets query into the SharePoint data, including which rows and columns are fetched in response to a given user request.
Finally, a critical adjunct of the SharePoint portlets is Mainsoft's Credential Vault Web Control, which can capture a user's SharePoint login information and store it securely in WebSphere Portal's credential vault. Using the Credential Vault Control lets you create a single sign-on experience; when a user signs on to the WebSphere Portal, then activates one of the SharePoint viewer portlets, the user's SharePoint login information is invisibly fetched from the vault. The user is securely logged in to the SharePoint site with no overt action required.
WebSphere portlets, no Java
From the developer's perspective, Mainsoft's technology is attractive mainly because it is so transparent. An ASP.Net developer
can create and deploy WebSphere portlets without having to lay so much as an eye on a single clause of Java. Better still,
that developer has at his or her disposal all the Web controls that Visual Studio makes available to ordinary ASP.Net applications.
Put another way, the developer's skills at ASP.Net are carried into the world of Java and WebSphere, and suffer no real loss
in the transition.
Mainsoft is in the process of building a remarkable edifice atop its .Net-to-Java translation technology. The tight integration of Mainsoft's WebSphere Portal and SharePoint Federator tools with Visual Studio lets .Net developers code for entirely new targets, all the while making those new targets look comfortably familiar. As Mainsoft annexes more .Net real estate, it creates a toolset that developers interested in enterprise-wide mashups should acquaint themselves with.
Rick Grehan is contributing editor of the InfoWorld Test Center.
