Architecture

Overview

Before starting to write Windchill Extensions, it is useful for a developer to get acquainted with their and the WEX Platform's architectures. The goal of this section of the guide is to shed some light on aspects such as WEX's design principles and package structure, the platform's architecture and its parallelisms to containerization, important file locations to take into consideration when developing an extension an information on the WEX Kernel.

WEX Design Principles

The primary goal behind the WEX architecture's design is to allow unfettered software decomposition. Our systems are designed following a principle of compartmentalization: we use data and method hiding by means of access (private, protected and public) and we use object orientation to define interface and hierarchy. This gives us the illusion of separation, but all the elements of our design build to run in the same JVM with the same class loader we must integrate these elements during the build process.

In order to understand why the design is so emphasized on software decomposition, we must first understand the downsides most software systems face when they turn into a monolithic entity. The idea of a monolithic build has some fundamental constraints to Go Live i.e. take the code into production:

1. Everything we want to deliver must be ready at the same time.
2. If we are using a shared resource e.g. an open source library, we must all agree on a specific version.

This has some consequences:

1. Significant effort has to be made to coordinate the development since every piece of the release must be ready simultaniously.
2. There is a need to have a concrete and formal Go Live event.
3. The need to be sure that everything is ready often propitiates over testing our system, most times very inefficiently.
4. The code tends to use a large amount of branches which are expensive to maintain.
5. The Go Live events have a long lead time resulting in a poor code delivery time to the user.

The design of the WEX platform revolves around the following concepts in order to avoid the abovementioned constraints.

Containerization

Let us take a look at a containerization system, such as Docker. This isolates a single software program into a self-contained unit that has all the resources it needs to run. It does not share an O/S or disk with other applications: it is self reliant.

There is no need for coordination: different resources of different versions and types can be used from container to container as they are isolated from other containers running in the same machine. Web application servers were an early example of this, and more recently Docker plays the same trick.

Micro Containerization

Why is containerization important for extensions?

Because we can re-use this containerized design within our application. We call this micro containerization.

We make our extensions self contained: they contain everything they need to run. Our WEX Kernel acts as a container manager, and it shields Windchill from the extensions. In fact, Windchill itself is not aware of the existence of the extensions, except the cases in which they expose an interface through the kernel, in the form of a feature, for allowing interaction with other extensions.

This means that:

1. Each extension is built independently and results in an autonomous installable entity.
2. An extension can use common libraries, but these are built into the extension.
3. Common libraries are not shared at runtime.
4. Since the extension runs in its own class path, it can run exactly the same code as other extension.

A common consequence of this is we can run two versions of the same open source library at the same time in different extensions.

The call pattern looks like this:

• Extensions can call kernel code.
• Extensions can call Windchill code.
• Windchill cannot call extensions.
• Extension can expose an interface that can be called by another extension or by Windchill via the kernel.

Understanding this pattern is crucial to be able to develop extensions.

The Kernel and the Platform

The WEX Kernel is a very small part of the WEX Platform: it acts as a container manager, and it shields Windchill from the extensions. All other features such as the Manager, Documentation, Security are developed as extensions: these types of WEXes are called System Extensions and may not be removed from the system.

The kernel's code is the only WEX code visible to Windchill. The extensions run in an isolated class path and are only accessible via features exposed by the kernel.

When defining a feature, we declare methods using annotations. These methods are available to other extensions using the wex invoke command. See the Coding section for more information on cross-extension communication.

WEX File Structure

Windchill Extensions

All files of an extension package can be found under this directory:

$WT_HOME$/wex/[groupid]/[artifactid]

Within this directory are the following files:

Location	Description
bootstrap.xml	Read by the Kernel to install the code.
codebase/[artifactid].jar	Codebase.
codebase/*.jar	Code of the WEX, including 3rd party libraries.
/windchill	Files in this directory will be copied to the Windchill home.
meta/definition.xml	Definition file which contains metadata such as the display name and the target Windchill version.
docs	Documentation of the WEX in MarkDown format.

definition.xml

The definition file holds the versioning information and other metadata, such as the client information, the display name, the artifact-id or the target Windchill version. It cannot be changed after signing, as that will invalidate the extension.

<wex-definition>
    <meta>
        <group-id>Unique ID of author e.g.com.wincomplm</group-id>   
        <artifact-id>wex-manager</artifact-id>    
        <display-name>Wex Manager</display-name>
        <system>true</system> 
        <description>The features of Wex</description> 
    </meta>
    <build>
        <version>
            <major>1</major>
            <minor>0</minor>
            <beta></beta>
            <revision></revision>
        </version>
        <host>
            <release>11.0</release> <!-- Target Windchill Release --> 
        </host>
    </build>

    <additional> <!-- This data is added during download fromt the center or during signing --> 
        <timestamp></timestamp>
        <client>Wincom</client>
        <clientid>666</clientid>
        <evaluation>false</evaluation>
    </additional>
    <intall/>
</wex-definition>

Source Package Definition

The standard locations for source files are suggested, although not enforced:

Name	Description
src/[groupid]/[artifactid]/commands	Command lines.
src/[groupid]/[artifactid]/api	API that may be called by other Windchill Extensions.
src/[groupid]/[artifactid]/workflow	Code called by workflows.
src/[groupid]/[artifactid]/impl	The code private to the WEX.

Platform

File locations

All extension files are held in a single directory:

$WT_HOME$/wex

Within it, the following relevant subdirectories are found:

Name	Description
wex/codebase/kernel.jar	The WEX Kernel that will be loaded into the Windchill class path.
wex/packages	Installed wex packages.
wex/deploy	Applications to be installed by the deployer.

Core WEX Applications

These are some of the fundamental libraries that we use for developing Windchill Extensions; they are all in the com.wincomplm group-id. Some WEX applications will call Windchill API or interact with Windchill: they can be recognized by the wt particle present in their artifact-ids:

Artifact id	Description
wex-kernel	The kernel is in the Windchill class path and loads the WEX apps.
wex-core	Holds the fundamental definition of the WEX and understands its metadata.
wex-framework	Holds general utility methods.
wex-deploy	Used to deploy new WEX packages.
wex-wt-system	Only information about Windchill, no direct API to the DB.
wex-wt-framework	The abstract APIs used by most WEXes.

Install types

Name	Description
cold load	The Windchill servers must be stopped before the install is started.
warm load	The Windchill servers must restarted after the install.
hot load	The Windchill servers do not need to be restarted.

Versioning

Each app is released with a unique version number. The schema is:

[major version].[minor version] e.g. 1.1

A change in the major version indicates a restart is required, while minor version updates can be hot loaded onto the system.

Note: the minor version may be a number, dots and letters.

Beta Releases

If a minor version contains the letter b (for example 1.1b1), that means the build is for beta testing only and must not be put in a production system. After testing has been concluded, the version must be upped (1.1b1 would transition into 1.1) to signal that the WEX is ready to be deployed outside of a development environment.