Blue Fish: Kevin, can you give us some info about yourself?
Kevin: Sure.
- Official title: Group Product Manager
- Primary responsibilities: I am responsible for the general product direction for our developer tool offerings and perform the hands-on product management of 1)WDK, 2)ODBC Services, 3)JDBC Services, 4) Documentum Application Builder and legacy products such as Reporting Gateway, Rightsite and the eConnector for JDBC.
- Years with Documentum: 2
Blue Fish: What were the overarching considerations as Documentum set forth to re-engineer WDK?
Kevin: When I joined Documentum I was coming from a unique perspective, one where I was driving the architecture of an application server targeted at serving common content to a multitude of unique mobile devices. The situation at Documentum was in many ways converse – this challenge was to serve disparate content types, elements and applications to similar browser clients, but in a way that would make developers of C-Apps (content-centric and content-enabled applications) more productive. We then used our own development teams that were building Webtop, Web Publisher, Documentum Administrator, CIS, etc. as the initial requirements-driving force behind the extensible component architecture. After developing the extensibility model we correlated our internal requirements gathering with the feedback on previous WDK release and drove in the ease-of-maintenance features such as the control model (using JSP taglibs), customization layering (putting the extended components in an initial resolution layer) and maintaining the component definition and configuration via XML files.
Blue Fish: Were there any specific limitations in the previous version that became a focus for the product’s development?
Kevin: Absolutely. WDK 4.2, while being a solid product, was too intimidating and inaccessible for a majority of the developers out there. What I mean by this is that in the WDK 4.2 model most of the WDK code itself was resident in the JSP pages making it very Java-centric and also limiting the effectiveness of cross-component application changes based on this tight binding of UI and application logic. With WDK 5 we were striving to create a separation of tasks, presentation code and application logic in way that allowed delivered WDK-clients to be more easily configured and customized. In conjunction with the new Business Object Framework (part of DFC) we now have delivered a way of customizing the user-interface and application ‘events’ as well as controlling access to Docbase services and their invocation on a per content-type basis.
Blue Fish: What sort of formal and/or informal processes or methods for customer/developer feedback (if any) did you put in place before kicking off the re-engineering effort?
Kevin: One of the key things that I did as soon as I joined Documentum, was to go out and visit with customers to gain a better understanding of what they wanted WDK to be. I spent time with existing WDK 1.0, 4.2 and Rightsite customers, as well as time with those customers whom were building custom web applications. After a very short time it became immensely clear to me that what customers wanted was a solid framework, one that offered industrial strength capabilities and yet availed itself to easy lifting, in terms of the development work that went into being productive with it. Hence, the product you have today, was defined. It is not only the underpinnings for our web client development, but it also is a strong framework for delivering applications. You know there are a lot of interesting web frameworks coming on the scene today, you’ve got Microsoft’s .NET Web Forms, the Apache Software Foundation’s projects: Struts, Velocity, etc. and shortly their will be a JavaServer Faces specification that promotes the abstraction of event handling and what we call ‘application services’; things like session handling, localization, help systems, role services, etc.
Blue Fish: Have you received any early feedback from some Documentum customers?
Kevin: Yes, quite a bit, and all of it has been very positive. We have many customers already in deployment and are seeing average application customization projects, doing some pretty radical stuff to Webtop, ranging from 4-6 weeks. I believe that this is the most important feedback we have received. With prior versions of WDK and in other application environments, such projects have taken considerably longer. With one customer they have introduced a number of new components and extended our base webcomponents to make Webtop very ‘Workspace-like’ and this has been very weel-received by their users as they transition from Workspace to Webtop.
Blue Fish: That’s an interesting segue onto the future of Documentum’s support for both the web and client-server architectures. Can you tell us more about what lay’s ahead?
Kevin: Documentum is very committed to its customers and their success when deploying any Documentum ECM (Enterprise Content Management) solution. That said, we have heard more and more customers looking to move their users to web-based applications that allow for a closer to zero-footprint on the end-user workstation allowing for a lower TCO to each user’s application and system needs. In doing so, we are examining some unique new client-side application functionalities which will interface well with web-applications and still provide a rich integration to today’s most commonly used productivity applications. Similarly, on the server side of the equation we are working to introduce Linux support for our web-tier, which would allow for a lower TCO when deploying the servers that drive the web-based applications. I believe that Documentum is doing a great job of paralleling the trends that are emerging in enterprise application development and deployment.
Blue Fish: Can you tell us more about this new client-side application?
Kevin: Sorry, I need to keep some secrets in the bag for the next time we sit down together.
Blue Fish: What sort of feedback, if any, did you receive from your own internal development staff as they began to develop new applications using the new product?
Kevin: Our internal teams have been really pleased with the amount of ‘foundation’ that we have pre-built into WDK 5. In fact the Web Publisher, Documentum Administrator and Digital Asset Manager teams were overwhelmed at how efficient and focused this made their development effort. I was recently speaking with Arvindh Sabapathy, engineering manager for DA, and he was telling me that if they had to build all of these services, actions, controls and components themselves – and not as a development framework – he thinks that it would have taken them about 27 man months more time to deliver DA 5. So, you can see that we are not only working to ensure that our customers and partners are getting an ROI from using the product, but we are working to ensure that we are as well!
Blue Fish: Can you share some further details on the WDK implementation architecture?
Kevin: The WDK model is really based on the concepts of forms and controllers. Forms are defined to present a view or respond to an action, with that said you can see how our action and component controllers dispatch to forms (components) to provide the necessary UI to complete a transaction. In addition to this, WDK 5 makes extensive use of the new Business Object Framework, that’s now a part of the DFC. A major part of the new BOF is the SessionManager, using this you can share an authenticated session across several applications that are running off of a common DFC instance. In other words, when any component class is being invoked directly by navigation or indirectly as the result of an action the component class calls its local service method which communicates with the session manager to perform the transaction under the correct user profile. This has alleviated a lot of the work that we had to do in the past to manage sessions creatively on the application server.
Blue Fish: What is the best way to login to the docbase in a proprietary fashion, but use the wdk model and view classes?
Blue Fish: Extending the existing Login component to pickup authentication credentials from the existing user’s session. This infers that you will have at least one authentication mechanism within the application. For example you could create your own Login component which pulls an encrypted (hopefully) userid and password cookie from the request that the user has made for a WDK component. My recommendation for better performance, however, would be to embed the WDK component library in your application so that you can set an HttpSession attribute to contain this data, rather than passing it back and forth for each request. This would immediately carve out the HttpRequest parsing, thin out each HTTP request by a few bytes and also ensure that existing authentications timeout; objects bound to HttpSession’s get destroyed whenever the application’s session timeout setting is reached, whereas with a cookie you must implement this behavior yourself.
Blue Fish: Are there versions of WDK where the source code to the components, controls and actions are available? Will there be? If not, will DCTM consider making the critical fields which are now private, at the very least protected so that they can be extended and used?
Kevin: As it stands today we are providing the component source for the webcomponent components. I am sure you’re next question is “what the heck’s the difference?” Let me offer an explanation: The components that we are including the source to and calling webcomponents are those which are generic in nature and will be surfaced in multiple applications (e.g. Login, Properties, etc.); those which fall under the webtop components title are those which are unique to the functionality of that application and will continue to be delivered in only a binary format to prevent compromise of our competitive advantage in the marketplace. However, since the majority of components are in the webcomponent library and developers have access to the JSPs for both sets of components, I feel that it’s pretty easy to understand what’s happening behind the scenes to make a component run.
WDK applications are sandboxed. This is so that each application, and version thereof, can present the appropriate components without having to work with some complex versioning API. I mean, imagine if you took one of the most commonly customized components like ‘Search’ or ‘Properties’ and kept creating incremental versions that added/subtracted functionality and had to remember which one you wanted to use in each application based on a version number? That could prove to be a nightmare. To alleviate the complexity of using an API to manage component invocation we’ve decided, at least for now while we are still observing the usage patterns of WDK 5, to use the physical packaging of components to govern what components get invoked from an application.
Blue Fish: There are many java web developers who are familiar with other web architectures, for example the STRUTS framework from the Apache Jakarta project. Will DCTM ever consider writing a justification of their design issues and the advantages of using the WDK framework for web applications vs. other more standard frameworks?
Kevin: Yes. Indeed we already have written one and will plan on covering such material at this year’s developers conference (June 10-14, 2003). In fact we have even had organizations write integrations between the WDK and Struts frameworks to meet the needs of their users and developers alike. The big differences that we call out are localization of actions to individual components so that updating of an application is a less onerous task and that such dependencies are localized to a module or region of an application rather than global to its entire presence. We have had many customers compliment us on this design difference since it makes it easier for new developers to join a team, become productive and feel comfortable that the changes that they make to an application are more manageable and easier to test.
Blue Fish: What Netscape client is the DCTM team aiming at with their releases? Netscape has presented issues for the WDK in 1.01, 4.x, and 5 beta, are we moving toward an Internet explorer-only application?
Kevin: Let me take the second part of that first: We are not moving away from Netscape at this time. And it’s not that I don’t like Netscape, it’s just that they are releasing far too many versions at the present time and they are only fixing major issues with new releases – making support for both Documentum and it’s customers a real nightmare. I mean look at the situation we had with the JavaScript implementation in Netscape 6. It was pretty rough in Netscape 6, then fixed up in Netscape 6.2, which by the way is the version that we will support with our WDK 5.1-based products, and now there are several other issues cropping up with Netscape that are only being fixed in Netscape 7. This would mean that to stay up to date with Netscape, Documentum would need to go back and retest a bunch of products and platforms while customers would have to go around and update everyone’s browsers. I just can’t see this being desirable or sustainable for either party. Who knows – maybe things will settle down and Netscape will become easier to support in the future. As for Internet Explorer-only, this can’t happen until they have 100% of the market. Anyone for Opera?
Blue Fish: It seems that many of the original WDK architectural decisions were made to mimic RightSite architecture, and this has stuck even through wdk5. Are there any planned future versions where the backward compatibility is sacrificed in order to re-architect the application flow or take advantage of new technologies?
Kevin: I must admit that I don’t see much Rightsite in WDK. At least from my perspective. No, I think to answer your real question – we will never throttle WDK based on previous-generation functionality. WDK has provided to be an easy migration based on its standards-basis, Java and J2EE. WDK also implements a lot of the functionality that was missing from Rightsite and thus forced the customizations that were done. However, we will in WDK and all of our products continue to provide a very concerted focus on making it easy to migrate and provide backwards compatibility for our products. Case in point: WDK 5.1, Webtop 5.1, DFC 5.1 and so on are all backwards-compatible with 4.2.x versions of the Content Server. This way customers can migrate either the docbase or application individually and not be forced to do both at once.
Blue Fish: What is the future of the J2EE compliant wdkSpace, as .NET takes hold in the industry?
Kevin: Lets not talk about wdkSpace. Nice idea, bad result. Webtop is the way of the future – get on board now!
Blue Fish: Does Documentum intend to write a WDK best practices and/or WDK design patterns document? The documentation out there explains how WDK works but there are sometimes multiple ways that a task can be accomplished; navigation and error handling are two examples.
Kevin: Yes, absolutely. This is one of my current pet-projects and I am actively working with customers to gather enough data to provide a useful document that will help expedite projects and stear developers away from troublesome patterns that can hamper scalability, migration, etc. Stay tuned.
Blue Fish: Is there anything you didn’t address with this release that you definitely want to address with future versions?
Kevin: Absolutely! It’s a pretty long list – but here are just a few:
- IDE integration – We are currently redefining the role of Documentum Application Builder and at this point we believe that it should include a visual development/customization for use with WDK.
- Portal/Portlet functionality – Envision the streamlined components running in a portal. What a thing of beauty.
- Better Plugability – Currently we are evaluating a content transfer model which would allow developers to implement their own component to do content transfer and also to screen in their own client-side script. These are the two greatest challenges that we face when we try to support a variety of client platforms. And as users want to integrate WDK into more internet-facing applications, this is going to be a must.
Blue Fish: Are you telling me that there are applications on the internet that are exposing WDK components?
Kevin: Yes, indeed. One of my prouder moments. And they are performing quite well from both an end-user functionality and performance standpoint.
Blue Fish: Anything else you would like to add?
Kevin: Yes, I’d like to encourage anyone with an interest in the future of WDK to get in touch with me and my team by sending email to wdk_info@documentum.com. We’d love to hear about your successes, challenges, and where you think the product should go in the future. And thanks for providing me with the time to espouse on the latest web development technology from Documentum.
