DPT Software Architecture
Before you understand the DPT Software Architecture, you must know the various integration strategies that PTC has employed for various products. The products involved with DPT use any one of the following architectures for integration:
• Middleware
• Client / Server
• P2P (Peer-to-Peer)
Middleware
In this architectural model, a dedicated software layer serves as a central intermediary between multiple systems. The middleware manages communication protocols, data format consistency and mapping, and integration logic. Centralized control is a primary advantage of this approach, facilitating streamlined monitoring, efficient troubleshooting, and robust security policy implementation. Additionally, middleware supports advanced functionalities such as data caching, audit logging, and message queuing, which contribute to enhanced reliability and resilience.
Middleware architectures are particularly beneficial for integrating a heterogeneous array of systems lacking native interoperability, or when stringent governance and centralized oversight are necessary. However, these architectures may present potential bottlenecks; therefore, considerations for high availability and redundancy are paramount during system design.
This approach is commonly used in Windchill OSLC integration, where the middleware (ThingWorx) manages interactions and ensures seamless client-server communication between Windchill and other connected products.
Client / Server
In any OSLC configuration, there is an OSLC provider (server) and an OSLC consumer (client). An OSLC server basically runs a web service that provides software development tool integration and data. An OSLC client provides an interface to the end user primarily to fetch resources and data by connecting to the web services provided by the OSLC server.
The following are some of the functions of an OSLC server:
• Enables a system to expose resources such as Requirements, Issues, Parts, etc., in a consistent methodology.
• Allows users to navigate those resources (browse, query) and create them.
• Provides support for Remote UI.
• Manages authentication from the OSLC client.
• Referred to as Upstream.
The following are some functions of an OSLC client:
• This is the side where Trace links are created and stored.
• Provides the ability to query and update resources from an OSLC Server.
• Can leverage Delegated for Query / Search of Resources or use local capabilities for these needs.
• Retrieves properties of a remote resource.
• Referred to as Downstream.
In addition to the above, an OSLC client performs the following calls:
• Retrieve a delegated UI for selecting artifacts on a remote repository. The remote repository artifact representation includes a URL that can be used to navigate to the remote repository (display the remote artifact in the Web UI of the remote repository). The artifact selected is returned as an OSLC URL to the artifact.
• Retrieve a delegated UI for creating a link for an artifact on a remote repository (either for an existing remote artifact or for a new remote artifact created by the delegated UI).
• Retrieve a delegated UI for displaying the properties of a specified remote artifact.
• Find all artifacts in a remote repository (optionally scoped to a specified configuration) that have a link to a specified artifact in the local repository (reverse lookup). The artifacts found are returned as OSLC URLs.
• Retrieve a list of all remote artifacts in a specified scope that have been changed on the remote repository since a particular date (returned as a list of OSLC URLs).
Peer-to-Peer
A Peer-to-Peer (P2P) architecture enables systems to communicate directly with one another, without the need for a central intermediary. Each participating system, or peer, can initiate and respond to requests, creating a more decentralized network. In Digital Product Traceability, P2P architectures are leveraged in OSLC integrations for PTC RV&S, PTC Modeler, and Codebeamer. These products establish direct connections, allowing for real-time data exchange and the formation of traceability links across different lifecycle domains.
The P2P approach offers several advantages, including improved scalability, as there is no central bottleneck limiting throughput. It also increases resiliency, since the failure of a single node does not disrupt the entire network. Moreover, P2P can be more flexible, enabling organizations to tailor integrations based on specific project or product needs. However, managing consistency, security, and version compatibility across a distributed set of peers can be more complex compared to a centralized middleware solution
The following image explains the DPT Software Architecture from Windchill’s perspective.
