Windchill UI development technologies

 

Contents

• Introduction
• The 90/10 rule and blackbox/whitebox abstractions
• A little history; Applets, Templates, DCA, JCA/WCA, Info*Engine
• Applets and template processing
• Info*Engine
• DCA – What went wrong?
• JCA aka WCA (Windchill Client Architecture)
• Other technologies; XSLT, Cognos etc.
• Conclusion 

Introduction

Windchill is 10 years old! It was one of the earliest Java enterprise applications and now is one of the largest. The base of Windchill is one of its core strengths, 100% Java with and very strong client-server architecture and a unique Object Relational Mapping technology which only now has been equalled with technologies like Hibernate. However overtime the techniques used to produce the User Interface have changed alot; this is not a big surprise as over this time many technologies in core Java have been and gone (?) such as Applets, Struts, Swing and EJBs and creating reliable interface continues to be a complex problem with various MVC type solutions (Spring, Struts2, JSF etc) trying to provide standard solutions. 

In this article we go through the various user interface options that have and are being used in Windchill and discuss their various strengths and weaknesses. 

The 90/10 rule and blackbox/whitebox abstractions

Before we can analyze and understand the limitations of the various UI strategies, such as DCA and JC,A we need to understand some fundamental concepts. 

The first is the 90/10 rule; which states that the last 10% of a project is as complex and difficult to achieve as the first 90% (maybe it is 80/20 or even 70/30 but the principle still holds true). This is why projects so often overrun and why demos can be so quick to produce but production worthy code is so much harder. 

The second idea is the concept of blackbox and whitebox abstracions. A blackbox abstraction is a layer which hides the true implementation from the user and gives them a simplified way of doing a limited number of, or domain specific things, very quickly and easily. A whitebox abstraction is the same but allows the user to drop through the abstraction to implement at the lower lever as needed. Blackbox abstractions often provide recipe book manuals and look very attractive; limited training and skills are need to produce very powerful results. Whitebox abstractions tend to be more complex to learn but can achieve the same results. 

Good blackbox abstractions can be very powerful but we have the 90/10 rule to worry about. The problem is that we are limited with what our blackbox abstraction gives us, if it can’t do what we need, we can’t use it. We sometimes don’t know this until we hit the problem, when we are at 90% done!  We either compromise or throw it away. Comprimise is sometimes not possible e.g. mission critical feature ,or if it is we get a result that is below our users expectations.  

A little history; Applets, Templates, Info*Engine, DCA, JCA/WCA

Windchill V1 had Applets and HTML, there was not much else available. It some major applets such as the Windchill Explorer that were used to create and manage data in the system, HTML pages were primarily for viewing and could do simple updates. It was presented as a development environment which was highly customizable, this was true but it quickly become clear that the 1000’s of expert Java programmers needed did not exist (in any continent) and from that point, with the various new versions, techniques were introduced  to try to make it easier to customize and configure the system. 

Applets and Template Processing

When Windchill was first released it was a very risky and foresighted strategy to use Java, It was a still new technology and to attempt to create a product with it was a brave move, and in the first versions the user interface was a big issue. Unlike client-server solutions everything was delivered over the net which meant HTML pages and Applets. HTML was still not very versitile and was used for displaying data and basic updating of single objects e.g. documents. Applets were needed for any complex interaction as the HTML interface was so limitied. 

Basically the networks and machines were often not upto the task  of quickly delivering Applets, and the HTML interface was basic. PTC used various strategies to overcome these technology limitations, such as caching the applets (now standard in Java) and creating the idea of template processing. Template processing was basically a way of making dynamic HTML pages which was same idea that Java eventually used to create JSP. 

 

Applets

Applets worked reasonably well, with some performance and network issues. The most famous being Windchill Explorer; even now alot of administrative functions are applets and some complex interactions such as the Product Structure Explorer,  now however, more and more features are available via pure web pages.  

Template Processing

