Module - WSServer Api (WSServer Api)

This module defines the WebService API (SOAP & REST) of the GRID Access Layer.

This is a pure API module with no own implementations featuring Java interfaces and data types used to exchange data with the GRID. The module ws-server implements a server process using this API.

API and server implementations combined in the ACL server process build service endpoints that may be used to query or feed the GRID.

  • Offered Services Types:
  • Offered Endpoint URIs:
    • Public via Internet: https://gacl.trendmicro.com/
    • Trend Micro Internal: https://mygacl.trendmicro.com/

A pre-built client implementation (built with wsgen) using this interface implementation can be found with the module ws-server-client.

Accessibility & API Versioning

When looking at the SOAP or REST interfaces you may step over "level-0" and "internal" inside the access paths:

  • /level-*/: Services are organized in profiles that are numbered starting from '0'. Within a profile level (e.g. 0) there mustn't be any changes made to the interfaces that would break existing clients (incompatible interface changes are forbidden within a profile level).

    Enforcing compatibility ensures that existing software continues to work, at the potential cost of introducing legacy issues if an attempt is made to fix a broken interface design (methods may be deprecated but still have to be supported).
    In order to resolve legacy design issues it is possible to define another profile of a greater level which is logically an enhancement and may or may not be compatible with an API of another level. It's important to note that new profiles are only created when needed. Compatible enhancements are added to all lower levels first.

  • /internal/: Services that are not meant for public availability are marked by the keyword internal inside the service endpoint address. Internal services can be accessed only from within the Trend Micro network (protected by firewall rules).

    See Access Control for more information on accessibility and finer grained access rights that are mandatory to access the production web services.

Well Known Tags

The ACL has very little knowledge on what tags are applied to packages or files. A few API calls however do need to know the meaning of some tags in order to function correctly. The following subset of tags are defined within the API as 'well known tags' and influence the ACL's internal processing logic:

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/**
 * Tags a file or package if it is considered clean. (= whitelisted)
 */
clean,
  
/**
 * Tags a package that contains a large amount of file entries.
 * <p/>
 * The ACL treats such packages in a special way by disabling the full
 * synchronization inside the storage subsystem.
 * <p/>
 * Processing modules may then send processing results in chunks which reduces
 * the memory requirements for handling such packages.
 */
oversized,