1. IFX Messaging Fundamentals
Introducing the IFX Messaging Model
Welcome to the continuing series of IFX Orientation presentations.
In this presentation we will begin to dig a bit deeper into the IFX Messaging Model.

2. Standard Request-Response Common Object Definition
IFX Messages
Key Concepts
IFX Messages consist of a Request (Rq) and Response (Rs)
IFX Messages always act on one particular type of object
Responses include Status which indicate success or failure of the message handling and the state of the object
There is a well defined set of methods which can be applied to any IFX Object
Standard Request-Response
MsgRq
MsgRs
Let’s start by getting a few key concepts on the board…
First, the IFX Message Model is a Request-Response protocol…
And second - IFX Messages are always addressed to a specific type of object – and as we will see later, usually act on a single, specific instance of an object.
A key benefit of the Rq-Rs protocol is that the response is not only an acknowledgement of the success or failure handling the request, it includes a complete Status record of the result of the operation.
And the last key concept – for the moment – is that there is a defined set of methods which can be applied to any object in the standard.
Add
Mod
Del
Can
Inq
Aud
Adv
Sync
Status
Common Object Definition
Party
Payment
Account
Bill

3. Methods Key Concepts Implication
Every IFX method has well-defined behavior which leads to understandable responses and status codes
IFX Messages cause actions to be taken on objects – effectively changing the state of the object
Object management can usually be accomplished with a subset of available methods.
Implication
Messages can be understood conceptually just by reading the message name which includes the Object and Method
Every IFX method is intended to invoke specific actions and behavior by the service provider – the recipient of the message – on a particular object.
It’s worth noting that most objects can be managed effectively with a subset of the method list shown here– Add, Mod, Del and Inq for example. The complete list of available methods is shown here.
One final note, by default every IFX Object is intended to support the Status Inquiry (StatusInq) message and the standard includes a mechanism to return a StatusInfo aggregate without returning any of the object’s actual data properties. This supports data privacy considerations and a quick, efficient means to understand whether an object exists, and what it’s current state is.

4. Service Providers offer Services to Clients.
IFX Service Framework
The fundamental underlying principle of the IFX Framework is this simple:
Service Providers offer Services to Clients.
The standard is specifically designed to support stateless, multi-tiered communications between clients and servers
In other presentations we have discussed the fundamental underlying principle of the IFX Framework : Service Providers offer Services to Clients.
We also emphasized that the standard is assumed to be implemented on stateless, multi-tiered infrastructures where services may be clients of other services. Now we can talk about how the Messaging Model supports these principles.
In the IFX framework, collaboration and communication between service providers and specific services is the result of message exchanges. Let’s take a look at how this works in practice.
© Copyright IFX Forum, Inc. 2014
Slide

5. The IFX Rq-Rs Protocol Financial Institution Service Partner Client
The fundamental underlying principle of the IFX Framework is this simple:
Service Providers (Financial Institutions) offer Services to Clients.
Extending the concept :
Financial Institutions collaborate with other service providers to assemble a more robust set of services.
Client
Financial Institution
Service Partner
Object-Message Rq
Object-Message Rq
Object-Message Rs
Object-Message Status
Object-Message Status
Object-Message Rs
IFX Services are invoked with messages which consist of a Request and Response between a Client and Server (Service Provider/FI)
A Service is invoked when a Service Provider (show here as the FI) receives a Request (Rq) message from a client
The SP or FI performs the action requested and sends a response to the client. In its simplest form, this single interaction can be viewed as a service.
Let’s extend the concept a bit, to show how IFX messages can be forwarded from one SP to another. A FI can see that the message from the client is for a service that the FI has outsourced to another partner so it simply forwards the entire message directly to its partner
…who provides the service and sends a response to the FI…
…who in turn forwards the response to the client.
This set of interactions leads to the next key concept…
Services are invoked with request message from a client to a service provider
Responses include a Status Code, Severity [Info, Warning, Error] and Object Data

6. IFX Message Handling Key Concepts Implications
IFX Messages can forwarded directly from one service provider to another
Message responses are handled the exact same way
Implications
IFX messages can be readily handled at a message hub and routed appropriately
Back-end service providers may change without impacting the client-facing interface
Legacy systems can be hidden from exposure to clients and later replaced with new or upgraded systems.
IFX messages can be routed from any service provider to any other service provider. SPs may be other companies, or services provided at a different physical locations, server farms dedicated to specific functions, etc. And as we will see shortly, the message header contains enough information to reliably handle the necessary routing and authentication. Message responses travel back along the same path.
All of this is invisible to the initial client. So the architecture and behavior integrates very neatly into common EAI solutions including message hubs, load balancing solutions, front-end facades, etc.
Obviously, this is an ideal architecture to support outsourcing, too. The client is unaware of exactly who/what is servicing the request making it possible to change providers without impacting customers.
Lastly, this architecture allows for managed evolution in the SOA environment. Services can be re-factored, de-composed and reassembled at will. Only the destination of the messages change.
Clients – whether people or applications - are insulated from changes that happen behind the scenes.

