Introducing Java Service for the Web



   

Java Service for the Web (JSW) is a Nymex Access Trading System Infrastructure (TSI) Service
The objective of JSW is to provide Internet Trading for Nymex Access
JSW has been written to run with existing TSI Server code in mind.
A few minor fixes are needed to Central Server to support REMOTE SERVICES
JSW runs under the Apache/TomCat Jakarta WebServer (Unix or NT)
JSW is written in a combination of Java, JSP and Dynamic HTML

Leverage Existing Software

The approach taken by the vendors of JSW is that all current Nymex code is valuable.
Competitor vendors take the approach of replace all the code with new code.
The existing structure within Nymex is that external systems provide:

  • inward contractural data From C21 to BackOfficeInterface to C21 via the Message Replay Service (ATS)
  • outward trade data via BackOfficeInterface
  • outward price information PriceReportingServiceInterface (ITC2 Message Format)
  • Corporate Explorer to manage Support Database Tables
  • Citrix Network
  • Database
JSW is designed to run as well as and not in place of any Nymex Access Product
In fact, subject to Server Side Implication JSW runs side-by-side with the Nymex Access Win32 Clients
It would be a clear advantage to JSW if Nymex Access converted its Implication Price Output
to be issued from the Server as the Client aspect of JSW does not support Market Liquidity Calculations
JSW supports the AnyAnyMarketReply and CmeWepMarketInformation which are real price outputs from TSI Servers

The authors of JSW are fully aware that any *off the shelf* competitor will have to be customised
to meet the business flow of support data from C21.
We feel our knowledge of current Nymex Systems places us as more competitive than the competition.
It is our view that we should be considered for producing the delivery of Nymex TSI over the Internet.

Java Service for the Web - The Java to TSI Server Connection

JSW registers itself with Central Server as a Remote TSI Service
JSW can do this
a) because it has a component [java:idlmaker] that reads data_desc and creates JSW IDL objects
b) the third party service extentions remain intact in Central Server even after the deprecation of Reliable Broadcast Server (RBS)

Java Service for the Web - The Model for Business Process Re-engineering (BPR)

This is a brief outline of the JSW Core
JSW is made up of: Model Objects, Model Events, Component Managers and Delegates

Model Objects use the basic premise of Entities.
To achieve a Trading System on an Exchange the following Entities are needed
"Contracts", "Markets", "Orders", "Firms", "Users", "Trades" and "Accounts"
From a Contract it is possible to find a Market and enter
an Order via a User within a given Firm using a particular Account
that matches a corresponding Order to produce a Trade.

Such entities inevitably get more complex such as a User may not be able to enter Orders in a given Contract,
let alone Market, as he cannot 'trade'.
Or a Contract may actually decompose into two Contracts ( A Product )
Or the Firm does not 'clear' Markets/Contracts.

Model Objects are thus Entities with sub-lists
The JSW design is that Component Managers marshall the instantiation of Model Objects and Model Objects sub-lists
according to the needs of the particular Component Manager.
Each Object can be instantiated horizontally (database) as well as vertically (messages)
The JSW by design works with partially instantiated Model Objects (sub-lists)
It has to be this way otherwise the only Component Mangers would be for the "Trading Service" Process
and we would be back at the complex vertical interaction instantation witihin TSI Servers

The Component Manager "DBLoader" tells all Model Objects within its scope to instantiate themselves
from the database
The manager can do this because each Model Object understands its task of "load"
This is horizontal instantiation However TSI would need to be amended to give Services a time window in a similiar fashion to the CME Server startup.

The Component Manager "ServerConnection" is more complex as
a) it has to conditionally forward messages to Model Objects
This is vertical instantiation
b) has to perform 'up and running push messaging'
It achieves its task by relying on a Delegate Component Manager MessageLoader which has a transient role to load all the dynamic message information.
Once up and running the third major Component Manager "Distributor" informs the model entities of messages
ServerConnection can optionally write all the in and out bound messages to file
It would take a major reverse engineer effort to achive that in ETSAPI.DLL
This was included as a design consideration within JSW

Distributor accepts registration from Model Objects that they handle messages from "ServerConnection"
The Distributor Component Manager should be used with any collection to create a Component Level Process.

Model Objects publish ModelEvents from their internal nested class Handler for messages
to any listeners and thus ensure the listeners for ModelEvents are *not* dependant on the IDL format
passed to "Objects" via "Distributor" from "ServerConnection"

