Conversion guide summary SIXP Java API

This is a conversion guide showing how to convert from an old Java API solution to a new Java API solution. It covers a fairly 
common scenario when a client is subscribing to quote information, for example SSE stocks, and real time news and putting it all 
in some kind of data store. The data store used is SQLite and it should be fairly easy to convert to any other data store that 
is table, column and row based, for example another SQL or NOSQL solution. SQLite will store the information in a file called 
data.db in the bin directory. To view the SQLite db there is a lot free alternatives on the internet.

The example program will read a request file including different queries to SIXP. From these queries the program will dynamically 
create tables in the SQLite db. When this has been done the program will create columns based on the infotype received from the server. 
The infotype is a column description sent from the SIXP server for every subscription that is setup to the server. After this 
updates will fill the fields of the database.

A note on the SQLite adapter is that is it horrendous slow. The first thought was to replace it with a faster adapter but after some 
consideration it was left in place. The reason for this is that it is proving a point on the performance of the back end. If the end 
solution, in this case the SQLite adapter, is not able to handle the updates in the old Java API a queue will build up inside the API 
that is not visible. In the new API, that do not have a internal queue, a queue must be build by the API user otherwise the API will 
break and throw an error. A queue solution is shown in the new API solution.

Description of the old Java API

As noted earlier the old Java API has a internal queue and is single threaded from the API point of view. The implication of this 
is that a API developer do not have to think about delays, blocking calls or threading issues. This is of course a big plus but 
to be able to get exceptional performance the new Java API is threaded and asyncrounus.

The old Java API uses a SixEventHandler that is central in setting up connection to a server. A implementation of a SixResponseListener 
is set up and attached to the SixEventHandler. All updates from all subscriptions will go through this response listener so most of 
the client logic is put inside this file. A request is first setup to get the infotype, this is done automatically in the new Java 
API. After this a subscription is setup.

After the subscriptions has been setup the infotype will be returned in the processGetFieldSetResponse. From here we will setup a 
dictionary to be able to lookup the name of a certain id, this is  done automatically in the new API. From this information the 
columns in the database will be created. From this point processDataResponse will receive updates from the SIXP server.

The central way to connect an update to a table in the db is to use the cookie that is include in every request.

Full news text is a special case in both the old and new API so it requires extra explanation. For every new update received the 
full text is not included. Therefore a new GET request is setup to the SIXP server to get the full text. To be able to update the 
correct row in the db a dictionary must be setup to connect the new cookie(request identifier) to the record that is going to 
be updated when the full news text arrive.

Description of the new Java API

The biggest change with the new Java API is that there is no longer a internal queue and the API is multi threaded. What this means 
is that most solutions need to implement a work queue that is running in a different thread to not running the risk of blocking a 
event in the API. In the example code a ConcurrentLinkedQueue is used. Blocking events in the API can lead to all sorts of errors.

In the new API the SixEventHandler is replaced by the class implementing the interface ISessionEventListener. Here you find events 
that are connected to login, logout, on connected. From the SessionEventListener class a data listener is set-up similar to 
SixResponseListener in the old API. The DataListener implements IRequestEventListener. These events handle such thing as fieldset 
received och data updates.

Conversion points to think about

1. Infotype handling is simplified. In the new API field names can be accessed directly in the OnRecordUpdate
2. Cookies (request identifiers) are not used in the new API
3. A separate request is needed to fetch news text both in the old and new api
4. A worker queue is needed in the new API to be able to handle periods of intensive updates
5. To build persistence over sessions, us the Key field not record id as record id will change between sessions
6. The new API version is implemented using the asynchronous version of the API. This is the recommended way to implement.









