Advanced Customization > Services and Infrastructure Customization > Windchill Design Patterns > The Business Service Design Pattern
  
The Business Service Design Pattern
This pattern has the following major kinds of abstractions:
Type
Cookie
Helper
Service
ServiceEvent
ServiceException
ServiceFactory
Type
The Type abstraction provides an interface for means to type an object as being of a particular kind. This interface is what the service expects to deal with in terms of input and output, other than additional information. An object that does not specify it is of a certain type cannot statically be used by the service and thus is rejected at compile-time. In general, a Type is a kind of persistable object.
Cookie
The Cookie abstraction provides a class that is used to specify the information to be associated with and stored as a part of the typed object. When an object asserts itself as being a Type, the Cookie and its attributes, including all nested attributes, are code generated into the object along with applicable accessors. If a Cookie’s cardinality is 0..1, the Cookie and all its nested attributes can be stored as null if none of the Cookie’s attributes are required. If any of the simple, or structured, attributes of the Cookie are constrained to be non-null in the database, the Cookie is forced to be non-null.
Helper
The Helper abstraction provides a class representing the service’s external interface from which all visible functionality can be invoked. The helper is intended to specify only static methods and attributes which any other class can access without having to create any instances. The static methods are typically Cookie accessors.
Service
The Service abstraction provides an interface that specifies the main functionality of the service itself, which may or may not be invoked remotely if the interface is annotated with the @RemoteInterface. Otherwise, the service’s interface will be available only locally in the server. This interface must be adhered to and implemented for the service to function properly. Additionally, a standard implementation of the service’s methods exists. This standard implementation is a singleton executing on the server and is the default for all Windchill services.
ServiceEvent
The ServiceEvent abstraction provides a common definition of an event that can be emitted from the service and cause another service to be notified of the event. This event specifies one or more kinds of occurrences that are used to generate keys for listeners. Because these specific kinds of occurrences are extremely simple in nature, only one event per service that defines all occurrences is specified.
ServiceException
The ServiceException abstraction provides a common definition of an exceptional condition that may occur as a result of abnormal behavior in the service. This exception, along with the service’s resource bundle, can be used exclusively to throw any and all kinds of errors. However, it may be appropriate, but not necessary, to specialize this exception for more explicit and applicable errors.
ServiceFactory
The ServiceFactory is a utility to look up implementations of Windchill service interfaces. The ServiceFactory is primarily intended for remotely invokable services, but can also be used for server-side services (such as PersistenceManagerSvr).