The following topics describe the web services tools available with Info*Engine, and provide examples of how to write and deploy a web service for use with Windchill.

Windchill offers a toolset that facilitates deployment of the same Info*Engine-based web service that leverages JAX-WS (Java API for XML Web Services) in order to handle the SOAP/XML and security-related web service details. This toolset is available in addition to the Info*Engine-based web services that are supplied by the SimpleTaskDispatcher servlet. The web service implementation, which is based on Info*Engine tasks and task delegation, remains mostly consistent. However, the XML representation of the corresponding SOAP interactions differ based upon the manner in which JAX-WS uses JAXB (Java Architecture for XML Binding) to bind Java objects and Info*Engine data structures to XML. For backward compatibility, access to the same services is available using the SimpleTaskDispatcher.

Aside from leveraging JAX-WS for the SOAP-related details, a major advantage to using this framework is the addition of configurable and efficient security. Legacy Info*Engine web services rely solely upon web server authentication for security. This means that SOAP clients must have complete access to user credentials, and must supply those credentials to the web server per its authentication requirements (typically HTTP Basic Authentication). However, this presents a fairly significant roadblock to developing applications that implement SSO (Single Sign On). This is when a separate application or application server has independently authenticated a user, and a trust relationship exists between the client and Windchill. Relying solely upon web server authentication means that an SSO application or application server must have access to the user’s password to reauthenticate that user within an Info*Engine web service.

A downside to leveraging more advanced security policies is the complexity of the mechanisms involved. The web service client must be capable of complying with the configured security policy, which often involves encryption and a complex XML representation of the security information embedded within SOAP requests. If the client in question is Java, then the tooling supplied with Info*Engine hides these complexities so that you can write your client without complex coding for security purposes. If you use a separate third-party SOAP framework to connect to Windchill web services, then it is that client’s responsibility to comply with the security policy chosen for a given web service.

With web service security support in Windchill, you can establish a trust relationship between an application (such as a portal server) and an Info*Engine web service by exchanging public key information, requiring that SOAP message exchanges be properly signed and encrypted, and requiring that they contain a valid username token that the web service should trust. As long as the incoming SOAP message meets the security requirements and can be decrypted using a public key found in the server’s truststore, the web service then executes a request that has been authenticated with the username. Similarly, depending on the requirements of the security policy in use, the client may be required to have access to the server’s public key to decrypt responses.

Each web service endpoint is represented by an instance of a Java servlet. As a result, a JAX-WS-based Info*Engine web service can be deployed multiple times if each time the web service is secured by a different security policy and uses a unique servlet name for each deployment.

Optionally, given additional configuration, it is possible to place a JAX-WS-based Info*Engine web service behind web server authentication and forgo the cryptography-related requirements of selecting another security policy.