This leads to the Component Manager "UserSession" whose job is to interact between jsp pages and Model Objects
which listens for ModelEvents from Model Objects and passes those ModelEvents to objects that are listening to UserSession.
In terms of the "Trading Service" Process this means UserSession passes ModelEvents to listening AppletConnection(s) via PeerServer
which in turn pass 'pseudo Model Events' to the Java Script Client via its callback Applet.
UserSession is a java coded jsp:bean that is session persistant within the Apache WebServer (TomCat)

The final Component Manger is PeerServer which maintains a threaded list of AppletConnections
Note if the client callback Applet fails to connect to the open FireWall port on the WebServer the Web Page Component Manager
(UserSession) creates pages using HTTP refresh rather than using the 'Holy Grail' of Server Push
(something that should *not* be confused with Remote Scripting a technique exploited in AddOrder)


To Recap

  • DBLoader/ServerConnection, one is needed for Model Object Instantiation
  • ServerConnection utilises a Delegate that filters data_desc IDL Messages if used at start up.
  • Distributor is called upon to send IDL Messages to the registered Model Objects
  • UserSession fires events to its listeners and is the interface jsp:bean for initial web page drawing
  • AppletConnection, A UserSession listener, passes changes to the Web Client Applet Socket, which knows what to do via Client loaded Java Script
  • PeerServer, the ModelEvent pump to the list of AppletConnections who translate ModelEvents to 'pseudo model events' that Java Script can utilise

A Brand New Component Level Manager Should

  • a) Pick its Model Objects
  • b) Determine and marshall instantiation ( "DBLoader" or "ServerConnection" )
  • c) Utilise a Model Message Handler ( "Distributor" --- "Trading Service" Default )
  • d) Create a ServerConnection assuming that instantiation was via a DBLoader that does not have a Delegate
  • e) Create a UserSession Manager responsible for output.

The tasks are
  • Instantiate - (Model Objects)
  • Receive - (Messages)
  • Publish - (Post Results)
This is the same design consideration in the JSW Model as adding a new TSI Server except of course TSI has the rather
nasty habit of embedding CLMP (Component Level Manager Processes) inside a TSI Server
For example both DCC (Daily Cycle Controller - Market Times) and ACC (Account Credit Checking) are both embedded in CME

This technique can only fully function with an extention to the TSI IDL message header
The lack of this header extention is the prime casue of new TSI Servers being embedded inside existing Servers

IDL Maker

This is a Java Program that creates Client messages from the data_desc IDL file
UserSession (for the likes of AddOrder) ServerConnection (as the TSI Service Driver) and the nested Handler class
in Model Objects all use the IDL package
Changing the Broker IDL would therefore be rather involved, that is until you realise the strength of the Model:
Why not add a new Distributor and add another nested Handler class to the Model Objects as a route to their instantation

The Way Forward

This is rather conditional on:

  • Nymex's interest in the JSW Product Suite
  • Purchase/Development Agreements
  • Retrospective fixes to TSI
The vendors and associates of JSW are in a position to write an entire trading system from Client Web Browser
through TSI Servers ( and even provide a different Implication and Market Matching Model )

Model Objects and Retrospective Fixes to TSI

Model Objects have the capacity to read from the database or messages as discussed before.
By locating these two methodologies in the same object the inconsistancies within TSI are easier to spot
and paradoxically makes it easier to find the code in TSI that should be corrected

Evolution of TSI is the best way, firstly align it better for Third Party Service Extentions.
Secondly consideration should be given to translating the TSI Servers into the JSW Model.
The model owes more to object orientated languages and could be applied in Java or C++

Model Objects - The Babble Fish

Model Objects are the core Business Objects for the Enterprise Application
The idea is that they are broadly constant in nature although clearly the odd attribute could be added or subtracted
Model Objects register with Distributor and speak the IDL language of that Distributor
Clearly different Distributors could be added that use a different protocol, Model Objects would have to register with the new distributor.
Model Objects issue Model Events as updates, which to the listeners like AppletConnection need to be translated into pseudo java-script, effectively then Model Objects speak a third language.
Finally Model Objects can provide the WebServer with the HTML code to render an element on a Web Page
This means Model Objects currently speak four 'languages'

The n-tier Architecture

To prove the requirement that nothing is constant, it is possible to flatten the model to Client/Server
This requires two new component managers/marshallers to support that model.
The whole middleware layer of Model Objects/Entities and IDL class objects are moved to the Client side without any syntax changes and function just as effectively
This proves the quality of the model design.




Services  JSW Model  JSW Client  JSW IDL  RUP  Cut Red Tape  Java Merlin Patch