3 Architecture
3.1 Decomposition into Packages
The interfaces for Coordinate Transformation Services are split into three packages: a Positioning
PT b Coordinate Systems CS
c Coordinate Transformations CT The interfaces in these packages have the following dependency relationships:
Package
Interfaces depend on…
PT None CS PT
CT PT CS
Figure 1: Package interface dependencies
3.2 Naming Conventions
All interfaces, structures and enumerations start with a two letter prefix indicating their package. For example, all interfaces in the Coordinate System package start with the prefix “CS_”. This
convention both makes client code easier to understand, and resolves issues with re-using common names, e.g. Parameter.
All method, parameter and property names are consistent with the normal conventions for the DCP in question.
3.3 Object Mutability
All interfaced objects are immutable. This means that implementations must promise not to change an object’s internal state once they have handed out an interface pointer.
All mutable entities are implemented with structures in the COM and CORBA profiles, and classes in the Java profile. These language elements allow for return-by-value and pass-by-value
semantics.
3.4 Error Handling
All errors are handled using the normal method for the DCP. In the COM profile, an implementation that fails to perform an interface method can return a
HRESULT value of E_FAIL. Successful method functions will return S_OK. In most COM client environments e.g. Visual Basic and ATL C++ these return codes are processed by client-side
stub code, and errors are converted into exceptions that the client application must catch. C client programmers should check all the HRESULT return values with the SUCCEEDED macro.
In the Java profile, an implementation that fails to perform an interface method should throw a runtime exception.
No exceptions have been specified in the CORBA profile.
Page 12 of 117 OGC Document Number 01-009
3.5 Mandatory Parts
Kategori