110 likes | 208 Views
MPCC Architecture Review. January 2008. Background. This review is being driven on behalf of the market to ensure that the MPCC architecture is maintained at the highest possible level. The Goals for this exercise are to:
E N D
MPCC Architecture Review January 2008
Background • This review is being driven on behalf of the market to ensure that the MPCC architecture is maintained at the highest possible level. • The Goals for this exercise are to: • Help suppliers understand the current MPCC systems / technical architecture • Highlight the limitations of this architecture • Get feedback from Market Participants • Identify business requirements • Agree on the next steps
Current Architecture – Communications Link Technical Architecture • Communications protocol stack is in line with industry standards • TCP/IP is the standard comms stack for communication over the internet • SMIME and SSL (transport encryption) provide secure encryption of the Message and its contents as it travels over the internet • PKI is used for vetting 3rd Parties • XML used for packaging data Minor Limitations • Need to upgrade version of SSL • Need to investigate the usefulness of PKI as MODSSL is performing a similar function
Current Architecture - Suppliers MPCC Technical Architecture • CGI is used for interfacing to external applications • OnRamp is used for unwrapping and date time stamping messages • Webforms is used to create and amend market messages Limitations • Access 97 is not a suitable database (not secure and unsupported) • Windows 2000 is not secure enough • IE 5.0 is not suitable for new encryption technologies • CGI is inefficient at processing data • Software upgrades involves distribution of CDs.
Business Issues Market Participants • MPCC provides no new functionality • Message logs need to be regularly maintained • Limited visibility of message throughput ESB Networks • ESBN have recently adopted SAP’s application integration platform and more specifically SAP XI (an XML based message broker) for their SEM and future internal needs. • SeeBeyond OnRamp expertise will gradually become more limitedwithin ESBN Regulatory • New design could facilitate new market entrants • Opportunity to design a single market gateway. • Opportunity for one supplier to provide IT services for another.
Technical Issues • Current software has a maximum shelf life of 3 to 5 years • Significant parts of the technical architecture are unsupported • Access 97 is not a suitable database (not secure and unsupported) • Windows 2000 is not secure enough • IE 5.0 is not suitable for new encryption technologies • CGI is inefficient at processing data • Software upgrades involve the distribution installation of CDs. • There is a licensing overhead which may be removed through the use of open source software
Assumptions • Any new MP messaging component to be developed via a third party contract i.e. not directly by ESB Networks resources. • The favoured option should be that of a common MP messaging component as it would facilitate: • Testing • Integration • Open source software should be used
Next Steps • Provide a migration path • Get feedback from Market Participants on: • Business needs based on evidence from their experience of the current MPCC • Their preferences for development strategy