IBMs Bisconti: Under the Hood with IBM Workplace

 
 
By Steve Gillmor  |  Posted 2004-05-14
 
 
 

IBMs Bisconti: Under the Hood with IBM Workplace


When IBM shook up the collaborative desktop with its Workplace cross-platform, rich-client strategy, the reverberations were felt all the way from Redmond, Wash., to Silicon Valley.

In a conversation with eWEEKs Steve Gillmor, Ken Bisconti, vice president of Lotus Workplace technologies at IBM, details Big Blues new client middleware stack.

Whats the goal of the Workplace client?

When we started talking about the Workplace strategy, a key goal was to provide an integrated platform for collaborative services and a consistent user experience to basic browsers, to mobile devices and also to a rich-client experience.

We werent going to build just a fat-client/rich-client experience like Outlook or Notes, but in fact we were going to carry this componentization model forward on the client side as well.

Were trying to marry the low-TCO, centralized-management qualities and ubiquitous access qualities of traditional Web apps with the rich-function offline support user experience and other qualities of traditional thick clients.

And were doing this by using the model of client-side components with dynamic provisioning technologies and a number of services that we provide.

Some of them are similar to Notes services such as data storage, replication, etc., but there are also many expansions beyond the early Notes model—much broader programmability model, more extensive data-storage capabilities, more openness throughout the stack we provide, and again, not using the traditional thick, fat-client model but using the latest in dynamically provisioned client-side components.

For more collaboration coverage, check out Steve Gillmors Blogosphere.

Are these services delivered via Java applets?

No, think of a relatively lightweight middleware stack on the client which consists of a runtime environment—a mini-app server if you will—thats based on some services we get from our WebSphere Everyplace colleagues.

It was originally called ASWE, or Extended Services for WebSphere Everyplace, and it consists of a J2EE container and a J9 runtime, and some things for running Java and J2EE applications.

It includes a Cloudscape data store, a relational lightweight embedded relational store that we acquired when we bought Informix [Software] but have developed forward.

Read more here about Cloudscape, a 100 percent Java database.

It includes provisioning technology both from Tivoli as well as from the Eclipse effort, and also bidirectional replication based on SyncML—using Notes-quality replication methods but based on a more open SyncML method thats also more conducive to synchronization with non-PC devices. And then on top of that, we deliver a user experience and a programmability and extensibility model based on top of Eclipse.

Eclipse was started by IBM but handed down to an open-source consortium. It was originally developed for rich, development -oriented Java IDEs, and its been a very successful project—over 20 million downloads of the Eclipse toolkit, hundreds and hundreds of plug-ins available, and lots of key tier-one ISVs that have built IDEs based on Eclipse.

But over the past couple of years, thereve also been efforts—one of them called Equinox—to recognize the Eclipse environment as a pretty attractive runtime environment as well, not just an environment for building programming tools.

So, weve capitalized on that, and were using Eclipse in the foundation here to provide a programmability model which is much more flexible and broader than what we have done on the Notes side. It supports Java, J2EE, even .Net, C++ applications—and includes a component model for building cross-platform components. Weve used this platform to build some embedded editors that run on Windows and Linux and whatnot that are OpenOffice-derived.

Compared to old models of Java clients, where you were left to the lowest-common-denominator widgets or functions based on what was able to run cross-platform, Eclipse is much more pragmatic.

It allows you to reach down into the bowels of an OS and call the GUI through Windows GDI interfaces. I can run this on XP and get the look and behavior of XP, I can run it on a future Longhorn and get an Avalon look and feel, I can run it on Macintosh and get a Carbon look and feel, etc.

On top of Eclipse, Cloudscape, the synchronization engine, the provisioning and app runtime, we also provide a number of services—the typical things youd expect Lotus to do with instant messaging, presence awareness, e-mail and calendaring.

Were building document services with embedded document editors—word processing, spreadsheet, presentation tools, etc. —and were building this out as an enabling technology that can be used not just in Lotus Workplace products but all across IBM and IBM partners.

Click here to read more about IBMs new server-based software model.

We will deliver this quarter reference applications using this enabling framework—Workplace Messaging and Workplace Documents. When instantiated in the rich-client mode, you get a richer e-mail experience, offline support, a Notes-quality e-mail experience.

Optionally, Workplace Documents uses the Cloudscape store to create and manage documents on the desktop but then trickle-synch them back to a server to be managed, encrypted, access-controlled, etc.

We integrate and will launch Office editors directly and let you use those natively, or you can use the embedded, OpenOffice-derived editors that we provide as part of the technology stack.

Next page: Forking OpenOffice.

Forking OpenOffice


The OpenOffice editors are essentially the same base stack that Sun is using with the Java Desktop System?

Technically, no. They were derived from the OpenOffice project, but we forked away from that over a year ago. We componentized them and tried to slim them down a bit, and we also added a whole bunch of fixes and features and cleaned them up.

