OpenCCM - Writing Trading Service Type Descriptions in XML

Table of Contents

  1. Trading Service Type Descriptor (TSTD)
  2. <services> Element
  3. <service> Element
  4. <super-type> Element
  5. <interface> Element
  6. <property> Element

Trading Service Type Descriptor (TSTD)

The goal of this document is to provide information on the way to use the Trading Service Type Descriptor (TSTD) to describe trading service types. Someone with a pretty good knowledge of the OMG Trading Service should find the TSTD XML DTD obvious. For other people who want to use the CosTrading Service with OpenCCM, it is recommended to read this document first and the OMG Trading Object Service specification for more details.

<services> Element

Description The services element is the root element of the Trading Service Type Descriptor.
XML DTD <!ELEMENT services (service)*>
Parent(s) None.
Attributes None.
Children Elements
  • service:
    The services element groups some Trading Service Type definitions.

Example <services>
  <service name="AServiceType">...</service>
  <service name="AnotherServiceType">...</service>
  <service name="AThirdServiceType">...</service>

<service> Element

Description The service element describes a Trading Service Type such as exposed in the OMG Trading Object Service specification.
XML DTD <!ELEMENT service (super-type*, interface, property*) >
<!ATTLIST service name CDATA #REQUIRED >
Parent(s) services
  • name CDATA:
    The name of the trading service type. This name must be unique in the CosTrading Service Type Repository. The name format is checked by the underlaying CosTrading Service product.
    Warning: The OpenORB CosTrading Service does not allow OMG IDL scoped names format, i.e. service type names containing "::".

Children Elements
  • super-type:
    The super-type element is used to specify the super types of the current trading service type if any. These super types must be already declared in the same XML file or already declared in the CosTrading Service Type Repository when feeding it with the trader_feed command.

  • interface:
    The interface element is used to specify the functional OMG IDL interface of the current trading service type. A service registered with a given trading service type provides at least the related interface functionalities. A trading service type interface must be in conformance with its super types' interfaces, i.e. same interface or a sub type. Finally, following the CosTrading Service product used, when the CosTrading Service Type Repository is fed with trading service descriptions via trader_feed, it may be necessary that the related interface descriptions has been fed in an Interface Repository.

  • property:
    The property element is used to specify which properties can or must be used to describe an offer for the current trading service type. A trading service type inherits all properties defined in its super types.

Example <service name="AServiceType">
  <super-type name="..." />
  <interface name="..." />
  <property name="..." type="..." />
  <property name="..." type="..." />

<super-type> Element

Description The super-type element references another trading service type by name.
XML DTD <!ELEMENT super-type EMPTY >
<!ATTLIST super-type name CDATA #REQUIRED >
Parent(s) service
  • name CDATA:
    The name of the trading service type to reference as a super type. The name is submitted to the same restriction than trading service type names.

Children Elements None.
Example <super-type name="AnotherServiceType" />

<interface> Element

Description The interface element references an OMG IDL interface.
<!ATTLIST interface name CDATA #REQUIRED >
Parent(s) service
  • name CDATA:
    The name attribute is used to reference an OMG IDL interface. The name format must be conform with the CORBA repository identifier format, i.e. IDL:[prefix]/[module]/interface:X.Y where X and Y are respectively major and minor version numbers. No other format is allowed.

Children Elements None.
Example <interface name="" />

<property> Element

Description The property element describes a trading service type property. A property has got a mode, an OMG IDL type and a name.
XML DTD <!ENTITY % Mode 'normal|readonly|mandatory|mandatory_readonly' >

<!ENTITY % Ulong 'unsigned_long'>
<!ENTITY % Ushort 'unsigned_short'>
<!ENTITY % BasicTypes 'long|

<!ENTITY % SeqTypes 'LongSeq|

<!ENTITY % IDLTypes '%BasicTypes; | %SeqTypes;'>

<!ELEMENT property EMPTY >
     mode (%Mode;) 'normal'
     type (%IDLTypes;) #REQUIRED >
Parent(s) service
  • name CDATA:
    The name attribute identifies the name of the property. This name must be unique in the scope of the trading service type description (including inherited properties). However, a property already defined in a super type can be redefined with a more restrictive mode (see the mode attribute). In this case, and only in this case, an existing property name can be reused (the related OMG IDL type must be the same).

  • mode (%Mode;):
    The property mode defines how the property of a service offer can be accessed. Four modes are possible: normal, readonly, mandatory and mandatory_readonly. The normal mode is the less restrictive. A property with the normal mode is optional and can be modified once the service offer registered. The readonly and mandatory modes are both more restrictives than the normal mode and less restrictives than the mandatory_readonly mode. A property with readonly mode cannot be modified once the service offer has been registered. A property with mandatory mode must be provided when registering a new service offer. The mandatory_readonly mode is the most restrictive. A property with a such mode has the two previous restrictions.
    As default value, the normal mode is used.

  • type (%IDLTypes;):
    The type attribute sets the OMG IDL type required for the property value. Currently, only primitive types and sequence of primitive types can be used with the TSTD.

Children Elements None.
Examples <property name="aLongProp" type="long"/>

<property name="aFloatSeqReadonlyProp" type="FloatSeq" mode="readonly" />
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster | Last modified at 2005-07-07 02:04 PM