
	JacORB 1.0 beta 12, Trading service implementation


This trading service implementation is an extension of Mark Spruiell's
JTrader, version 0.2. This version was GPL'ed (see the COPYING file in
this directory),  but with  a different license  than the  main JacORB
license,  which is  GPLL.   The current  JTrader  copyright holder  is
Object Oriented Concepts, Inc. (the  makers or ORBacus). Note that the
present distribution  is in full accordance with  the original license
and remains free  software, even though OOC has a  product of the same
name (which is the successor of the predecessor of this implementation
and is commercially licensed).

As of  JacORB beta  12, our trading  service differs from  JTrader 0.2
with respect to the following points. The JacORB trader:

* uses the  POA and  the most recent  DynAny API (CORBA  2.3) 

* supports   trader  federations/linked  traders   (implementation  by
  Nicolas Noffke)

* has a slighly different directory structure

Gerald Brose.


(The rest of these notes are Mark's original ones:)
==

Random notes about this implementation:

* Constraint/preference validation

  JTrader uses strict ("static") type checking of constraint and
  preference expressions.  The specification implies that offers
  can be exported containing properties that are not defined in
  the service type.  The intent of the specification is to allow
  these properties to appear in a constraint or preference
  (within the given property-type restrictions).

  JTrader, however, performs static type checking using the
  service type information.  A property that does not appear in
  the service type cannot be used in a constraint or preference
  expression, with one exception: an undefined property can be
  used as the operand to the 'exist' operator.

  This shortcoming will be corrected in a future version.

* Constraint/preference errors

  The IllegalConstraint and IllegalPreference exceptions do not
  contain a field for describing the problem with the expression.
  JTrader prints an error message to stdout when parsing errors
  occur.  If these messages are not desired, they can be removed
  by editing RegisterImpl.java and LookupImpl.java.

* Persistent storage

  JTrader includes two storage mechanisms, one based on Serializable
  objects and the other using the free ObjectStore PSE product.
  These mechanisms are not very scalable but should perform
  adequately in smaller applications.  Interfaces are provided for
  defining custom persistence mechanisms.

  The provided persistence mechanisms can only store properties whose
  values are primitive types (boolean, short, unsigned short, long,
  unsigned long, float, double, char, string, octet) or sequences of
  primitive types.  JTrader does support the storage of properties
  that are not defined in the service type, as long as the property
  type is one of the previously listed supported types.

* Admin settings

  The settings controlled by the Admin interface are strictly
  transient in nature.  In other words, the defaults are established
  in TradingService.java, and can be changed at runtime via the
  Admin interface, but the settings are not stored persistently.
  Any changes made while the service is active are lost when the
  service terminates.

  If you have permanent changes, make them in TradingService.java
  until such time as the Admin settings are persistent.

* Service Type Repository

  The Register, Lookup and Admin implementations all use the
  service type repository, and all access to the repository is
  done exclusively via the IDL interface.  Therefore, a separate
  implementation of the repository can be plugged in relatively
  easily by modifying TradingService.java.

  JTrader currently supports fully-scoped identifiers as service type
  names (e.g. ::One::Two), but does not support interface repository
  IDs.

* Interface Repository

  JTrader will use an interface repository (if one is available) to
  perform validation of service types and service offers according
  to the criteria in the specification.  JTrader obtains the repository
  using the ORB's resolve_initial_services() method.

  Note that use of the interface repository has performance
  consequences.

  JTrader will only throw the InterfaceTypeMismatch exception if it
  can successfully confirm that there is in fact a conflict.  If any
  errors occur (e.g. no InterfaceDef found, etc.), the operation is
  allowed to continue.

* Dynamic properties

  JTrader attempts to handle service offers containing dynamic
  properties in an efficient manner by using threads to simultaneously
  evaluate multiple offers.  JTrader limits the number of threads that
  are created (currently the maximum is 10).  To change the thread
  limit, edit the jtrader.impl.OfferEvaluator class.  JTrader will only
  evaluate a dynamic property if it is used in a constraint or
  preference expression, or if it is one of the "desired" properties.

* Proxy offers

  JTrader's handling of proxy offers is similar to that of dynamic
  properties; threads are used to simultaneously process multiple
  proxy offers.  Proxy offers can have dynamic properties.

* Porting to other ORBs

  Assuming an ORB adheres to the standard IDL/Java mapping, there are
  still source-level differences that won't be resolved until the
  Portable Object Adapter specification has been widely implemented.
  In the interim, a simple ORB-independence layer can be found in
  src/jtport.  The ORBLayer abstract class defines the handful of
  methods that were necessary to make the rest of JTrader (mostly)
  independent of ORB-specific idiosyncrasies.

  One area that's particularly difficult is the notion of "persistent"
  objects.  Visigenic and other vendors use proprietary mechanisms for
  distinguishing between persistent and transient objects.  In the
  particular case of VisiBroker, one way a server makes an object
  persistent is to provide a name when constructing the object.  This
  approach is not portable, and a workaround was used in JTrader.

  The best candidate for a persistent object in the trading service is
  the Lookup implementation, through which all other objects are
  accessible.  In src/jtrader/impl/LookupImpl.java you will find the
  VisiBroker-specific method _object_name(), which overrides a method
  in the superclass and is an alternative way of providing the persistent
  object name while not affecting portability (at least between the two
  ORBs currently supported by JTrader).  The name used for the Lookup object
  is "TradingService".

  To further facilitate portability, the src/jtport subdirectory also
  contains a partial implementation of the DynAny specification.  These
  objects will eventually be provided by the ORB vendors, but until then
  JTrader will include its own implementation.

  If you have successfully ported JTrader to another ORB, please
  send me a note containing or describing the changes that were
  necessary.