We will not advertise these as OpenOffice editors; we will be clear that they are OpenOffice-derived and they will support OpenOffice formats, and we encourage people to use OASIS and OpenOffice doc formats in addition to Office ones.

Its very important to communicate that this is not a StarOffice play. Were not positioning this as an Office competitor orb as a take-on-Microsoft play.

Nor are you positioning this as a competitor to JDS?

No, were not. In fact, early on, we had some analysts who worked with us under nondisclosure, and they specifically said, "Whatever you do, dont do an anti-JDS play because that basically has not worked with customers."

Its a message of, "Customer, you made a stupid decision at one point, and youre going to have to go let us help you change that bad decision you made," as opposed to providing additional services and added value around existing editors people may have.

Lets say you just had an Office environment today. But if you wanted to add Workplace documents to that environment, you now have a managed store trickle-synched back to a managed server environment where end-users can create or store documents.

Those are automatically backed up, shared, access-controlled, can be part of business controls and reporting, you can have corporate policies enforced, you can have access to multilevel storage and the whole enterprise content management set of services that IBM and other provide, if you so choose.

Well also use this technology to power things like WebSphere Portals. The next version of WebSphere Portals will take advantage of this technology for offline portal application support.

Well be using it in IBM industry solutions—for example, weve already started working in banking on a Bank Branch Office Transformation solution. And weve already started working with some ISVs—Siebel, PeopleSoft, Adobe and a bunch of smaller-tier ISVs.

Are there any aspects of IBMs J9 JVM code that are not compatible with the Sun JVM?

I dont think so. The team has worked with Sun on this for some time. To give you an example of how compatible it is with other environments, Siebel took an application that was 90,000 lines of Java code, and in less than a week, they brought it over for mobile use.

They only had to change 20 lines of code out of 90,000, to basically take a server-based Java application to a client front-end running on top of this J9 JVM.

Next page: Its not your fathers eSuite.

Not Your Fathers eSuite


In the Notes days, Java applet components required being downloaded to the client each time they ran …

Thats not the case here. If you see anybody comparing this to eSuite and things like that, were not building a Web-based desktop suite or any sort of network-only approach to this. In fact, the whole idea is that were leveraging a combination of using code that is resident on the device and smartly provisioning that as needed.

On the back end, were using the portal technologies from WebSphere Portal to manage, configure and provision the users, and we effectively build the desktop for a user at the server and stream down to them an XML data stream we call RCPML—Rich Client Platform Markup Language—that sends down XML data as well as tags for components.

The client knows if theres a component tag sent to it, it can go fetch the component as needed. Once youve provisioned the client for the first time, the whole environment and any new applications, etc., are always kept up to date and managed the same way that I would push down a new rev of a Web application.

RCPML sounds somewhat similar to XAML on Longhorn.

The idea is similar, that theres an extended markup language that also supports software componentization.

Is the data itself encrypted?

Yes. Weve based the storage on this Cloudscape encrypted store, and it supports sophisticated user-access controls. In the next version later this year, were also planning to add some additional control over editors that are used to manipulate documents in the store.

On top of access control and encryption, we also have heard from customers the desire to be able to control what editors are being used on content: Even if I have access to it, I want to additionally signature-check the editor and make sure somebody didnt compromise my Word 97 editor, or I might just want to set some ground rules that at Corporation X, we only support Word 2000 and Adobe Acrobat.

Where is the code that determines intelligently whether Office code is used if its available on the client?

Thats on the client. The administrator can control what editors people are using, but the default is that the end-user can decide whether to use the embedded editors or the operating systems default editors, which are likely going to be Office.

Does this have the same kind of speed hit that Word has when loaded as the messaging editor with Outlook and Notes?

Certainly, theres a speed hit when you first launch it, but its not that significant. And to be perfectly frank, this is the beginning of a multiyear journey for us. What were showing and demonstrating and shipping in the first releases this quarter are the first exercises of this programming model, and there are loads and loads of things that are going to be on our plate to go add to this.

But the most important point here is its changing the model of computing for rich applications, employing—arguably for the first time en masse—a server-managed client model where Im using dynamically provisioned client-side components in a holistic computing approach.

Youre not sending down code so much as XML constructs that trigger templates on the client?

Thats exactly right. For the most part, in a typical end-user experience, theyre just sending back and forth XML data streams. Once in a while, you may run into a new calendar-picker component or something thats been updated, so that gets streamed down to you, but for most common usage scenarios, youre not going to be downloading components every day.

Next page: Digging into Sametime and QuickPlace.

Sametime and QuickPlace


Will the IM and presence code ship with the Messaging client?

Yes, there will be presence, awareness and IM built into both the Messaging and the Docs solution. We wont have full-blown conferencing or team spaces yet in the first version, but youll see that in the second half of the year.

Are team spaces based on the QuickPlace constructs?

