Misys FusionCapital Summit version 6.0 has now been released. A new major version number means that that there has been a pretty major change in the architecture of the system : Version 3.0 brought the Straight Through Processing architecture, and Version 5.0 brought us Summit FT. The big change in version 6.0 is ‘The end of Classic’.

Last week, we looked at how the Summit GUI architecture changes in version 6.0. This week, we will look at the handling of Documents, Payments and the Straight Through Processing subsystem.

There’s only one way to do it

The STP architecture was introduced fully in version 3.0, providing an event driven architecture. Prior to this, Summit used a collection of driver programs to generate payments and documentation : Accounting driver in cash mode, incres_driver, swift_driver, payext_driver, bulk_dispatcher and friends. These all had equivalent services in STP : Expected Flow Server, Document Server, PreSettle Server, Settle Server, Dispatch Server. Over time, many more services have been added to the STP architecture, and there are now a wide range of STP services – some of which are not related to documentation or payments at all.

In the same way that the pre V5.x GUI has been dropped in version 6.0, the pre V3.0 driver processes have now been dropped. You will now need to handle all document processing with STP services. Converting the old servers over isn’t technically too difficult, but you will need to retrain users to work in an STP environment, where they will need to process exceptions as an when they occur, rather than getting bulk drops of data when the relevant driver runs. There is much more flexibility in the STP approach, and from a user efficiency standpoint it’s by far the better approach. Dropping the old approach makes sense – as code no longer needs to be duplicated between two implementations of the same basic business requirement.

The End of Orbix

As I said last week, Orbix has been removed from V6.0. This leaves a bit of a gap, since Orbix provided a number of key features to STP servers:

• A way for servers to find each other, via the itnaming_daemon
• A way to start and stop servers remotely, using the itnode_daemon running on each machine
• A communications protocol ( IIOP ) and libraries to allow inter server communication

I discussed the server location problem last week, and the solution is the Summit Naming Service, which runs inside Tomcat. This is a near drop in replacement for the itnaming_daemon.  The Summit Management Tool ( which I also touched on last week ) is now the way to start and stop servers remotely. Both of these technologies have been in Summit for the last few versions, and can be rolled out now.

A New Form Of Communication

This still leaves the problem of inter server messaging, and this has been solved by moving the messages over to the JMS 1.1 protocol. Misys now provide Apache ActiveMQ along with Summit to handle the routing of messages between servers. JMS is a well understood and widely used protocol. JMS and ActiveMQ together provide a number of features:

1. A communications protocol ( JMS 1.1 ) and libraries to allow inter server communication
2. A place to publish updates and messages ( eg. “I’ve just updated trade 1234567F” )
3. Message routing to single or multiple subscriber queues ( eg. “Send this update to the TradeProcessing queue and the ExpectedFlow queue” )
4. Message persistence – ie. a message will hang around until *something* processes it ( eg “Don’t remove this from the Documents queue until a Document Server processes it” )

Item 1 is the necessary feature to replace Orbix. The bonus items are all needed within Summit, and come for free with JMS/ActiveMQ. Orbix doesn’t provide these facilities – they are currently (versions 2.6->5.7) handled by the Distribution Server, a Summit program.

End Of The Distribution Server

The role of the Distribution Server (DS) as a central hub for publishing updates, message routing and message persistence is now redundant. The Distribution Server is very much an Orbix process, with a lot of Orbix handling code, and rather than re-implement it in a post Orbix way, the DS is joining the Classic GUI and the old Documentation drivers in the rubbish heap. This is fine, but there were a couple of other things the DS did that are not replaced by ActiveMQ.

Firstly, the DS used to be the broker for new System Ids – when you wanted to book a new audited record, the Audit_Id field value comes from the DS. You could dispense Ids direct from the database using the pALLOC_SID stored procedure, but the performance is utterly tragic – the dmTRADEID and dmSID tables lock up far too easily as the system loads up. This functionality has now been moved to a new Tomcat web service – the IDGenerator service. You’ll need roll out the IDGenerator service inside Tomcat.

Secondly, right at the core of the DS was the thread that used to order Summit transactions, so that everything happens in a repeatable order. We’re talking about the process that allocates the SequenceNumber field in dmAUDITLOG and dmTRDAUDIT. Again, JMS and ActiveMQ don’t do this, so another STP process – the Sequencer Server now provides this feature. Sequencer Server is the spiritual successor to the DS – like the DS, it’s the first STP server to start, the last to stop, and none of the other servers are going to do much without it.

Getting Ahead Of The Game

Unlike the new Summit FT GUI components, which are already available in Summit 5.6 and 5.7, albeit not widely used, many of the new STP components are new. You won’t be able to have a play with the IDGenerator or Sequencer Server until you have a V6.x Summit tree installed. With the arrival of V6.0 though, there is a lot more Java in the Summit tree : The Tomcat Webapps ( IDGenerator, SMT, ETKSessionService, ETKPoolService, ft_middle_ws, MonitorService, SummitNamingService ) along with Tomcat itself and ActiveMQ are all written in Java. It’s just a educated guess from me, but expect to see a lot more Java appearing in the Summit tree over the next few years, and if you don’t know anything about Java programming – now might be a good time to learn!