3 Business Process Architecture

3 BUSINESS PROCESS ARCHITECTURE

3.1 Introduction

The FpML 4.0 Schema was the first release of the specification to place a messaging framework around the product descriptions to describe the context and use to which the information is expected to be put. This section describes a small set of complex types and elements that comprise a simple message framework that is used as the basis for defining business messages and processes suitable for use in a 'Business-to-Business' (B2B) or 'Application-to-Application' (A2A) communications process.

These definitions introduce a new set of ideas that previously could not be used in FpML because of its reliance on DTDs as the formal specification of the grammar. The following sections describe the reasoning behind the features used in the framework as well as a description of several business processes.

3.1.1 Why Business Messaging?

Increased efficiency in financial markets can only be achieved through greater automation of transaction processing and use of electronic messaging (e.g. the exchange of information directly between computer systems with as little human interaction as possible). In order to achieve this all the parties involved in such communications must agree on four things, namely:

· Representation

There must be a common representation of a transaction, product or other reference data item that is accepted by all the parties.

The core FpML grammar defines a standard vocabulary for derivative based transactions and products that can form the basis of a messaging standard. As new messaging applications are considered the scope of the core grammar will need to expand to encompass the additional types of data referenced in these messages.

· Semantics

All the parties must have the same interpretation of the information expressed by the representation.

The work of the validation working group provides a set of rules to ensure that a product definition conforms to the market definition for that product. The FpML rule set will expand and evolve over time as new financial products and message types are added to the grammar.

· Business Process

All the parties must follow the same business processes and respond appropriately to any communication they receive.

To support business process the messaging working group has extended the core FpML grammar to add a framework for defining messages and their content. This section describes some business processes and shows how they could be implemented as message exchanges.

· Transport

The parties must agree on the communications transport used to interconnect their businesses.

FpML does not endorse any particular messaging transport for communication. The choice of transport is left to the implementer although in practice we expect only a few to be found suitable.

Disagreement over the first three of these features will mean that FpML users will potentially have to implement, maintain and support different software systems for each FpML aware service or application that they use. Supporting multiple communications transports is typically not that difficult although it does incur additional operations costs.

3.1.2 Design Assumptions

In order to create the messages and business processes described in this document some design assumptions had to be made, principally:

· Throughout this document we have assumed that message exchanges will be carried by an asynchronous passing of messages over a highly assured transport, such is provided by a messaging queuing system. This form of transport is commonly used today in the finance industry (e.g. AMQP, Apache QPid, FIX engines, MQSeries, MSMQ, RabbitMQ, SwiftNet Interact 'Store and Forward', etc.).

One important consequence of this decision is that error cases related to non-delivery do not have to be considered (e.g. once accepted a guaranteed messaging queuing system WILL ALWAYS deliver a message) although the 'freshness' of the message may need to be considered (e.g. has the message been stuck in a queue waiting to be delivered for a long period of time). Similarly message queuing system can normally eliminate duplicate messages so these are not considered either.

· There is no requirement for message sequence to be preserved over the message transport. Message sequence must not be expected to be repeatable nor predictable.

In practise enterprise message buses cannot be expected to halt the enterprise to preserve sequence. Hence this is not a requirement of FpML.

· Some of the business processes are 'long-running' in that once initiated they may remain active for a considerable time before completing (e.g. a request to confirm a trade may take many hours as it is dependent on the time of arrival of the matching trade). During this time the process may generate periodic notifications to the originator of the request and/or other parties. Such notifications will appear in the message stream set to a participant intermixed between other response messages.

An implication of such 'long-running' transactions is that the 'service provider' will contain a complex 'state'. The service should make suitable provisions to persistently record its state so that in the event of a software or hardware failure it can recover transparently without its clients having to resend any information.

· All business process definitions must have an observable completion. The set of messages defining a business process needs to be complete. In addition, timeouts must be defined if necessary.

Implementers attempting to construct software based on these protocols using a non queuing transport (e.g. WebServices, DCOM, CORBA) will need to implement a reliable message layer to encapsulate the current message sequences (e.g. a get/put message interface using sequence numbers to detect lost or duplicated messages and positive/negative acknowledgments). The W3C site contains links to proposals for such extensions for use with WebServices.

3.1.2.1 Transport Characteristics (NEW SECTION)

3.1.2.1.1 Purpose

The definition of the FpML business processes assumes the use of reliable messaging, meaning high predictability. Generally, increasing reliability increases latency. The assumption of reliable messaging is provided to make it easier to design standard business processes and messages. If the transport characteristics were not defined, the business process definition would be ambiguous.

3.1.2.1.2 Layers