Templates are written in HTML and when a dynamic field is needed special tags are added which execute java methods to retrieve the data. A simple white box abstract that works very well and is easy to program, but as more and more was expected from the HTML client quickly hit some limitations. JSP was a standard and replaced template processes, however a significant amout of these pages still exist and work effectively. A testiment to a clean simple whitebox solution unlike DCA…  

Example 

<SCRIPT LANGUAGE=Windchill>getFormValueFromSession formFieldName=OrganizationDN</SCRIPT>

 

Info*Engine

Info*Engine is a data acquisition and manipulation layer, although not strictly speaking a UI platform, it is closely connected to the UI. It is useful as it provides a task library that the developer can invoke directly from JSP page using Webjects, a simple XML definition.  It is essentially a scripting language so it is not strongly data typed and is interpreted; this means that most errors are detected at runtime and it has a very redundant syntax so it can be long winded and difficult to read. However it does provide an easy way to access and display data and provides useful tools such as creating webservices. 

Advantages 

• Easy to learn vs. Java
• Many simple tasks available to do basic operations
• Understands Instance Based Attributes

Limitations 

• It is a blackbox abstraction – limited to available tasks
• Not possible to google as it is a proprietory definition
• You cannot debug it in normal IDEs
• No MVC separation, all code is placed in JSP
• Inefficient syntax means difficult to read/maintain

Info*engine performs its task of allowing non-java experts to do custom coding however like all scripting solutions it is limited and is not suitable for complex developments. 

DCA – What went wrong?

Dynamic Client Architecture was for a few years PTC’s official way to customize the UI but has since been dropped. It was an attempt to make a black box abstraction that meant that the UI would be defined entirely in XML. It was very ambitious and now has been put aside. The scope of the blackbox abstraction was so large and by it’s nature so complex it was impossible, the XML become a language which it is not. No other framework attempts to do this and for good reason. 

Some parts of the ootb UI were written in DCA, some still exists in 9.1. The searching and User Management is DCA and, as most Windchill users know, these are not easy to use and feel “clunky”. 

JCA aka WCA (Windchill Client Architecture)

JCA which is referred to in the documentation as Windchill Client Architecture is another blackbox abstraction but with more limited scope than DCA and lives comfortably within the whitebox world of JSP. A large amount of the PDMLink and ProjectLink interface is written with JCA and it works well. It is basically a tag library that is used to create AJAX tables, trees, pickers and wizards. You can tell a JCA table as the columns are user resizable unlike template processor driven tables that have static columns, also the tables “fade to grey” as they update and only the UI component is updated, not the whole page. 

Example JCA Table

 

It still has some blackbox issues, for example if you want to display a set of Windchill objects in a table it works very well. It has a clean interface to Info*Engine and can produce very nice results, very quickly. However if you wanted to create more complex tables or even simple enhancements then the recipe book approach falls down. Imagine you need to do a side-by-side compare tool or even add something as simple as a total to your table, it is not clear that this is easy or even possible. Agreed this may be out-of-scope but unfortunately in the real world we sometime have no choice. 

JCA is very good and does does it’s job very well, but we have to note that it suffers from poor “recipe book” documentation and has by it’s nature limitations. To get these rich interfaces with such little work is what the blackbox does for us, but it has set boundaries, which, if we need to cross can cause problems for the developer. 

Other technologies; XSLT, Cognos etc.

Other techniques are used at various points in Windchill the most obvious being XSLT an XML transformation language. It’s primary use is for reports and the Dynamic Design Link which has now transformed into Options and Variants in PDMLink. XSLT is a reasonable solution for reporting but like all loosley typed, interpreted, scripting languages it is not scaleable and can be difficult to maintain. 

Cognos is a ·3rd party reporting engine which is integrated into Windchill provided a powerful platform to create graphical reports. 

Conclusion

Windchill has a range of UI technologies and support layers, all built around Java which makes it very open and gives the developer many choices about the best routes to take. Since R9 JCA is the primary UI technology choice and produces very clean and standard interfaces but can be difficult to learn. 

Please feel free to comment, we have tried to be as objective and accurate as possible but please suggest any alterations or improvements to this articile