eMCI - NonStop Ò Banking Middleware

1. eMCI - NonStopÒ Banking Middleware Artur Stefanowicz eMCI Architect Finance Industry Practice Manager, NSIS Compaq Polska

2. Agenda • Business case for eMCI • eMCI foundations • Architecture • Key ideas • Roots and References

3. No single system fits all bank’s needs, so... They assemble their infrastructure by incorporation of ‘best in bread’ apps, what results in… Interconnection maze and... Loss of consistency, Distributed and isolated data, Different platforms, apps, etc. Strong, global competition Time to market is key Non stop operation is a must Dramatic change for Customer perspective Implicit acceptance of ever growing technological frontiers Evolutionary vision Rapid evolution of business needs & vision Unification infrastructure very important Once upon a time banks were stable and predictable...

4. Business case for eMCI • Difficulties with banking application integration • different formats & protocols • different access mechanisms • Ad-hoc integration model consequences • many interfaces - maintenance problems • need to develop couple of interfaces when adding new app • Economy of integration efforts • Time & cost to deploy product, channel, service • Availability ?...

5. 24 hours a day 7 days a week 365 days a year

6. Business case cont. • In the electronic banking area the most impacting problems are: • many sources of transactions • separate databases, lack of synchronization which leads to inability to represent current coherent view on accounts • hard to route transactions to different host apps • changing requirements for handling transactions from different distribution channels • Lack of defined Architecture/Vision for Echanels evolution

7. Integration problems Private interfaces Each app needs a separate adapter for each application it cooperates with

8. eMCI - base ideas • Universal banking middleware platform • both on-line… • and batch applications • Architecture for broad range of electronic banking solutions • with defined evolution path • Fault-tolerant, 24x365 service delivery

9. Base functionality • De-coupling of transaction sources from transaction destinations • reuse of application gateways • Reliable transaction routing between banking applications • Business transaction flow modeling • using transactional scripting • Unification of transaction representation • XML-like • Continuos operation • based on RTR

10. eMCI - example

11. Base architecture Gateway Kernel External Back-End System Transaction Routing External Front-End System Internal Message Format Private Interface

12. eMCI Architecture - key ideas • Allow seamless integration for broad range of apps, minimize efforts for adding new app • Isolation of transaction sources and destinations • Internal Message Format (XML) • GTW-CTC-Destination model • Full control over transaction execution • Scripting mechanism for transaction flow definition • Detailed run-time information & control • elaborated config & mgt infrastructure • Fault-tolerant transport layer • RTR-CRTR-eMCI

13. Software components

14. eMCI Transaction Scripts • Key eMCI concept • The way to define business rules for transaction execution • Each transaction type has its corresponding transaction script • Executed by CTC - scripting engine • CTC bridges RTR server and client channels • Scripting languages • Perl, Tcl with RTR extensions embedded • Platforms: NT, UNIX, OpenVMS … Linux

15. Controlling Tx flow ATM switch iso8583 Gateway Bank MicroKernel Common Authorization Database Host Banking System PROFILE, IBS90,etc Call Center Transaction Routing Internet Banking Electronic Banking Transaction flow

16. eMCI Tx Scripts API • High level abstraction for transactional communication • API Calls • Call, AsyncCall • CheckReply, GetReply • Broadcast • Independent Tx calls • Simple and easy to use

17. Script example ... my ($text) = @_; # independent tx example - explicit tx control IndepStartTx(1000); IndepAsyncCall($IND_APP, $IND_SVC, $IND_FUN, $text); if(IndepAcceptTx() < 0) { # if error of independent tx, reject initiator tx... return -1; } # standard, implicit transaction return Call($APP, $SVC, $FUN, $ARGV[0]);

18. Configuration and management CFG INTERFACE CFGMGR Interfejs CFG-PROTOCOL CFG-PROTOCOL Interfejs CFG-PROTOCOL Interfejs CFG-PROTOCOL Komponenty MCI

19. eMCI Console

20. eMCI transport • CRTR - OO layer over RTR • C++ Framework • Buffer encapsulation, dynamic type recognition & object construction, automatic compression and large message segmentation • Automatic dispatching to appropriate service • Encapsulates both transactional and broadcast communication in RPC-like, call-back model • Handler based model for server structure • Simplified server structure • All common mechanisms implicit

21. eMCI/CRTR handlers #ifndef _ECHO_HANDLER_HXX_ #define _ECHO_HANDLER_HXX_ #include "mci_handler.hxx" /** * Handler odsylajacy z powrotem wszystkie otrzymane komunikaty. **/ class CEchoHandler : public CMciHandler { public: HandleResult OnMsg1(const string& msgIn, string& msgOut); HandleResult OnMsgN(const string& msgIn, string& msgOut); HandleResult WasProcessed(const string& msgIn); HandleResult OnPrepare(); void OnAccepted(rtr_reason_t reason); void OnRejected(rtr_reason_t reason); }; #endif

22. eMCI Server example int main(int argc, char* argv[]) { try { ... server.RegisterHandler( svc_no, fun, new CEchoHandler); server.Run(); } catch (CErrException& exception) { cerr << "[--------- EXCEPTION ----------]" << endl; exception.PrintDescrOn(cerr); exception.PrintTraceOn(cerr); } return 0; }

23. CFG GTW GTW CTC EVL GTW KNL KNL CTC GTW CFG EVL GTW Process topology MCI/GTW Machines MCI/BMK Machines MCI/CTC Machines KNL RTR RTR

24. eMCI roots • Handlobank project ‘98/99 • Electronic Banking Architecture for BRE ‘98 • DirectDebit project for BRE ‘98 • Requirements analysis (July ‘98) • based on professional market reports • competing products analysis • Internal project eMCI (Oct ‘98) • v2.0 released in March ‘99

25. References • Handlobank • Bank Przemyslowo-Handlowy • Bank Rozwoju Eksportu