Yes, we shipped the first release of shared team spaces in November, based on the QuickPlace/eRoom metaphor and built on the J2EE/DB2/Portal stack in Workplace.

Its not using the underlying Domino code?

No. We have continued to improve the ability to surface Domino applications and QuickPlace, etc., as native portlets inside of WebSphere Portal environment, and we made a very significant improvement to that application portlet last quarter.

Click here to read more about IBMs efforts to bring Domino and WebSphere closer together.

How does that relate to this project?

It relates to it only in that we are fundamentally on a path of converging the Notes/Domino-based technologies with Workplace. One example is the work that were doing on the Domino side to surface Domino data and applications through WebSphere Portal-quality portlets.

Another example is that in the Workplace client technology, weve used the Eclipse framework and the SWT [Simple Widget Toolkit] controls that are part of Eclipse to make Notes available as a plug-in into this Workplace client environment.

In the Notes 7 timeframe, first quarter of next year, a Workplace user could be using Workplace Documents and Messaging, and then also bring up Notes applications run fully native against Notes DLLs and EXEs in a window in a plug-in inside the Workplace client environment.

Whats the migration path for the Domino Designer client? Whats the tool for constructing and provisioning these Workplace systems?

We recognize that theres a spectrum of tool needs that range from power user to professional developer. The professional-developer angle is pretty easy—right now, you can use Eclipse toolkits like WebSphere Studio and others, and some of the Rational toolsets as well, to build components that can be used in this environment. The power user can surface existing applications through Portlet Builder and those kind of tools.

Were also including a new tool in Workplace called Workplace Builder—a visual QuickPlace-like, Web-based environment where a power user could tailor a team space or a document library.

Going forward, it will become an assembly environment for assembling components that were created either in tools like WebSphere Studio or the upcoming Workplace Designer tool that youll see in the second half, that will be more on the order of Domino Designer in serving a VB/Domino audience.

Will that be entirely server-based, or will it include provisioning and design capabilities for the new desktop client?

Ultimately, it will have both. I dont know yet what will happen in the second half. Ultimately, our goal is to be able to build an application and choose selectively whether its provisioned and accessed straightforward from a browser or provisioned and accessed from a rich client as rich-client-enabled.

Next page: Spanning reach to rich.

Spanning Reach to Rich


Thats been the struggle Microsofts been going through for years. "Ultimately" is either a long time or it never happens. If your strategy achieves a critical mass, theres going to be significant pressure to customize these rich-client applications.

Its still to be determined exact timeframes, how that will come to be. Our goal is to build applications including portlets that you see in portals like WebSphere Portal, that can run both in a connected Web mode or in a disconnected offline or ported onto the client mode.

But you dont have that capability today?

No, and to be clear, the Workplace client technology is going to first see the light of day inside of these two products—Workplace Messaging and Workplace Documents—this quarter.

Were working feverishly to make it available as a more general SDK and toolkit for ISVs and corporate developers in the second half. We have a couple dozen design partners who are working with us now to really flesh that out, to harden that API, and to build forward an SDK.

At that point, youll be able to stitch together presence and information in an application that intelligently responds to incoming data from, say, an RSS stream?

Yes, thats correct.

What about RSS?

Whats interesting about this framework is, it will enable a whole host of additional collaborative capabilities that we have not brought to market yet.

For instance, theres a research project that we were demonstrating in several labs at Lotusphere called Activity Explorer, where we pulled together in a project or whatever navigation metaphor you want to use, all different types of data: things ranging from an IM chat log to a document to an e-mail thread, all in a consistent navigation model.

If I want to now bring somebody else into my project, I just drag them off the buddy list or the presence awareness window, drop them onto one piece of the hierarchy in that navigation structure, and instantly Ive provisioned them access to that part of the project or the activity.

Already, our R&D team has built that on top of this Eclipse-based framework, and we fully expect that now, this open-source, Linux-supporting open community can start to build Eclipse-based plug-ins to this framework, and plug in all kinds of things: blog creators, RSS tools, etc. etc.

That stream could be emitting an RSS feed as well.

Of course.

I dont hear anything about peer-to-peer between these clients. Is that on the drawing board?

Its certainly something that can be done. Colligo, one of the partners endorsing Workplace partner technology, has peer-to-peer technology that theyve used to augment Notes in some situations.

Theyve already started working with the Workplace client technology code to see how they might do to augment what were doing with some of their unique technologies.

To read more about Colligo syncing with IBM Workplace on database replication, click here.

It appears that youre finally rejoining the collaborative universe.

[Laughing] Rejoining! Hopefully, were helping to define whole new opportunities for the collaborative universe.

Check out eWEEK.coms Messaging Center at http://messaging.eweek.com for more on IM and other collaboration technologies. Be sure to add our eWEEK.com messaging and collaboration news feed to your RSS newsreader or My Yahoo page:  

Rocket Fuel