Describes the interfaces and relationships of the core infrastructure of commands (i.e., the Command Subsystem) to include: command beans, command delegates, and utilities.

There are many types of consumers that command a Windchill system (i.e., method server) to perform tasks, or request information from it.

See:
Description

Exception Summary
NullFeedbackSpecException	Supported API: true Extendable: true

Package com.ptc.core.command.common Description

Describes the interfaces and relationships of the core infrastructure of commands (i.e., the Command Subsystem) to include: command beans, command delegates, and utilities.

There are many types of consumers that command a Windchill system (i.e., method server) to perform tasks, or request information from it. These consumers can be HTML or Java clients, vertical applications, command-line utilities, external systems, etc.

From an architectural perspective all of these consumers require a common means to perform these commands. Each command represents a business task or sequence thereof that can be performed against a single Windchill system. To perform these same commands against other types of systems adapters would be required for those systems where the commands could be effectively employed. This too applies for a web of cooperative systems.

To form a unified “enterprise layer” of commands around a Windchill system there must be the notion and implementation of these commands as a composite design pattern. This documentation establishes the design pattern for the “enterprise layer” based on commands.

Introduction

In the beginning of Windchill, there was a clear programming model for developing Windchill clients. Windchill clients had the following characteristics:

·Windchill clients were Java applets.

·Windchill clients communicated with Windchill server-side services using RMI, receiving serialized copies of the server-side objects.

·Windchill clients operated on the same classes and objects used by Windchill services.

The current state is more complicated for Windchill clients. A “Windchill client” may still be a Java applet, but it may also be a Java application, HTML client authoring using template processing or Java Server Pages, a Java or HTML client accessing Windchill services through Info*Engine webjects, or other clients using Servlets, XML, etc.

Clients need to be able to invoke common business tasks such as:

·CRUD for business objects as a whole.

·Querying for information.

·Updating attributes on business objects (Parts, Documents, Change Requests, etc).

· Changing the state of a business object through an operation (Checkout/in, Revise, Promote, etc.).

·Navigating, creating, updating, or removing associations between objects.

Windchill services exist to perform these business tasks. However, these existing services are designed to service the “traditional” Windchill Java client. These services are not suitable for direct access by New Client Architecture (NCA) clients because:

·They are designed to operate directly on Windchill persistable objects where NCA clients use type instances and attribute containers.

·They do not allow for operations to be performed indirectly through Info*Engine on composite business objects. In other words, not all of the business object’s attributes are from or managed by one system. There could be a web of cooperative Windchill and external systems where each owns part of the object.

·They do not understand the new virtual “typed” objects created through Light-Weight Customization (LWC) mechanisms.

Attempts to produce interfaces suitable for different types of clients have resulted in FormActionDelegates (for HTML Template processing), WebjectDelegates (for Info*Engine webjects), and various “TaskLogic” classes for Java applet clients. In many cases, there has been a duplication of business logic code in these classes.

Patterns must be established which allow core functionality to be easily utilized in a variety of clients, without promoting duplication of code representing key business logic. The code to service a request for a JSP client should not be duplicated in the code to service the same request for a Webject or Java applet client. The “golden logic” of Windchill must be re-used in a more reliable manner than cutting and pasting code.

Create Part [Example] Use Case

A consumer creates a command and sets its input to the requestor (i.e., object). The requestor is held within an type instance or attribute container in that common format. The consumer then executes the command to carryout its task. The corresponding command delegate for the command and requestor is either locally or remotely executed depending on whether the command was executed in the server or client, respectively.

Candidate Design Patterns Used

The following is a list of design and other patterns that were used to help in creating the “enterprise layer” set of abstractions in this documentation.

Command Design Pattern

Also known as Action or Transaction, this is one of the two main patterns employed for the command layer. This design pattern encapsulates a request as an object, thereby letting you parameterize consumers with different requests, queue or log requests, and support undoable operations. It will be used to express the external APIs of the command layer in the form of Windchill commands that can be executed by any consumer. These commands will also conform to the JavaBeans architecture so that consumers can expect certain conventions to be in place as a natural part of any command.

Strategy Design Pattern

Also known as Policy or Delegate, this is the other main pattern employed for the command layer. This design pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. This pattern lets the algorithm vary independently from consumers that use it. And thus, the behavior of an object is exercised by an algorithm is delegated to another object. It will be used to design a family of command delegates where each will implement its applicable command execution logic.

Composite Design Pattern

Defines a simple means of composing objects into tree structures to represent part-whole hierarchies. This design pattern lets consumers treat individual objects and compositions of object uniformly. More to the point, this design pattern is used in the command layer to define a collection of commands that can be acted upon as a command.

Template Method Design Pattern

It defines the skeleton of an algorithm in a method, deferring some steps to subclasses. This design pattern lets subclasses redefine certain steps of an algorithm without changing the algorithm’s integrity. It will be used to ensure that the execution algorithm for commands remain intact and that only certain steps (e.g., pre/post processing, business logic) can be overridden by subclasses.

Abstract Factory Design Pattern

Provides an interface for creating families of related or dependent objects without specifying their concrete class. This design pattern will be used within the command layer as an implementation detail such that command delegates can be constructed without having to know exactly what concrete class to pick. As a part of this in Windchill this type of factory will be part of the application context mechanism where the service.properties file is used to specify what delegate to construct based on selection criteria.