The protocol that is used for exchanging FpML messages is defined in being in three main layers:

· The Business Layer is the higher layer and deals with FpML documents. The exchange of FpML documents is fully described in the message choreography and the structure of the FpML documents is fully described by the schemata and the related validation rules. The Business Layer is equivalent to adding a Layer 9 to the OSI model.

· The Message Transport Layer is the lower layer and deals with transport messages. The implementation of this layer is outside the scope of FpML since it varies. The Transport Characteristics apply to the Message Transport Layer. This layer is equivalent to adding a Layer 8 to the OSI model.

· The layer immediately beneath the FpML Protocol is the Messaging Application Layer. FpML allows any Messaging Application that supports the requirements of the Transport Characteristics defined below. The Messaging Application Layer is Layer 7 of the OSI model.

3.1.2.1.3 Reliable Mode

Specifically, the transport characteristics that FpML assumes in order to implement most of its business process definition are defined by:

· The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.

· A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.

· The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.

· Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.

· For each FpML document sent, sixty seconds is the maximum duration of time in within which all its preceding FpML documents must be sent.

· Messages are addressed to nought to many receiving messaging endpoints.

· The maximum duration of time within which a message must be delivered is sixty seconds.

· Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.

· The messaging transport system must ensure that the FpML document is well-formed, W3C Schema valid, validated against the constraints defined in the validation rules, and validated against the message choreography. It is important to note that the messaging transport system is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems. In addition, multiple messaging transport systems can be chained together into a single messaging transport system.

· The messaging transport system must ensure that the message is kept available until it is received by the messaging endpoint or until it is expired because it was delivered later than the maximum duration of delivery time. So, it can be queued on the messaging transport system within the maximum delivery time duration, but it can be queued at the destination indefinitely.

· The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message.

3.1.2.1.4 Bulk Transfer Mode
In some processes such as Portfolio Reconciliation or Position Report, FpML assumes the following transport characteristics:

· The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.

· A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.

· The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.

· Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.

· Messages are addressed to nought to many receiving messaging endpoints.

· The maximum duration of time within which a message must be delivered is ten minutes (600 seconds).

· Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.

· The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message. [DIAGREEMENT ON THIS POINT]

3.1.3 Styles of Messaging

In general computer systems commonly use two styles of messaging to exchange information between each other, namely:

· Request/Response

A style of exchange in which one system sends a message to the other to asking it to perform some function, the result of which is encapsulated in an appropriate response and returned.

· Notification

A style of exchange in which a system sends a message describing a business event that has occurred and may be of interest to others.

The receipt of either kind of message may cause additional messages to be generated and sent as part of the processing to obtain information from other systems or to inform them of the business event underway.

3.1.4 Transport Independence

In general, four layers of specification are contained in a XML Standard. A multi-layer approach allows implementers to choose the most appropriate technology for a given situation. It allows development and modifications within one layer without affecting or requiring changes to the others..

From the top down, the four layers are:

3.1.4.1 Business Process

This layer specifies the way in which any business process is defined, such that is understood and executable by people and applications. A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable. Examples of business processes in the derivatives domain are the affirmation process, the confirmation process, and the matching process.

The FpML 4.0 Specification models business processes in UML sequence diagrams.

3.1.4.2 Document

This layer corresponds to the FpML document definitions. It provides a set of abstractions specific to financial derivatives but also a set of elements which are not context specific (such as “Party” and “Price”).

3.1.4.3 Messaging

The Messaging layer addresses the need to record session and communication settings for message transport in order to enable coordination between parties in a business transaction.

The FpML 4.0 Sschema explicitly models ‘delivery’ related information as part of the message itself. Some transports (i.e. SOAP, ebXML, etc.) allow such information to be placed in the ‘envelope’ that surrounds the message during delivery.

Including a standard header within FpML messages increases consistency by providing a single format for delivering information regardless of the physical transport, ensures that it will be persisted if the message is archived, and allows more flexible use of features such as digital signatures.

3.1.4.4 Transport

The Transport Layer provides a point to point connection so that one server can send messages to another server and they will arrive uncorrupted and in the correct order.

The FpML Message Architecture defines a message structure that is independent of the underlying transport protocol, such as SMTP, File Transfer Protocol (FTP), Standardized Messaging Middleware, HTTP, etc.

3.1.5 Control Over Content

The design of a grammar must strike a balance between the degree of flexibility it allows and the complexity of its validation. An overly lax grammar allows the construction of documents that, whilst syntactically correct, may have no valid business interpretation. On the other hand a very rigid grammar may require many more grammatical productions in order to enumerate only the valid combinations.