CAA Web Services Home

Web Services Overview

Web services are language neutral API which can be remotely accessed over a network through messages. Most of the time, these messages are formatted according to the SOAP specification [1] and are conveyed by the standard HTTP protocol. The functionalities that these systems deliver are described in a platform and language neutral-way using an XML based language called WSDL (Web Services Description Language). This mechanism enables loose integration of heterogeneous systems.

Setting up a Web Service architecture usually involves the following fundamental operations:

• Service Providers create Web Services. CAA doesn't offer specific tools for developing new Web Services but provides a set of Web Services,
• Service Providers then publish the services to a Service Broker,
• Service Consumers find services using the Service broker facilities and then bind to the provider code. Binding and consumption are greatly eased by the use of generated, language-specific objects called proxies.

WSDL

WSDL describes, among others information:

• The service endpoint URI (Uniform Resource Identifier) where requests to the service are to be addressed,
• The list of requests (also called methods or operations) than can be handled by the service and the description of their arguments.

Argument types are described in XSD (XML Schema Definition) format.

For more information on WSDL, see [1] and [2]

UDDI

Web Services are located through a service endpoint URI. Knowing this URI is mandatory to be able to use the service. The URI of a Web Service can for example be documented, and it can also be retrieved from a directory. The service endpoint URI scheme for CAA Web services is documented in [2].

UDDI (Universal Description Discovery and Integration) is a standard for a directory technology that describes how Web Services can be published and how they can be retrieved using queries. Publish/retrieval are often performed through web based user interfaces or using APIs. For retrieval, the use of an API allows an application to dynamically retrieve the locations of the services to consume by querying the UDDI registry where they have been previously registered.

For more information on UDDI, see [1].

Proxies

From the WSDL/XSD description of a service, developers can use off-the-shelf tools to generate a client proxy for their platform and programming language.

This client proxy provides a language friendly way to invoke service methods. It knows how to craft the correct messages and send them to the target software system. For example proxies generated for the Java language will be Java interfaces and classes. Invoking a method of the Java interface will transparently invoke the corresponding method of the Web Service by marshalling/demarshalling SOAP messages.

[Top]

General Principles of CAA Exposition of Web Services

Supported clients

As of V5R16, only clients using the Apache Axis technology are officially supported for consuming CAA Web services. See [3] for the precise list of supported levels.

Documentation

API documentation is presented in the familiar javadoc format for simplicity [4]. It is close from the javadoc documentation that could be generated from the Java proxies.

Beware however, proxies generation may vary from a client technology to the other. An out parameter is for example described as a classic Java holder on the type of the parameter, while it could for example be a reference on the parameter type in C++ proxies. Even for proxies targeting the same language, generation may slightly vary from a client toolkit to another.

Code Samples

Code samples are generally provided as CAA Java code in a framework/module structure. They rely on Axis proxies that are delivered with the samples. The Axis runtime is not delivered with the CAA media and must be obtained separately.

It is strongly recommended to re-generate the proxies with your own installed tool instead of relying on the delivered version. How to generate proxies using Axis is described in details [3].

The samples can be built and executed using any Java RADE tool as described for example in [4].

They can also be built using the CAA Multi Workspace Application Builder. This requires however to modify the Imakefile.mk of the module samples to reference your own installation of the Axis runtime:

• Remove any LINK_WITH reference to modules starting with "caa-",
• Either copy the Axis jars in .mjext CAA modules and add those modules as LINK_WITH references,
• Or use the LOCAL_WS_LIBS statement to add the Axis jars of your installation to the CLASSPATH:

Error Management

CAA Web Services return a NLS translated status string to the consumer. The status string returned will contain a collection of all messages and warnings for the operation.

In case of a failure, a SOAP fault of type CATServiceException will be returned. The error messages along with any warnings and informational messages will be returned in this exception. For Axis Java proxies, this results is a Java exception. Mapping may vary with other Web Services client technologies.

ENOVIA Customization

ENOVIA LCA allows to add customer attributes on existing data type. Having those attributes been processed by CAA Web Services requires operations described in [6].

[Top]

In Short

[Top]

References

History

Copyright © 2005, Dassault Systèmes. All rights reserved.