White Paper Briefing from Trace Financial on:     Incorporating Diversity of Financial Messaging Standards                ...
TABLE OF CONTENTS1       EXECUTIVE SUMMARY ..................................................................................
1 Executive Summary      Technology underpins the financial sector and is critical to strategies such as      Straight Thr...
service will support legacy standards equally well with contemporary standardsbuilt on XML. To achieve this support, key s...
2 Message Mediation      The multitude of financial messaging standards demands that a capability to      perform message ...
•   Perhaps most significantly the possibility to move design of a given                 mediation scenario into the hands...
4.4 or whatever message set we wish to deal with. The importance of this         approach is that the technical issues of ...
•   See also the following section “Message Enrichment”2.1.2.2 Structural Transformation between Standards         This wh...
2.1.3 Message Enrichment         The message mediation service has introduced the concept of message         transformatio...
•   The message itself may maintain a unique identification in the body of the                 message.             •   So...
•    To address the specific challenges of financial standards the dictionary                  should be supplied with, or...
The mediation service approach to parsing should allow for programmatic         extensions to the parsing process, either ...
structural correctness, next for inclusions of all mandatory elements, and finallythat all included data elements conform ...
mediation service itself then the condition must be escalated in some way to either         the originating application or...
Built-in test capability         A recurring problem for IT based solutions is performing reliable testing as changes     ...
2.1.9 Security         The mediation service must be                                                    ISO Defined Securi...
2.1.10       Performance, Scalability and Management         The critical nature of the mediation services requires that i...
3 Message Mediation – Architectural Role      Message mediation provides key capabilities that when combined establish a m...
services is the Enterprise Service Bus (ESB), commonly deployed in a Service         Oriented Architecture (SOA).3.1 Enter...
•   Message mediation (transformation, enrichment, etc.)             •   Security (authentication, authorization and so on...
accessed as a service as long as the interface remains unchanged the                 underlying implementation can be comp...
An area for confusion is found in the use of common technologies such as WebService standards and Message Oriented Middlew...
4 Mediation Technologies – Commercial Decisions      Having reviewed the functional attributes of a mediation service and ...
In these respects the mediation service should support a prevalent applicationframework such as J2EE or Microsoft .Net, an...
5 Conclusion: Mediation for Financial Messaging      The capabilities of a mediation service provide an essential architec...
Upcoming SlideShare
Loading in …5
×

Message Diversity: Financial Messaging Standards

2,138 views

Published on

Technology underpins the financial sector and is critical to strategies such as
Straight Through Processing (STP), regulatory compliance and driving customer
satisfaction.

In the last 25 years the importance of IT has grown enormously, and
with it there have been many initiatives to introduce standards that facilitate
improvements to the ability of financial organisations to conduct electronic
business.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,138
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Message Diversity: Financial Messaging Standards

  1. 1. White Paper Briefing from Trace Financial on: Incorporating Diversity of Financial Messaging Standards -An Architectural PerspectiveThis white paper was commissioned by Trace Financial for a ‘messaging standards in financial services’ industrybriefing. Mike Beeston, Director, Maven Associates is the independent author of this paper. He is well known inthe marketplace as a leading architecture and integration consultant 224-232 St John Street, London EC1V 4QR Telephone: +44 (0)20 7825 1000 email: info.financial@tracegroup.com www.tracefinancial.com
  2. 2. TABLE OF CONTENTS1  EXECUTIVE SUMMARY ................................................................................. 3 2  MESSAGE MEDIATION .................................................................................. 5  2.1  ASPECTS OF A MEDIATION SERVICE ....................................................................6  2.1.1  Message Structure Definition................................................................6  2.1.2  Transformation ................................................................................7  2.1.3  Message Enrichment...........................................................................9  2.1.4  Message Parsing................................................................................9  2.1.5  Validation ..................................................................................... 12  2.1.6  Facilitate Reuse.............................................................................. 14  2.1.7  Development and Testing Tools ........................................................... 14  2.1.8  Transactional Support and Data Integrity ............................................... 15  2.1.9  Security ....................................................................................... 16  2.1.10  Performance, Scalability and Management .......................................... 17  2.1.11  Support for Industry Standards ........................................................ 17 3  MESSAGE MEDIATION – ARCHITECTURAL ROLE ..................................................18  3.1  ENTERPRISE SERVICE BUS............................................................................ 19  3.2  SERVICE ORIENTED ARCHITECTURE .................................................................. 20 4  MEDIATION TECHNOLOGIES – COMMERCIAL DECISIONS ........................................23 5  CONCLUSION: MEDIATION FOR FINANCIAL MESSAGING ........................................25  2 of 25
  3. 3. 1 Executive Summary Technology underpins the financial sector and is critical to strategies such as Straight Through Processing (STP), regulatory compliance and driving customer satisfaction. In the last 25 years the importance of IT has grown enormously, and with it there have been many initiatives to introduce standards that facilitate improvements to the ability of financial organisations to conduct electronic business. The ongoing effort to develop and promote standards in the domain of financial messaging creates new opportunities for business efficiency through automation. At the same time, the diversity of existing and emerging standards results in complexities that must somehow be accommodated within IT architecture. Consider the variety of message standards that may be involved. On top of any bespoke and proprietary standards in use, a financial organisation may also need to process standards such as SWIFT ISO 7775, ISO 15022, ISO 20022, FIX, FIXML, FpML, RIXML, MDDL, Omgeo amongst many others. The introduction of technology based standards built using XML provides a degree of conformity in approach, but not necessarily in implementation, meaning that XML of itself does not provide a solution to the diversity that must be incorporated. As standards mature, older versions of a standard supported by production systems must coexist with new releases while migration tasks are performed. The need for coexistence can be for long periods of time affecting multiple systems. Critical to the success of any financial organisation seeking to maintain competitive advantage and continually introduce new efficiencies is the ability to manage the complexity created though these diverse message standards. Central to the ability to do this is a need for a message mediation capability that can be used to bring conformity to handling otherwise irreconcilable standards. Such a capability must be incorporated into the IT architecture and be part of the IT strategic vision and so aligned to business objectives. Message mediation is consequently an architectural building block that can support a number of architectural initiatives including the establishment of a Service Oriented Architecture (SOA). A message mediation service, supporting multiple architectural and deployment choices, must provide a non-invasive approach to meet these challenges. Such a 3 of 25
  4. 4. service will support legacy standards equally well with contemporary standardsbuilt on XML. To achieve this support, key standards should be built in to thetechnology and exposed using a common approach for creation of real-timetransformation between standards.Importantly the mediation service should not be “hidden” from the businessanalyst as a pure technology solution administered by a programming team butrather will allow the analyst to work directly with it, imparting their knowledgestraight into the solution, without the distraction of developing customprogramming code. 4 of 25
  5. 5. 2 Message Mediation The multitude of financial messaging standards demands that a capability to perform message mediations be at the core of any approach to deal with such diversity. In essence it is a problem best understood in terms of interface mismatches that must somehow be handled so that data processing objectives can be achieved. It is well understood that it is not viable to contemplate changing all participating systems to operate to the same interfaces, even were a single body to have authority to enforce such a change the effort and disruption would prove untenable. Techniques previously used with some success include: • Hiding the implementation of a message format from peer applications by “wrapping” a new interface over the existing one • Implementing a layer of “bridging” code that is designed to resolve format mismatches between two applications without change to the existing application code Such techniques provide some benefits, but suffer from limited reuse and fail to introduce any real degree of de-coupling between applications. In the case of the wrapper there is simply a new layer of code over an application, while for the bridge the logic is built and implemented between two applications and tends to be very specific in its functions. Mediating between message mismatch and diversity The optimal approach to manage diverse message formats is found through use of message mediation. This introduces an architectural ability to address the problem of interface mismatch both at run-time and build-time – right through to analysis and design. Such a mediated architecture, in contrast to its predecessors, provides a means to perform run-time resolution of mediation actions based on build-time design activities. This yields a number of benefits: • True de-coupling between disparate systems operating to incompatible standards • Greatly improved opportunities for re-use 5 of 25
  6. 6. • Perhaps most significantly the possibility to move design of a given mediation scenario into the hands of a business analyst rather than exclusively being the domain of an application developer2.1 Aspects of a Mediation Service A message mediation service must provide a number of features to claim a key role in enterprise architecture. Here we briefly consider these capabilities.2.1.1 Message Structure Definition To be expected, first on any such list is the ability to define message structures. There are a number of facets to message definition with the essential point being the need to capture all the information that is in the message definition documentation. For example, all the detail in the various SWIFT User Handbooks, the FIX Specifications (4.0, 4.1, 4.2, 4.3, 4.4), TRAX specifications and so on. The detailed technical specification must be captured in a common manner across all message sets rather than risk different representations for different message sets. Importantly this information should be maintained in such a way that a business analyst can work with it.2.1.1.1 Message Data Definition Messages are made up of data in defined formats and arranged according to structure using a particular syntax. Often there may be additional processing rules to be taken into account (e.g The ‘ExchangeRate’ is present if and only if the ‘OtherCcy’ is present). These messages definitions must be stored so that they can be subsequently used. To improve manageability and maintenance such storage is improved by building from basic data types and business components as defined in 15022 ISO standards (not forgetting 7775 and other non-ISO definitions). Assuming data can be represented in this way then these “business objects” should be used across multiple messages to represent ‘common’ business objects. An example underlines the merit of this approach. ‘Parties’ must be defined in a common way within, say, SWIFT 15022 messages yet in a different way than in FIX 4.3 which is different again from FIX 4.4. However it is important to identify the ‘Buyer’ or ‘Seller’ regardless of whether the data is formatted for SWIFT, FIX 4.3, 6 of 25
  7. 7. 4.4 or whatever message set we wish to deal with. The importance of this approach is that the technical issues of format and syntax can be ignored, instead allowing focus on the business role. Rather than working with data and formats attention is on business objects understandable by business analysts.2.1.1.2 Message Structure Definition Data definitions alone are insufficient to address the full complexity of the message structure. For instance, to store the message structure requires the ability to add structural type restrictions/features such as the use of repeating blocks, qualifiers and such like. This must be possible for any message set in use, so this must include both 15022 and non-15022 message groups. Naturally, for industry standard message sets, the goal is to have these pre-defined in any messaging technology and so avoid the lengthy ‘re-invention of the wheel’ involved when implementing from scratch.2.1.1.3 Rules processing The final ingredient of the definition phase is to capture rules or conditions that are necessary to ensure the validity of the messages.2.1.2 Transformation Also to be expected second on any list of such features is transformation between different message structures. Transformation can be further sub-divided to consider differences between agreed standards and the more traditional challenges of incompatible representations.2.1.2.1 Transformation Functions The building blocks for any transformation are functional tasks, examples include: • Mapping tasks: copying fields from input to output formats. This may include mapping one-to-many, many-to one and many to many. • Copy actions can be augmented by performing manipulation tasks on the data being mapped. These will include string manipulations (e.g. truncating a field to a given length), numeric functions (e.g. calculating the sum of two fields for an output field), date and time handling to reformat fields between different representations. • Conditional logic constructs will be used to handle more complex transformations 7 of 25
  8. 8. • See also the following section “Message Enrichment”2.1.2.2 Structural Transformation between Standards This white paper is very much concerned with the necessity to be able to transform between otherwise incompatible financial messaging standards. The mediation service should provide methods to handle diversity standards such as: • SWIFT 20022 • SWIFT 15022 • FIX • Omgeo CTM (Central Trade Manager) • FpML (Financial products Markup Language) • MDDL (Market Data Definition Language) • FIXML This problem is more complex than simply understanding these formats. Within each standard there is scope for incompatibilities between different versions that must be handled consistently. For example there should be compatibility between the ever expanding versions of FIX (4.0, 4.1, 4.2, 4.3, and 4.4) as well as the co- existence of different SWIFT formats.2.1.2.3 Representational Transformation between Applications Transformation challenges will demand greater flexibility than handling just standard message formats. For example it is common for legacy systems not to support industry standards having opted for a bespoke or otherwise proprietary format. These systems exhibit greater interface mismatches than message structure alone requiring the transformation service to provide features such as: • Bi-directional transform capability between XML and non-XML data structures • Data structure changes (e.g. csv into XML) • Data type changes (e.g. numeric to string) • Representation (e.g. fixed length data field into XML) 8 of 25
  9. 9. 2.1.3 Message Enrichment The message mediation service has introduced the concept of message transformation –changing the structure of a message in flight. Message enrichment extends this capability to add additional data to the message that was not included by the originating application at message creation time. Sources for this data are typically found in relational databases, such as Oracle, IBM DB2 and MS SQL Server, though other sources could range from a file system though to a Web Service invocation or even another message. The mediation technology should not constrain these choices, though good design practices and operational factors are likely to influence how enrichment is performed and particularly where the data used is sourced.2.1.4 Message Parsing Before a message can be transformed it must first be parsed to make it understandable to the mediation service. A common approach to this task is to implement an internal representation of message data that can be manipulated programmatically by the mediation service. This approach is successful because it allows the mediation service to make no assumptions about the incoming or outbound message formats. In essence the mediation service can operate on the “logical” message without concern for “physical” message. This approach is necessary because of the diversity of message formats that must be handled. The mediation service first parses the inbound message according to rules established at build-time and converts it to the internal format in use. Parsing therefore describes the process of deconstructing the message based on some predetermined criteria. This requires that first the message can be recognised in some way, and then to select and apply the correct set of rules. Messages can be identified using a number of approaches, for example: • Based on their inbound location to the mediation service – for example in a message queuing environment a message on a particular queue could be easily associated with a specific format. • Control data may be appended to a message as an independent header to be used by the mediation service 9 of 25
  10. 10. • The message itself may maintain a unique identification in the body of the message. • Some combination of all these approaches Optimally the architecture will seek to achieve the maximum de-coupling of all message producers and consumers using the most non-invasive manner possible. For these reasons XML is increasingly popular for representing message structures. The XML meta data can provide a suitable mechanism for message identification. Further, the nature of XML means that it need not of necessity be associated with a known message definition. Instead, if need be, the message structure can be traversed at runtime and processed programmatically in the mediation service. Such an approach underlines one of the appeals of XML – it is easily interpreted – and for mediation processing this can help development of a high performance solution. However, even for XML messages, to successfully process diverse message formats with strict processing rules it is necessary to pre-define the message structures to the message mediation service and use these during parse tasks.2.1.4.1 Message Dictionary Message identification is therefore the first step to allow parsing to a specific message standard. While this task can be easier for XML messages the diversity of standards dictates that the mediation service must be capable of processing both XML and other, traditional, proprietary formats. To recognise and subsequently parse a message to a known standard the mediation service must incorporate or access a message dictionary capability. A message dictionary is similar in concept to a data dictionary, and as would be expected contains descriptions of message standards - formats, structures, legitimate values, ranges and such like. The dictionary content itself is likely to be independent of any actual message encoding as it must incorporate messages definitions for many different format types. The dictionary should provide methods to create and maintain definitions though manual creation of a format and using import tools. • The Import process should be able to handle general purpose industry standards such as XML schemas and programming language constructs (COBOL copybooks and C header files for example). 10 of 25
  11. 11. • To address the specific challenges of financial standards the dictionary should be supplied with, or have available for purchase with subsequent maintenance, key message standards, such as SWIFT and FIX. This avoids the labour associated with setting up complex message formats and builds a shield from the annual changes to standards. • All the various messaging standards are now defined in a common way regardless of whether we are dealing with SWIFT, FIX, OMGEO, TRAX, XML, Proprietary back office and so on. Built-in support for financial message standards The message dictionary should support export functions to allow creation of message definitions of formats suitable for use by other applications. For example the dictionary should be capable of exporting XML Schema and DTD definitions. A further feature to consider is support for multiple message dictionaries. This could allow a runtime process to resolve a message definition based on some context information and select, for example, an enterprise dictionary of a departmental one. The value of the message dictionary concept is very high and can provide significant benefits. An Enterprise-wide message dictionary provides a single authoritive source of message standards in use. It acts as a point of control facilitating improved opportunities for managing change and achieving re-use.2.1.4.2 Parsing Once a message is identified it can be parsed so that other mediation activities can be performed against it. For clarity it is worth restating that while XML messages need not necessarily be parsed based on a message dictionary format, the complex nature of financial message standards combined with many being encoded in formats other than XML indicate that they will be parsed by use of such a dictionary. Parsing functions must be able to handle “simple” structures, such as Comma Separated Values (CSV) and repeating groups, through to “compound” structures such as messages built from business objects. Clearly XML constructs must be fully supported. 11 of 25
  12. 12. The mediation service approach to parsing should allow for programmatic extensions to the parsing process, either though introduction of additional parsers or by over-riding parsing actions with custom code.2.1.5 Validation Failure to properly validate messages against standards specifications prior to further processing can result in increased costs. In an ideal scenario the applications producing messages could be certain to generate accurate message structure on all occasions, in reality this is often not the case due to the complexity and ongoing evolution of the messaging standards themselves. Strictly, validation can be considered as an optional task in contrast to parsing, though often validation will prove necessary. While parsing is concerned with the syntax of a message – is it correctly structured - validation adds a further level of message inspection that confirms the semantic content is correct. A useful analogy here is to consider frequencies used for radio stations as a syntactical construct while the broadcast programmes represent the semantic content. In this analogy any device that can tune to the frequency can receive (parse) the content, but may still not be able to understand (validate) it if it is broadcast in another language. A parsing process, for example, may confirm that an element exists to contain a postcode. Validation could inspect the contents of this element to confirm that it is indeed a postcode rather than some other value, and that it is present if the message specification requires it. Performing message validation adds additional processing overheads that must be borne by the mediation service. The negative cost – that of not performing message validation - can often be easily measured, and so the benefits of thorough validation can be evaluated and justified. For example, SWIFT charges for any messages that have been negated (NACK) through syntax or network validation errors. Failure to properly validate can incur additional cost The validation process should allow control of the degree of validation performed. It may not be necessary to validate an entire message, nor perform all types of validation. Again, using SWIFT as an example, the message could be validated for 12 of 25
  13. 13. structural correctness, next for inclusions of all mandatory elements, and finallythat all included data elements conform to the SWIFT definition in terms of lengthsetc. This multi-layered approach allows a compromise to be found betweenprocessing overhead and risks to data quality.Architecturally there are benefits to placing validation in a separate mediationservice rather than implementing it in the applications generating such messages.A core principal of software architecture is the aim to achieve a “separation ofconcerns”. Here the concern is to perform high quality message validation againstcurrent message standards. Instead of replicating this functionality across allapplications, the solution is to identify and encapsulate the necessary processingand implement it as a reusable service – this allows a more effective decompositionof the software under development and improvements to the operation of thedeployed system.The net result is that applications can be developed without the additionaloverhead of implementing and, perhaps of higher impact, maintaining a validationcapability. Their objective remains to produce high quality messages, but now themediation service intercepts these messages and validates them against currentstandards prior to transmission for downstream processing. Thus the maintenanceeffort to ensure all validation is accurate and up to date can be focused on themediation service rather than many application instances. This fosters reuse ofcommon services implemented by the mediation service.The mediation service therefore must provide a high quality validation capabilitythat can flag errors and suspend further downstream processing of an errantmessage prior to cost being incurred or inappropriate processing initiated. Thevalidation service should sensibly share the same message dictionary used forparsing operations.There are a number of common approaches to consider for handing validationexceptions. One option could be to invoke a transformation that corrects the error.This strategy will be successful when errors are easily identified, such as amismatch between message format versions, and can be resolved throughrestructure of the available message data. Such an approach will not be viable ifadditional data is required to complete the message structure, though messageenrichment could help. If it is not possible to resolve the message errors in the 13 of 25
  14. 14. mediation service itself then the condition must be escalated in some way to either the originating application or some other architectural component responsible for further processing the errant message.2.1.6 Facilitate Reuse All elements described here – message definitions, transformations, validations and so on – should be managed by the mediation service to maximise the opportunities for reuse.2.1.7 Development and Testing Tools The functionality provided by the mediation service must be readily accessible and manageable. For development this means more than providing a rich environment for developing transformations and such like, though this is required. It is essential that the mediation services provide tools that can accelerate the use of the service and increase understanding between business analysts and development teams. Ideally the tool should allow the analyst to build standards based transformations that can be used directly by the mediation service without the need for an intermediary stage where the analyst’s designs are translated into transformation code by a developer for subsequent deployment. At the same time the tool must support operational controls and allow IT specialists to extend the business analyst’s work with optimisations and other technology specific functions. Business Analyst driven tools This means that while the mediation service is a highly technical component of the IT architecture, the tools used to create and maintain the message flows processed by the service should be highly intuitive and focus on the business requirements and not the technical implementation. Contrast this approach to a more traditional process of analysts documenting their requirements in some way, perhaps using spreadsheets, and passing these to a separate team for coding. This introduces a further layer of interpretation and delay in implementing change. 14 of 25
  15. 15. Built-in test capability A recurring problem for IT based solutions is performing reliable testing as changes are required. Incorporating diverse and evolving financial messaging standards requires that a testing capability be incorporated into the mediation service development environment. Such test facilities should maintain test data and allow management of that data, for example comparing test outcomes to previous tests with the same data. Testing should allow for activities such as impact analysis and regression tests as well as performance and unit testing for changes as they are developed. In summary, the development tools are able to exploit the features of the mediation service considered here. Of particular note is the reuse of message definitions captured from the volumes of User Handbooks and other specifications. The analyst is automatically guided through what is valid and what is not in a way that allows testing of specific message to ensure it complies with the published specification. The business analyst, best positioned to appreciate the business implications, now has a powerful quality assurance (QA) tool.2.1.8 Transactional Support and Data Integrity The criticality of the messages processed by the mediation service dictates that it must be capable of participating in transactions. The non-invasive nature of the mediation service means that a common design approach is to intercept messages as they flow between different applications. It would be unacceptable for the service to fail to honour at least the same level of transactionality and data integrity implemented by the applications passing messages. 15 of 25
  16. 16. 2.1.9 Security The mediation service must be ISO Defined Security Services capable of operating with the • Identification – who do you say various levels of security you are? required in the enterprise. • Authentication – can you prove These services can be that? implemented in a variety of • Authorisation – what can you ways with considerable scope do? for subtlety. For example, • Integrity – whatever data is sent has not been changed or consider a multi-part message, corrupted in some way. where each part may have • Confidentiality – data cannot different security needs and be seen be unauthorised could be encrypted using entities different keys. The mediation • Auditing – activities are service must be able to decrypt recorded for subsequent and re-encrypt the message review parts in order to transform • Non-repudiation – providing them. proof of message transmission The extent to which security is implemented will depend on a number of operational considerations. It is important that security is catered for without becoming a processing burden. 16 of 25
  17. 17. 2.1.10 Performance, Scalability and Management The critical nature of the mediation services requires that it provide a high performance and highly scalable solution. Message transformations should be deployed and managed using some form of version control – this could be implemented as part of the service itself or built using development tool interfaces to external version control tools. In general terms it is also desirable to seek: • Broad platform support • Wide support for technologies such as J2EE, ideally the mediation service can be embedded within applications as well as providing standalone implementation choices • Support for distributed deployments and subsequent operational control • Management support and planning information2.1.11 Support for Industry Standards When considering message dictionaries the need to provide support for financial messaging standards was noted. In addition to messaging standards the mediation service should support technology standards wherever appropriate. Examples include, and mentioned elsewhere in this paper, J2EE, Web Services and XML initiatives amongst many others. 17 of 25
  18. 18. 3 Message Mediation – Architectural Role Message mediation provides key capabilities that when combined establish a means to intercept messages, identify, parse, validate, transform, enrich and return them into the process flow. The mediation service can therefore be considered a core architectural component of an enterprise’s IT architecture. Satisfy tactical needs and address strategic goals Operating as a core architectural component indicates that the mediation service should be considered in conjunction with other architectural components. The mediation service has specific capabilities which can be used either in isolation – to handle particular tactical requirements – or in tandem with other components in support of strategic objectives. The value of the mediation service for isolated, discrete usages is often more easily defined. When the mediation service takes a strategic role, its value is greater, but can be harder to quantify – it becomes a case of “the whole being greater than the sum of the parts”. In this scenario the various architectural artefacts cooperate to produce a combined effect greater then that of their separate effects – that is, they operate in synergy. Any form of architectural synergy requires careful planning – the overarching need is to ensure that IT supports business strategy. How can message mediation assist increased architectural synergies that in turn support business strategy? The discussion of validation processing earlier presented the architectural principal of “separating concerns” between different software artefacts. In the case of validation the possible merit of a validation capability for financial messages implemented as a separate service from multiple application instances was explored. This “separation of concerns” allows software design to be more effectively performed through decomposition of otherwise complex systems into comprehensible components. The mediation service itself can be considered a coarser grained artefact than the validation services it incorporates. Viewing the mediation service in its full architectural context opens up new synergistic opportunities for its use in tandem with other architectural components. The compelling architectural design that incorporates mediation 18 of 25
  19. 19. services is the Enterprise Service Bus (ESB), commonly deployed in a Service Oriented Architecture (SOA).3.1 Enterprise Service Bus An ESB is generally recognised as a design pattern that addresses the need for advanced inter-application communications. The ESB provides a highly functional communications backbone rich in services such as mediation and transformation, routing, security, operational and management control, built to support standards and boasting many application interfaces. An ESB provides an excellent example of the synergistic benefits possible through implementation of a number of architectural building blocks to a well defined design and strategy.3.1.1.1 ESB Characteristics • Enables inter-application communication (the bus). Supports many communications models built on asynchronous messaging, e.g. o Fire and forget o Publish/subscribe o Request/reply o Broadcast, etc • Extensive interface connectivity o Frameworks: .NET and J2EE o Application suites (ERP, CRM, etc.) o Technologies (databases, transaction managers, etc.) o Language bindings (Java, C# etc) • Sophisticated routing, providing features like location transparency and infrastructure agility • Transactional integrity • Built to support industry standards, particularly: o Web Services o XML o Business process models (e.g. OASIS) and languages (BPEL – Business Process Execution Language) • Event driven processing 19 of 25
  20. 20. • Message mediation (transformation, enrichment, etc.) • Security (authentication, authorization and so on) • Development environments (.NET, Eclipse and others) • Operations and systems management A high profile feature of the ESB concept is the ability to perform real-time in- flight mediations as described in this paper. Such facilities assist in development and control of solutions such as Straight Through Processing (STP).3.2 Service Oriented Architecture While an ESB provides an architected design for inter-application communications, a related architecture provides a backbone to support business activities – the Service Oriented Architecture, or SOA. With service orientation there is a formal definition of how a service is implemented and how it can be used – this provides a high degree of de-coupling and so introduces greater agility into the IT environment. Services can be accessed without application “knowledge” of where they are located or how they are implemented. Multiple services can be invoked in sequence to support business processes. A popular technology for definition and access to such services is Web Services, however SOA neither predicates the use of Web Services nor is it true that a solution built to Web Service standards is necessarily adhering to an SOA.3.2.1.1 SOA Benefits • Enhanced corporate agility – service orientation allows an organisation to respond to market changes and new opportunities with greater speed. • Reduction in development and maintenance costs – the SOA engenders reuse throughout the IT environment. Building or changing applications can be a case of working at the interface (portal) layer of the IT architecture. • Improved reliability – re-use of tried and tested services not only reduces development time but improves the quality of applications. Further, the nature of SOA (when built on an ESB) introduces new opportunities to improve IT provision and exploit IT initiatives such as Grid computing. • Enables an incremental approach to change in the IT environment – established systems can be exposed as a collection of services. Once 20 of 25
  21. 21. accessed as a service as long as the interface remains unchanged the underlying implementation can be completely overhauled or even out- sourced if appropriate.3.2.1.2 SOA Characteristics • Services formally defined using standards (WSDL) – how they can be accessed and used • Services are published in some way to allow discovery, either at build-time or possibly at run-time • Underlying service implementation is invisible to the service consumer • Maximises de-coupling between applications • Services commonly represent a business function • Services are built to a very modular design • Services are independent of platform, transport and location3.2.1.3 ESB and SOA Contrasted The ESB and SOA appear to have jointly become the most widely discussed concepts in IT architecture at this time. It has been suggested that implementation of an ESB results in realisation of an SOA – though this is not strictly the case. The ESB represents the maturing of many technologies, both standards based and proprietary, which have been in mainstream use over the last decade or so. This is particularly true in the last few years as standards have formalised around these technologies. Likewise, the SOA is far from a new concept, though contemporary technologies lend themselves to development of solutions that implement SOA principles. The ESB provides the “plumbing” that links together disparate and otherwise incompatible applications. This can be achieved through a service oriented approach or techniques associated with Enterprise Application Integration. Service orientation changes the way applications are built and accessed – it is something more than connectivity and communications and requires an organisation to approach development of IT assets in a fresh style. 21 of 25
  22. 22. An area for confusion is found in the use of common technologies such as WebService standards and Message Oriented Middleware to implement the ESB and anSOA. This says much for the value of such technologies in IT architecture, but itdoes not mean that if you have an ESB you have an SOA. Many organisations willhave some form of ESB, even if it is not named such, which has evolved from earlyinitiatives to address application integration challenges. Implementation of an SOAultimately requires a shift in perspective within the organisation to developservices rather than traditional applications aligned to business units. SOA strategy is developed hand in hand with the ESBTo be successful an SOA strategy will encompass creation of an ESB, or be built toexploit an established ESB – the current standard of ESB technologies provides thebedrock on which to pursue service orientation elsewhere in the Enterprise ITarchitecture. Human Interface Layer: Web-based,A simple, high-level view of some portal, etcarchitectural layers shows how the ESBenables connectivity between Process Management/Orchestrationapplications and data and also supportsthe SOA. Service Interfaces (SOA)Thus the ESB and its core mediation Enterprise Service Buscapability is an essential architecturallayer in support of not only resolving the (incorporating mediation services)challenge of diverse financial message Enterprise Applications and Datastandards but also facilitating increasedagility in the enterprise. 22 of 25
  23. 23. 4 Mediation Technologies – Commercial Decisions Having reviewed the functional attributes of a mediation service and placed it in an architectural context all that remains is to consider how to approach selection of a mediation service. Historically these questions might have started with a “buy versus build” discussion. Today the market is well catered for and so competitive pricing is the first factor to strongly help the buy decision. Perhaps more significant is the complexity of the mediation service itself, the development and subsequent maintenance effort – essential in order to maintain pace with continually developing standards – are simply too high to be a cost justifiable project in most organisations. This final point underlines the merit of buying a mediation service – development effort should be directed at building solutions that are aligned to business strategy, not IT strategy. Wherever practical it is sensible to buy technology and build business solutions with it. The alternative – to first attempt to build the technology – is sure to restrict IT to business alignment. Choosing to purchase mediation technology requires assessment of commercial offerings and vendor suitability. The earlier section “Aspects of a Mediation Service” introduced the features that must be sought from commercial solutions. Additionally the vendor qualities should be considered in terms of stability, strategy, financial sector experience, support and services capabilities. A proven track record with case studies available for reference is assistance, though can only inform rather than decide the final decision. Vendor certification with standards groups is essential for financial messaging When considering a commercial solution to support financial messaging solutions it is essential to seek out a vendor that actively supports financial message standards in their products and is appropriately certified by standards bodies. For example SWIFT accreditation for compatibility to the SWIFT network. For the selected product to deliver the architectural benefits considered in the section “Message Mediation – Architectural Role” it must maintain a high degree of integration with mainstream technologies and standards as well as extensibility to enable support for non-standard applications. 23 of 25
  24. 24. In these respects the mediation service should support a prevalent applicationframework such as J2EE or Microsoft .Net, and ideally both in some capacity. Atthe same time it should not predicate use of either framework. Ideally themediation service should be deployable as part of such a framework if desired, aspart of an infrastructure capability, or standalone based on architectural designsand objectives. Using J2EE as a reference, the mediation service should beaccessible using EJB and MDB, but equally it should be possible to use themediation service from a Java application not hosted in an Application Server.A desirable deployment option to consider is the possibility of “embedding” themediation service in another architecture component. Such an approach willprovide additional flexibility when developing architectural alternatives.In terms of extensibility the mediation service should provide opportunities forcustomisation though well designed exits along with the possibility to include codeto perform custom functions during message transformations, parsing andvalidation.The mediation service needs to support other mainstream commercial technologiesthat will be used along side it in the IT architecture. Due to their popularity in thefinancial sector IBM’s WebSphere MQ is an obvious candidate for compatibility, butany transport and integration technologies must be supported, where they areincluded in the architecture. 24 of 25
  25. 25. 5 Conclusion: Mediation for Financial Messaging The capabilities of a mediation service provide an essential architectural building block to address the challenges experienced by financial organisations seeking to manage many message standards. This is particularly so when the mediation service is implemented within a Service Oriented Architecture that improves IT agility and business alignment. The mediation service offers a number of significant advantages to the financial organisation seeking to manage a diverse number of message formats: • Improved corporate agility – reduce time to market • Capability to resolve message format mismatches between disparate applications in a non-invasive style • Product solution that allows business analysts to be an active participant in the creation of mediation solutions along with traditional IT roles • Out of the box standards support including message formats (e.g. SWIFT, OMGEO etc) and technologies (e.g. Web Services) • A common approach to all mediation activities, treating legacy applications in the same way as contemporary standards based applications • Provides extensive opportunities for re-use, incorporates features like the message dictionary to further such imperatives These capabilities are essential in order to address the challenge of diversity in financial message formats. When viewed in the context of an architectural strategy that exploits the mediation service deployed as part of an ESB underpinning a SOA then the potential return of the mediation strategy is further increased. Change is constant, so an IT architecture designed to support change is necessary to eliminate the brittleness that has caused IT solutions to become a constraint to agility. The mediation service is a critical component of this architecture and provides a foundation for long-term business benefits through greatly increased corporate agility. 25 of 25

×