7. IFX Services are Message Collections
Key Concept
In the IFX Framework Services are represented as a collection of Messages
Implications
Services can be designed with very narrow scope
Complex services are assembled as a collection of messages
One last note on the role of messages in the IFX Service Framework…
In the IFX Framework we define a Service as a collection of messages. From the list of messages identified in a service, its easy to get a high-level understanding of the scope of the service.
Note also, that because each IFX message acts upon one object, it is possible to define services down to a very discrete, granular level by defining a service as a collection of one or two messages although it is actually more common to find that services implement several messages to provide desired functionality.
Since there is no real limit to the number of messages defined in a service, it is also possible to describe large, coarse-grained or high-level services with a long list of messages.

8. Message Representation in BMS
Messages are represented in the spec as aggregates
The usual components are RqUID, RqHdr and xxxInfo
Just a quick word about how messages are represented in the IFX standard repository. Messages are represented as tags in the BMS user interface and every message is an aggregate that includes:
a unique request id (RqUID),
a header (MsgRqHdr) and
the object data (xxxInfo) necessary to satisfy the request.
Because every message has a unique ID (RqUID), it is possible to implement several key controls:
If a server receives a duplicate RqUID, it can avoid duplicating the action and simply return a Status that the request has already been handled.
A client may request that a server “Reverse” the effect of a previously submitted Request by providing the RqUID in a Rev message.
RqUIDs can be used in transaction logs as audit trails of which activities were conducted as a result of particular requests.
© Copyright IFX Forum, Inc. 2015
Slide

9. Message Headers- Intro
Key Concept
Every IFX message includes a MsgRqHdr
SvcIdent
CredentialsRqHdr
ContextRqHdr
FeeRqHdr
There are Rs equivalents
Implications
SvcIdent facilitates message routing
Credentials support authentication and authorization
ContextRqHdr facilitates communication about where a message is coming from
Every FX message includes a MsgRqHdr.
The MsgRqHdr optionally includes SvcIdent which identifies the Service that created the object and facilitates routing messages directly to the service provider.
We won’t get too deep into the Context or Fee information in this presentation. For now, just note that these items accompany every message in IFX.

10. Message Headers- Credentials
Key Concepts
CredentialsRqHdr
SubjectRole
Multiple extensions of abstract SecToken
SecTokenLogin
SecTokenCard …
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
abstract SecToken
SecTokenLogin
SecTokenCard or
or …
Implications
Repeating Credentials facilitates key security and authentication practices
Multiple credentials with different roles can be supplied
Abstract SecToken is replaced with a real Token when implemented.
It is worth noting that the CredentialsRqHdr is a repeating element. This allows for a message to carry multiple sets of independent credentials for situations that require multiple signatories, supervisor authorizations and the like as indicated in the SubjectRole element.
It also allows a financial to add its own credentials before passing a request to another provider.
A final note on this item – the specification identifies the Security Token as an AbstractAggregate that is replaced with a specific concrete token such as a login id, card token, etc. when the message is actually transmitted.

11. Messages - Responses Key Concepts Implications
All message responses include a StatusCode and Severity
Default behavior is to also return an Object StatusRec
Client can request additional information from object record using FieldSelect in the Rq
Implications
Conserves bandwidth
Protects privacy
Aligns with common technology practices
Object Status Records are designed to the nature of the object
Message responses can be very lightweight success/failure responses or go so far as to return the entire record that resulted from processing the request.
As noted here, every IFX message includes a Status Code and Severity indicator. By default, the message response also includes an object status record. Object status records are small segments of information designed to be contain a few fields commonly associated with the state or status of the particular object type.

12. Conclusion
There’s a lot more to be learned about the message model. We have only covered the fundamentals here. Look for other orientation materials to learn more about
Chaining messages together as an IFX Operation
How to use the RecSelect, FieldSelect and IFXPath to scope inquiries and limit the data elements being impacted by message
More details about identifying Fee-for-service
More details about the ContextRqHdr
There’s a lot more to be learned about the message model. We have only covered the fundamentals here.
Look for other orientation materials to learn more about these topics.
© Copyright IFX Forum, Inc. 2015
Slide

13. Additional Resources
There is much more to be learned using the resources shown below.
Direct Inquiries To
Organization
Name
IFX Forum
Judith Vanderkay, Director, Public Relations
IFX Community Forum
Available to Guests, Subscribers and Members
Reference Documents
Topic
Type of Document
Reference to Document
IFX Standards
IFX Standard Online
IFX SOA Implementation Guide
Complete guide available to members and subscribers
Sample content freely available
Thank you for your attention, your interest and your support of the IFX Standard.
More information can be found at these locations and at
© Copyright IFX Forum, Inc. 2014