Business-to-Business Integration(B2Bi) Architecture

Roy Abraham




1) Introduction
The B2Bi is a part of overall enterprise architecture. There are six important criteria which, fully define an enterprise architecture, they are,
a) Components: Elements or units upon which enterprise applications are built. For example, objects in Object Oriented Architecture and services in Service Oriented Architecture.
b) Message: How components communicate to each other. Describes not only the contents but also the temporal and special relationship of the messages. For example, structured and unstructured contents sent synchronously or asynchronously.
c) Topology: The general layout of the components and their messages. For example, hub and spoke or message bus.
d) Constraints: Constraints on components and messages such as multiplicity, concurrency, transient nature, sequencing etc.
e) Layers: Grouping and abstraction of components and messages according to the functionality and homogeneity. For example, presentation layer, business logic layer and persistence layer.
f) Rationale: Describe the pros and cons of selecting a particular architecture.
This paper is mostly devoted to topology and layered architecture. There are in general four types of topologies are prevalent in enterprise architecture such as hub and spoke, message bus, service bus and hybrid. However, there is considerable difference in the organization, responsibility, administration and layout of each of these topologies with respect to B2B and EAI enterprise relationship.

2) Hub and Spoke Topology

In this topology, a hub connects to one or more spokes to form a star layout. The communication among spokes is possible only through the hub. In a B2B hub and spoke topology, each node is most likely owned and managed by separate trading partners. On the other hand, all the nodes are within an enterprise environment for an EAI hub and spoke. The nodes of B2B hub and spoke are implemented across the firewalls. An EAI hub and spoke is implemented within the firewalls.

2.1) B2B Hub and Spoke: The B2B eMarketplace is a typical example of this type of topology. Each supplier and buyer trading partners connects to a hub, which itself may be another trading partner for routing the messages. In most cases, hub is managed and administered by a standard organization by that vertical industry. The spokes need to be compliant with the specifications provided by the standard organization especially messaging protocol and transport protocol. A number of vendors provide pre-packaged on-ramp applications to facilitate setting up the communication between hub and spokes. For example, suppliers and buyers may send messages such as purchase order and invoice to market place using on-ramp application interfaces. Two common message protocols used are Commerce XML (cXML) of Ariba and XML common Business Library (xCBL) of Commerce One. The HTTPS is the most commonly used application layer transport protocol.


Figure 1: B2B Hub and Spoke topology for B2B eMarketPlace.


2.2) EAI Hub and Spoke:
The Hub and Spoke integration described earlier follow this topology. Both hub and spokes servers reside inside the firewalls of an enterprise and managed and administered by the enterprise. Similar to on-ramp application used by spokes to communicate with the hub in B2B hub and spoke described earlier, an adapter is used to communicate between the hub and spokes in this topology. Since all the nodes are within the enterprise application system, the enterprise need not have to follow any specific standards for implementing message and transport protocols. B2B integration architecture of EAI hub and spoke with B2B hub and spoke are shown in figure 2 for outbound message and figure 3 for inbound message. The enterprise application system in the EAI hub and spoke shown is for a Buyer, for example.

In the figure 2, the core business of the enterprise application system (of Buyer, for example) creates a Value Object (VO) encapsulating business information for a purchase order. The VO is marshaled to an XML document and sends to on-ramp in the integration server either synchronously or asynchronously through JMS. On-ramp maps the XML message to the xCBL (for Commerce One) or cXML (for Ariba) and sends to the eMarketPlace server over HTTPS. The eMarketPlace server (for example, Commerce One’s Market Site) routes the purchase order to the appropriate supplier.


Figure 2: Architecture for an outbound message involving B2B and EAI hub and spoke.



Figure 3: Architecture for an inbound message involving B2B and EAI hub and spoke.

The supplier process the purchase order and create an invoice in xCBL format and sends back to the eMarketPlace server which in turn routes to the initiating buyer. The Buyer on-ramp receives the invoice message and maps xCBL to XML message. In general only the business data in the xCBL is mapped to the XML message and send to business processing in the application server. The meta-data such as the envelope information of xCBL is persisted directly from the integration server itself as shown in figure 3.

3) Message Bus Topology: In this topology, every server node in the enterprise connects to a message bus. If two nodes need to communicate, the source node publishes the message to the message bus and the recipient node subscribes to that message. This type event model can be asynchronous if the message bus is connected to a Message Oriented Middleware (MOM) provider. For example, if the message bus provider is built on MQSeries or JMS, it facilitates asynchronous mode of messaging. Each message published and subscribed must be unique in the message bus to avoid name conflict. In other words, message must be name space qualified. If the nodes are located and managed in different trading partners, then the configuration is a B2B message bus topology. If all the nodes are within an enterprise application system, such a configuration is EAI message topology. The nodes of the B2B message bus are implemented across the firewalls. On the other hand, all the nodes are within the firewalls in an EAI message topology.

3.1) B2B Message Bus: Individual trading partners connect to a message bus. In most cases, such a message bus is managed and administered by a standard organization by that vertical industry in which the trading partners belong. Examples of such message bus are Global Data Synchronization Network (GDSN) of UCCNet and SWIFTNet. However, each node must follow the specification standard enforced by the message bus on messaging and transport protocols. For example, the Catalogue Item (CI) messages exchanged between manufacturers and retailers in a GDSN message bus must be EAN.UCC compliant as shown in figure 4.


Figure 4: B2B Message Bus topology for UCCNet.


3.2) EAI Message Bus: The message bus integration described earlier follow this topology in its simplest form. However, an enterprise-wide message bus catering to different divisions or sections of the enterprise located in the corporate network backbone within the corporate firewall provides a better topology albeit complex. This Enterprise Message Bus (EMB) offers better monitoring, performance and security of the message. This is because many of the tools available provide a wide range of features like clustering, persistent queue, brokering (routing the message) and so on. The architecture of such a topology is shown in figure 5.


Figure 5: Enterprise Message Bus topology.

For example, the application server in the Pricing division publishes a message to the EMB, which is subsequently subscribed by the ERP server in the Management division. After completing the management decision, ERP server publish another message to the EMB, which is subscribed by the CRM server at the Marketing division.

4) Service Bus Topology: Service Bus topology is based on web services and Service Oriented Architecture. Although very similar to message bus topology, service bus is based on open standards. Each node, the service provider (WSDL producer) exposes the services it is going to provide through a WSDL. The WSDL interfaces are published and registered with a service bus connected to a UDDI server. A node, the service consumer searches and finds the right service from the service bus. Then that node binds and invokes the service based on the WSDL and creates a SOAP instance and sends to the address of the node as described in the URI of the WSDL interface. Note that the node (service consumer) which consumes the WSDL (WSDL consumer) is the one which creates the SOAP message (SOAP producer). A service bus may provide additional asynchronous based messaging, for example using a MOM provider. The same node may act as service providers for some services and service consumers for some other services.

If the nodes are located and managed in different trading partners, then the configuration is a B2B service bus topology. If all the nodes are within an enterprise application system, such a configuration is EAI service bus topology. The nodes of the B2B service bus are implemented across the firewalls. On the other hand, all the nodes are within the firewalls in an EAI service bus topology.

4.1) B2B Service Bus: Individual trading partners may connect to the service bus as service providers, service consumers or both. Although web service can compartmentalize the various vertical industries into yellow pages, a service bus mostly handle services for one or two similar vertical industries. It is less complex and easier to manage and administer for a standard organization by that vertical industry in which the trading partners belong.


Figure 6: B2B Service Bus topology.

4.2) EAI Service Bus
The service bus integration described in the section 1.5 of chapter 1 follow this topology in its simplest form. The enterprise-wide integration of applications is made possible by architecting an Enterprise Service Bus (ESB). In this topology, the service bus is located in the corporate network backbone within corporate firewalls. This topology is best suited when disparate application systems such as legacy, mainframe and J2EE are spread all over the enterprise.

For example, Marketing and Management divisions publish their CRM and ERP services the service bus through their respective WSDLs. The application server in the Pricing division uses the ERP WSDL to send a SOAP message to the ERP server. The same way, ERP server uses CRM WSDL to create and send a SOAP message to CRM server as shown in figure 7

Figure 7: Enterprise Service Bus topology.
5) Hybrid Topology
In many situations, an enterprise is forced to adapt a topology which is a combination of previously discussed topologies due to the legacy commitments. However, the most common one is a combination of hub and spoke and message bus or service bus. Since message bus and service bus provides a high level of loose coupling among the nodes, it best suited for integration of divisions (or departments) in the enterprise. The ERM servers in a division are connected to an integration server forming a hub and spoke. The integration server in each division forms the nodes of a message or service bus as shown in figure 8.


Figure 8: Hybrid topology with hub and spoke and service bus

6) Layered Architecture
A typical J2EE application environment consists of 3 tiers; presentation, business logic and persistence as shown in figure 9(a). However, in B2Bi, presentation tier is replaced by an integration tier. If an application provides both web interface and B2B interface, then both tiers has to be provided as shown in figure 9(b).



Figure 9: Layered architecture: (a) with web only and (b) web and B2Bi
Each layer contains components of similar functionality pertaining to that layer. For example, presentation layer consists of JSP and Servlet components. As the architecture become more complex, dissimilar and inappropriate components starts appearing in each layers. To prevent this, a more expanded or n-tiered architecture may be implemented. In general, the entire complex architecture can be divided into three tiers; front end tier, middle tier and back end tier. The layers contain J2EE components involved in the J2EE design patterns1. In many architectural scenarios, it might be difficult to compartmentalize the component functionalities among the layers. The integration layer and messaging layer share many common features. For example, MOM (Message Oriented Middleware) tools perform more or less same functionality of both integration layer and messaging layer.

6.1) Front end Tier: The front end tier consists of client layer, proxy layer, presentation layer, decorator layer and controller layer for web interface. For B2Bi, the presentation, decorator and controller layers are replaced with an integration layer. The layers in the front end tier communicates with the client (web and B2B), does the initial processing of the request data (or final processing of response data) and sends the information to the middle tier for a request message (or receives the information for response message). The layered architecture of front end tier is shown in figure 10.


Figure 10: Layered architecture for front end tier.

• Client Layer: Client tier provides user interface with users and actors. Usually in J2EE architecture this is implemented through a Web Client such as a web browser. However, this can be extended to different kinds of clients such as Wireless Client, CORBA client, web service client and B2B client.
• Proxy Layer: Those system components which reside in De Militarized Zone (DMZ) or semi-secured area are encapsulated in the Proxy layer. Caching, system recognition, authentication through LDAP, vendor specific credential validation, store and forward, reverse proxy are some of the services provided by the components reside in this layer. Usually proxy servers provide this functionality. Note that this proxy layer must not be confused with the functionalities provided by the classic proxy design pattern described by the Gang of Four.
• Presentation Layer: This layer provides the View part of the Model-View-Controller (MVC) design pattern. In most of the J2EE implementations, this is done using JSP. This layer logically located in a web container. Usually Client tier and Presentation layers are combined to have a single presentation layer. In most of the enterprise systems, considerable amount of resources are consumed by the presentation layer as it is the "brain" of user interaction. The recent evolution of XML as Model and XSLT as View in the presentation layer, further improved the functionalities of this layer. The need for various presentation techniques required in enterprises for multitudes of evolving client technologies such as Wireless and print servers results in a thick and fat presentation tier.
• Decorator Layer: Decorator layer encapsulates functionalities which intercept client messages to present to the system and vice versa. For example, pluggable decorating filters may be used for I18N whenever necessary. Incoming requests and outgoing responses (preprocessor for requests and post processors for response) are redirected to a filter which does necessary conversions based on the user Locale. Software filters may be used for formatting dates, currency conversion and language texts. Other functions may include checking security credentials, document format conversion, document type conversion (eg. XML to Java Bean or Form Bean) and image format conversion. In J2EE, this may be implemented through Servlet filters.
• Controller Layer: The controller layer controls the interaction between the front end and middle tiers. This is implemented through Java Servlets which act as the Controller part of MVC. The controller layer functionality includes redirection and invocation services, maintaining conversational state of clients through web sessions (HTTP Session) and handling exceptions thrown by middle tier. Note that conversational state of business logic is provided through Stateful Session beans which reside in Business Logic layer. Data transfer across this layer is provided through Form Beans which act as View Helper and through Value Objects and these constitute the Model part of MVC. This layer is logically located in a web container. Presentation layer and Controller layer together constitute the Model-2 variation of MVC design pattern.
• Integration Layer: The integration layer is the B2B counter part of the three layers described earlier. This layer provides B2B related plumbing services to the application such as mapping, transformation, XML processing etc. This layer is logically located in an integration server.
6.2) Middle Tier:
The middle tier contains service layer, interaction or access layer, façade layer and business logic layer. The layered architecture of middle tier is shown in figure 11.

Figure 11: Layered architecture for middle tier.
• Service Layer: The service layer encapsulates domain specific services to the underlying sub-systems. This includes Java Naming and Directory Interface (JNDI) look up services to EJB home interfaces, Java Message Service (JMS) components, data sources, integration adapters, and JCA connection factories in the respective subsystems. Service Locater components which are usually implemented through stateless EJBs, are located in this layer. Very often this layer is too thin such that it can be merged with the interaction or business logic layer. All the layers in the middle tier are logically located in an EJB container. Data transfer across the layer is provided through Value Objects.
• Interaction Layer: The interaction layer holds Business Delegate1 components which allows loose coupling between the front end and middle tiers. The interaction layer also contains B2B specific and web specific components. In the absence of a service layer, interaction layer performs the JNDI look up related services. The exceptions thrown and re-thrown from the underlying layers are captured in the interaction layer and converted into user friendly messages to the controller layer (for web application) and business friendly messages to the integration tier (for B2B application). In a pure web application, data validation may be achieved in the front end (preferably in Controller tier), close to the client. However, in a mixed application environment (such as web as well as B2B), validation needs to performed preferably in the first common layer to avoid unnecessary duplication of data validation. The interaction layer fits the bill for this.
• Facade Layer: The Facade layer consists of session facade1 which provides a single point of access to the underlying business components in the subsystem. This enables loose coupling of components in business logic layer and the components in the interaction layer. The client view of the business logic layer is completely hidden and is made available only through the session facade. For example, clients can not access any Entity beans directly except through the session facade. Usually session facade components are implemented as a stateless session bean. However, if non-web clients such as CORBA clients or B2B clients need to access business logic components, to maintain state a stateful session facade may be added in this layer.
• Business Logic Layer: Business Logic layer abstracts the problem domain for the application. This layer enforces the business rules, logic and process. Business logic is implemented through Session and Entity Beans. Bulk access across the tier is provided through Value Objects.
6.3) Backend Tier:The data access layer, persistence layer and messaging layer are the major layers in the backend tier. The layered architecture of back end tier is shown in figure 12.

Figure 12: Layered architecture for backend tier.
• Data Access Layer: The data access layer consists of Data Access Objects (DAO) which abstracts and encapsulates all the access to the data source. The DAO manages the connection with the data source to retrieve and store data irrespective of storage type such as relational, object-oriented, native XML etc. Thus data access layer decouples the business logic and the persistence mechanism.
• Persistence Layer: Persistence layer permanently saves the object state by providing database CRUD (Create, Retrieve, Update and Delete) services. The java business objects follow hierarchical model (Tree structure) data structure. However, the most popular mode of persisting data is through relational model (Table structure) due to its inherent advantage of storing and retrieval of data. The implementation of the persistence can be accomplished through JDBC (data centric), entity beans (application centric) or using JDO (object centric). As the popularity and performance of native XML databases improve and XML CRUD tools such as XQuery, XUpdate and XPath receive wider acceptance, afore mentioned hierarchical data may be persisted as is.
• Messaging Layer: Messaging layer encapsulates the messaging services provided by the application. Although both synchronous and asynchronous messaging components can be encapsulated in this layer, asynchronous messaging components such as JMS components and MOM components are more common. Components in this layer are used to send and receive messages from the enterprise message bus in the corporate message backbone.
7) Conclusion
The B2B architecture does not stand alone. It is part of enterprise architecture. Hence this paper discussed both B2B and EAI integration architecture together in the J2EE framework. All the important architectural topologies and architectural layers are discussed in this paper. The right architecture must be selected on a case by case basis based on technology, functional and non-functional requirements.

References:
1. Alur, D., Crupi J., and Malks, D. Core J2EE Patterns, Prentice Hall, 2001.
2. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
____________________________________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this blog is used or reproduced without the written consent from the roychettan@gmail.com

e-Business Standards Implementation in Financial Industry

Roy Abraham

1) Introduction: Business-to-Business (B2B) integration refers to electronic commerce business model in which business information is exchanged between business enterprises or trading partners.B2B integration is not a new concept. It has been with us for a long time. First, it appeared in the horizon in the form of EDI (Electronic Data Interchange). With the advent of internet, Java and XML (eXtensible Markup Language) based B2B integration is evolving and undergoing a completely different outlook. The following is the list of advantages of B2B integration.
• Reduce human intervention and automate the trading partner business transaction,
• Reduce cost and increase productivity,
• Reduce transaction life cycle,
• Increase the security of the transaction,
• Better data accuracy and integrity,
• Better monitoring,
• Less subjective and human errors,
• Better reusability and portability.

As described in the previous section, B2Bi rarely stands alone. In many cases B2Bi is implemented in conjunction with other technologies such as BPM (Business Process Management) architecture and STP (Straight Through Processing)

2) B2B integration and Business Process Management (BPM) Architecture

Business Process Management deals with defining, analyzing, managing and implementing the interaction among internal systems, people and external trading partners. In traditional systems, Business Logic (objective part) and Business Rules (subjective part) in a Business Process are tightly coupled. Hence, any requirements change in either one results redesign or re-factoring (depends on the extent of the change) of business process. However, laws, rules and regulations of certain business process change constantly. This necessitates the decoupling or loose coupling of Business Rules and Business Logic. Business Logic is hard coded (means, business logic change depends only on requirement change). On the other hand, transient changes in rules, laws and regulations are encapsulated in Business Rules. These Business Rules may or may not need human intervention. Business Logics are implemented in Application server (for example, an EJB or IoC container). Business Rules, which need human intervention is implemented in Workflow server. Business Rules, which do not need human intervention is implemented in Rules Engine.

A typical example is the life cycle of a tax return in IRS (Internal Revenue Service). Rules and laws continuously change as new legislation come into effect every year. However, it is extremely difficult to change or re-factor the existing applications which process the tax returns as per every change in the tax law. The best strategy is to separate business logic and business rules from the business process. The subjective and transient tax features are encapsulated in business rules. The objective and permanent tax features are encapsulated in business logic. Whenever a tax law changes, the business manager create a business rule associated with the new tax law and store in a rules engine. When the system receives a tax return, application server applies business logic and rules engine applies business rules on tax return data. If the outcome of this processing triggers an audit, tax return is sent to a workflow for appropriate human intervention. Such a BPM architecture using an Application server environment, Workflow server and a Rules engine environment is shown below.

Figure 1 BPM logical architecture

BPM provides a holistic approach to Software development involving technology (objective) and human behavior (subjective). The important elements which constitute BPM are described below.

a) Business Logic: Defines the objective behavior of permanent nature. In software terms, this attribute never changes unless and until requirement changes. This also implies that there is nothing absolutely permanent in software development. The core business model of the enterprise is captured in the business logic.
b) Business Rules: Defines the objective behavior of transient nature. However, this attribute changes within the confines of the requirements. This encapsulates the forces outside the enterprise which influence the core business model such as market forces and government policies. The daily or weekly promotion sale of the company or changing the sales tax structure due to government policies are few such examples.
c) Work flow: Defines the subjective behavior of transient nature. This is where the human aspect interacts with the core business model. For example, a customer agent partially forgives the overdue penalty of a customer and her supervisor completely forgives it due to good payment record of the customer.
d) Trading Partner Interaction: Defines the business relationship with other enterprises. In the current integrated business environment, business to business transaction is inevitable in one way or other.
e) Enterprise Integration: Defines the integration of various software and data assets within the enterprise. It can be legacy assets accrued over the years such as main frame or software written in C language.
f) Life cycle management: Almost every business model has to perform a sequence of tasks from inception to fulfillment to complete the business process. It can be a claim processing, an order fulfillment of a shopping cart or a loan processing etc. BPM provides the state management of individual steps involved in the Business Process.


Figure 2: Elements of BPM

g) Monitoring: The entire software development project is business requirement driven. The business requirement is stake holder driven. Hence, directly or indirectly the business manager is the ultimate stake holder of the software development. However, the business manager may not have the technical acumen to understand the complexities of the software process. She has to believe what she is told by the development team. This poses considerable challenge to the Business Manager on day to day operations of Business Process. The monitoring tools of BPM provide such a visibility to the business process. Monitoring may include but not limited to Business Activity Monitoring (BAM) of Key Performance Indicators(KPI), Six-Sigma, compliance monitoring (like SOX) etc.

3) B2B integration and Straight Through Processing (STP)Straight Through Processing allows end to end information movement through trading partners without human intervention. STP is analogous to Supply Chain Management (SCM) in the manufacturing industry. STP has it origin in the trade life cycle from initiation to settlement in capital markets and payment transactions. Lately, STP concept is embraced by other financial sectors such as banking and mortgage industry. STP is very closely related to BPM described before. How STP, BPM and SCM are related is described below using an example.

A weather forecasting company informs a building equipment retailer that there would not be any snow in Virginia until third week of January and may not store snow shovels in Virginia, but stock pile in Kentucky and Colorado. The retailer sends this information to snow shovel manufacturer and others in the supply chain. A trucking company which already sent a truck load of shovels to Virginia can re-route to Kentucky or Colorado. With the introduction of RFID (Radio Frequency Identification), the efficiency of SCM reached the consumer level. This way Supply Chain Management (SCM) tools efficiently manage inventory. Using RFID, a SCM tool can monitor the movement of a digital camera from the manufacturer to wholesaler to retailer until it is delivered to the customer.

What is SCM to manufacturing industry is what STP to financial industry. Once a business data is created by an Originator, it may pass through a number of organizations until it is delivered to a consumer. Such a business document requires a unique id (similar to RFID) so that STP tools can monitor it. Life cycle of a mortgage is typical example of utilizing STP. For example, when a lender originates a loan, the subsequent mortgage pass through different trading partners such as secondary market, vendors, service providers, custodians, warehouse lenders, servicers and investors using B2B transaction. Thus STP provides life cycle management of a business document spanning multiple trading partners. Usually, the unique id used in mortgage document is Mortgage Identification Number (MIN). In the tax return example described previously, may use social security number as the unique id. Using this id, disparate enterprises can monitor and process the tax return end to end. Currently, eBusiness standards such as FIX and SWIFTNet provide STP based services.

4) FIX
The Financial Information Exchange (FIX) is a message standard intended for use between trading partners to facilitate the electronic exchange of information related to securities transaction. An important feature FIX provides is the Straight Through Processing (STP) solutions. This is accomplished by streamlining message life cycle processing through confirmation, settlement and reconciliation. FIX specification is independent of any particular communication protocol, security protocol or network model. The FIX protocol is defined in two levels: session level protocol and application level protocol. The session level protocol deals with the delivery of data. On the other hand, the application level protocol deals with the business related data content. In traditional FIX implementation, a FIX engine manages the session protocol layers and application protocol layers. The FIX engine is responsible for managing the FIX message exchange among the trading partners.

When he FIX engine of a trading partner A (acts as client) connects to the FIX engine of a trading partner B (acts as server) and a FIX session is established. A FIX session is defined as a bi-directional stream of ordered messages between these two trading partners. A FIX session consists of three parts, Logon, Message Exchange and Logout. The Logon is responsible for the creation and maintenance of the telecommunication link, authentication of the client by the server and initialization of the message. After successful logon, actual messages are exchanged. The messages can be administrative messages or application messages. The administrative messages deals with the utility features of the protocol such as heartbeat, test request, resend request, sequence reset etc. The application messages contain business related messages such as quote request, quote cancel, quote status request etc. After completing normal message exchange, the session is terminated with the exchange of Logout messages.

The FIX messages (both application and administrative) consist of a standard header, message body fields and terminated with a standard trailer. The header defines mostly meta-data about the message such as message type, length, destination, sequence number, origination point and time. The standard trailer consists of signature information and checksum value. Each message consists of a stream of name-value pairs of fields with fields separated by a field delimiter in the stream. All FIX messages are uniquely identified by a sequence number which are initialized at the start of the each FIX session and incremented throughout that session. Each session creates and maintains the sequence series separately independent of one another. With the advent of XML technology, traditional FIX messages described above can be represented in XML called FIXML. The same FIX session level protocol can be used to send FIXML as embedded payload. Currently, the FIXML message structure is defined by a DTDs. A B2B integration between trading partners exchanging FIX messages using J2EE technology is described in the following sections.

5) SWIFTNet (Society for Worldwide Interbank Financial Telecommunication Network)
SWIFTNet provides a wide range of end-to-end Straight Through Processing (STP) of financial messages. These services include trade service services, treasury and derivatives, securities, payments and cash management, custody services and reporting. SWIFTNet provides both B2B and web based messaging services such as FIN (FINancial application) based (using SWIFTNet FIN), structured XML exchange (using SWIFTNet InterAct), file exchange (using SWIFTNet FileAct) and web based messaging (using SWIFTNet Browse). The traditional SWIFT FIN messages are defined using Message Types (MTs), which is based on the evolution of MT syntax and created ISO 15022 complaint MTs. The data representation of field data in the FIN messages is in the plain text format. The MT does not provide structure, meta-data, multiplicity and sequence of the field data. This information called DFD (Data Field Dictionary) is provided in the form of a textual description (similar to a logical data dictionary) in the SWIFT User Handbook. With the advent of XML technology, a XML based standard equivalent to MT tags has been developed. To reduce the verbosity of XML message, this standard is a simplified XML Message (MXs) which is complaint with ISO 20022.

A SWIFT FIN message is represented by its unique identification number having the format of MTnxx, where n stands for the category of the message group and xx stands for individual message. For example, MT1xx represents message used for customer payments. The complete list the categories are shown below.

MT0xx System Messages MT5xx Securities Markets
MT1xx Customer Payments MT6xx Precious Metals and Syndications
MT2xx Financial Institution Transfers MT7xx Documentary Credits and Guarantees
MT3xx Money Market and Derivatives MT8xx Traveler’s Checks
MT4xx Collections and Cash letters MT9xx Cash Management and Customer Status

Table 1: SWIFT message categories.

The structure of FIN messages consists of 5 blocks of data. They are basic header block, application header block, user header block, body and trailer block. In the first two blocks, fields are fixed length, continuous and no field separators. The rest of the blocks may contain sub-blocks and fields delimited by field tags. The user header block is optional, mostly used to hold a reference number for acknowledgment and reconciliation. The body block contains the actual financial data in the form of MTnxx message as described previously. Business application retrieve this body block from the FIN message to process the business logic. The entire FIN message is embedded in a SWIFT message envelope. The SWIFT envelope contains address information which uses X.500 complaint Distinguished Naming (DN) system for representing the hierarchical tree structure, high level and granular entities (similar to LDAP). This enables SWIFT address to define PKI (Public Key Infrastructure) and message addressing and routing to accomplish end-to-end Straight Through Processing. The message structure of SWIFT and FIN message are shown in Figure 3.

Figure 3: SWIFT message structure.

SWIFT uses a secure private network backbone called Secure IP Network (SIPN) to enable the customers to access SWIFT services. SIPN is an IP based secure network connects to a VPN box at the customer side through network partners using Backbone access point (BAP). The SWIFT messages are tunneled through IPSec, which ensures network level security between BAP and VPN box. The session level and message level security of the SWIFT messages are provided by PKI embedded in SWIFTNet Link (SNL). The VPN boxes at the customer side are installed in an M-CPE (Managed Customer Premises Equipment) environment which is managed by SWIFT. A SWIFT Alliance Gateway (SAG) acts as a proxy in the customer DMZ, which intercepts inbound SWIFT messages and routes to application integration interfaces using Remote API Host Adapter (RAHA) for synchronous invocation, MQ Series Host Adapter (MQHA) for asynchronous invocation and File Transfer Agent for file transfer initiated by SWIFT FileAct services. For outbound messages, SAG concentrates the message flow from the application integration interfaces and routes to SWIFTNet through SNL.

As described earlier, SWIFTNet services in B2B integration space are SWIFTNet FIN, SWIFTNet InterAct and SWIFTNet FileAct. SWIFTNet provides a number of messaging patterns for exchanging messages among the trading partners. They are store and forward, Y-copy, T-copy, V-copy, request-response and push-pull model. For more information about these messaging patterns, refer chapter 8 on Messaging Patterns. SWIFTNet FIN enables exchange of traditional FIN messages between customers and SWIFTNet using MT standard. SWIFTNet FIN may use store-and-forward, T-copy or Y-copy as the messaging pattern. SWIFTNet InterAct uses store-and-forward or request-response messaging patterns and MX standard as message exchange. SWIFTNet FileAct uses store-and-forward or push-pull model as the messaging pattern.

B2B integration architecture between trading partners exchanging SWIFT messages with a J2EE based enterprise is described in section Appendix B.9

5) FIX (Financial Information eXchange) Message FlowThe general information about FIX is described in section 3. This section describes the architecture of a FIX based B2B integration involving two trading partners, where one trading partner implement its infrastructure using J2EE and XML technology. Both trading partners have a FIX engine which manages session level and application level protocols. The inbound and outbound architecture is shown in figures 4 and 5 respectively.


Figure 4: FIX based B2B integration with J2EE – inbound FIX message.

Process Flow:
a) The trading partner creates a FIX message using a FIX engine (acts as client) and sends to the FIX engine (acts as server) of the enterprise over leased line, VPN or internet.
b) The request may be intercepted at the DMZ of the enterprise by a FIX proxy server which forwards the FIX message to FIX engine of the enterprise.
c) The server FIX engine establishes a connection with the client FIX engine, authenticates the client by the server engine and sends back the logon confirmation message. Once the client engine receives the confirmation message, it sends the FIX message to the server FIX engine. Since FIX session protocol is based on an optimistic model, no acknowledgment of individual message is sent to the client engine. In other words, normal delivery of message is always assumed.
d) The server side FIX engine retrieves the message and sends to the integration server. If the message is based on traditional FIX message, the FIX message processor maps the inbound FIX message to a canonical flat file schema (at design time). At run time, the inbound FIX message is mapped to the XML instance and sent to the down stream application. If the message is based on FIXML, the FIX message processor extracts the FIXML message from the inbound FIX message and maps to a canonical XML and sends the XML instance to the downstream applications.

Figure 5: FIX based B2B integration with J2EE – outbound FIX message.

e) Once the downstream application completes the business process, it creates a response XML message and maps to the FIX response message. Now the FIX engine of the enterprise acts as a client and sends the FIX response message to the FIX engine of the trading partner.

6) SWIFTNet (Society for Worldwide Interbank Financial Telecommunication Network)This section describes how an enterprise integrates with SWIFTNet and exchange messages. Although there are number of ways SWIFT messages can be delivered for SWIFTNet services, only once scenario describes in this section. The environment of the institution which sends and receives SWIFT messages is assumed to be built on J2EE platform. The J2EE application, using its business logic creates the SWIFT business data. The SWIFT/FIN message handler/processor and SWIFTAlliance Access tools transforms the business data to SWIFT message. The message flow of outbound and inbound SWIFT messages are shown in figures 6 and 7 respectively.


Figure 6: SWIFTNet based B2B integration with J2EE – inbound SWIFT message.

Process Flow:
a) The core J2EE application creates SWIFT business data and marshaled into an XML message and sends to the integration server.
b) The SWIFTAlliance Access or integration interface creates the SWIFTNet FIN protocol envelope message (for MT messages), SWIFTNet InterAct message (for MX messages) or SWIFTNet FileAct message (for file transfer) and sends to the SAG server via Remote Access Host Adapter (for synchronous invocation), MQseries Host Adapter (for asynchronous invocation) or File Transfer Agent ( for file transfer).
c) The SAG server forwards the message to SWIFTNet Link (SNL) which encapsulates the message payload with SWIFT message envelope sand sends it to the VPN box over a TCP/IP connection.
d) The VPN box sends the SWIFT message to the SIPN (Secure IP Network) through IPSec tunnels. These tunnels are established between the VPN box the enterprise and the Backbone Access Points of the SIPN in the SWIFTNet.
e) Based on the SWIFTNet services and the messaging pattern, SWIFTNet servers or the recipient institution process the message and create a positive acknowledgement (or negative acknowledgment) or a response message and sends back to the originating enterprise system as shown in figure 7.


Figure 7: SWIFTNet based B2B integration with J2EE – outbound SWIFT message.

7) Any message protocol over Any transport protocol
In B2B integration, potentially any combination of message standard or message protocol can be used over any transport protocol such as XML over SMTP, flat file over FTP, XML over HTTPS etc. However, each such combination has its own advantages and disadvantages and may be selected based on case-by-case basis. Selection criteria may be based on synchronous or asynchronous, request or response paradigm, push/pull or poll, structured or unstructured data format, compliance of industry standard, level of security and so on. Two of the commonly used and best suited for B2B integration Scenario are described below.

This is the most popular and efficient B2B integration paradigm with out any proprietary components. This solution provides a continuation of current ubiquitous, web based and request-response scenario where HTML pages are sent over HTTP(S). The only difference is that a visual friendly HTML is replaced with a structure friendly XML. A B2B solution can easily be implemented if a similar web application already existing.
Pros:
a) HTTP(S) and XML are open standards and widely used,
b) A wide range of languages and tools provide HTTP(S) client and server implementations,
c) Faster data transfer and minimum overheads
Cons:
a) XML being data and structure friendly than visual friendly, knowledge of XML or third party tools are required for coding.
b) XML being highly verbose, allows eavesdropping by hackers.


Fig 8: Messaging and Transport Protocol
Virtually every vertical industry comes up with a standard which is widely used within the industry. These standards usually provide a Logical Data Dictionary (LDD), a XML data model and a Schema or DTD structure. The LDD provides the complete list of attributes used in the industry and its semantics. XML data model describes the element content model providing parent child relationship. XML schema shows the complete graph of the tree structure. Some of the common standards used in financial industry are given below.

Vertical Industry :  XML Standard
Insurance             :  ACORD
Mortgage              : MISMO
Securities             : FIXML
Trading                 : MDDL
Reporting             : XBRL
Investment and financial research :  RIXML

Apart from the vertical industry semantics, most of these vertical standards provide their own horizontal technological standards such as XML Digital signature, XML encryption, Document embedding, SAML etc. For example Mortgage standard MISMO provide SMART standard for XML encryption and XML digital signature and eMortgage package for document embedding.



Fig 9: Enterprise Service Bus Implementation Using SOAP / HTTPS
__________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).

Implementing a BPM (Business Process Management) Architecture in Financial Industry

Roy Abraham

1. Introduction:
Business Process Management deals with defining, analyzing, managing and implementing the interaction among internal systems, people and external trading partners. BPM provides a holistic approach to Software development involving technology (objective) and human behavior (subjective). In traditional systems, Business Logic (objective part) and Business Rules (subjective part) in a Business Process are tightly coupled. Hence, any requirement change, in either one, results redesign or re-factoring (depends on the extent of the change) of business process. However, laws, rules and regulations of certain business processes change constantly. This necessitates the decoupling or loose coupling of Business Rules and Business Logic. Business Logic is hard coded (means, business logic change depends only on requirement change). On the other hand, transient changes in rules, laws and regulations are encapsulated in Business Rules. These Business Rules may or may not need human intervention. Business Logic is implemented in Application server (for example, an EJB or IoC container). Business Rules, which need human intervention is implemented in Workflow server. Business Rules, which do not need human intervention is implemented in Rules Engine.

2. Components of BPM:
The major components of BPM are described below.

a) Business Logic: Defines the objective behavior of permanent nature. In software terms, this attribute never changes unless and until requirement changes. This also implies that there is nothing absolutely permanent in software development. The core business model of the enterprise is captured in the business logic.
b) Business Rules: Defines the objective behavior of transient nature. However, this attribute changes within the confines of the requirements. This encapsulates the forces outside the enterprise which influence the core business model such as market forces and government policies. The daily or weekly promotion sale of the company or changing the sales tax structure due to government policies are few such examples.
c) Work flow: Defines the subjective behavior of transient nature. This is where the human aspect interacts with the core business model. For example, a customer agent partially forgives the overdue penalty of a customer and her supervisor completely forgives it due to good payment record of the customer.
d) Trading Partner Interaction(B2B integration): Defines the business relationship with other enterprises. In the current integrated business environment, business to business transaction is inevitable one way or the other.
e) Enterprise Application Integration(EAI): Defines the integration of various software and data assets within the enterprise. It can be legacy assets accrued over the years such as main frame or software written in C language.
f) Life cycle management: Almost every business model has to perform a sequence of tasks from inception to fulfillment, to complete the business process. It can be a claim processing, an order fulfillment of a shopping cart or a loan processing etc. BPM provides the state management of individual steps involved in the Business Process.

Figure 1: Components of BPM

g) Monitoring: The entire software development project is business requirement driven. The business requirement is stake holder driven. Hence, directly or indirectly the business manager is the ultimate stake holder of the software development. However, the business manager may not have the technical acumen to understand the complexities of the software process. She has to believe what she is told by the development team. This poses considerable challenge to the Business Manager on day to day operations of Business Process. The monitoring tools of BPM provide such a visibility to the business process. Monitoring may include but not limited to Business Activity Monitoring (BAM) of Key Performance Indicators(KPI), Six-Sigma, compliance monitoring (like SOX), process analytics etc.

3) Necessity of BPM:
A typical example is the life cycle of a non-performing mortgage loans (assets). Rules and laws continuously change as new legislation come into effect every year. However, it is extremely difficult to change or re-factor the existing applications which process the mortgage loans as per every change in the mortgage law. The best strategy is to separate business logic and business rules from the business process. The subjective and transient tax features are encapsulated in business rules. The objective and permanent mortgage logic is encapsulated in business logic. The Business logic may reside in various disparate systems which needs to be integrated (EAI) using EJB, JMS, JDBC etc. Whenever a mortgage law changes, the business manager create a business rule associated with the new mortgage law and stores it in a rules engine. When the system receives an asset in trouble, the application server applies business logic and rules engine applies business rules on troubled asset data. The asset is sent through a Workflow if it needs to go through human intervention such as evaluating Broker Price Opinion. In most of the cases external trading partners (B2B integration) are to be involved such as Appraisal companies. In many cases, data and software assets reside in legacy systems and other disparate systems which needs to be integrated. For example, ARM loans are processed in C based systems while 30 year loans are processed in COBOL systems. Above all, an oversight by the Business stake holder or upper management (using BAM) is essential for the proper management of the life cycle of the troubled asset. To integrate such a complex and disparate business process, a BPM system is absolutely necessary.

Figure 2: BPM Project life cycle in modified waterfall methodology

4) Architecture of BPM: A BPM system must be able to integrate with Application server environments, Workflow servers, Rules engines, B2B trading partners, Legacy systems and Enterprise application Integration systems. The BPM system must provide a design environment to capture and model the business process and create compile time stubs. The BPM application must have a process engine to monitor the run time processing and KPIs. A high level, logical, design time and run time architectural topologies are shown below.

Figure 3. BPM Logical Architecture

Figure 4. BPM Design Time Architecture

Figure 5. BPM Run Time Architecture

Figure 6. BPM Run Time Architecture in Amazon Cloud


4) Design and Building a BPM application: The following steps describe salient features of a BPM application from design to production release.

a) Capturing and Modeling Business Processes. The first step is to capture the logical business process with the help of a business stake holder (or business analyst). Coarse grained processes may be sub-processed to capture underlying fine grained processes. The business analyst may iterate through the processes to refine the business process model. Steps are used to capture the business process and transitions are used to direct the flow among the business process. Such a logical Business process model is shown below.

Figure 7. Logical Business Process Model

Figure 8: Logical Business Process Model using BPMN notation


Using a Modeler or Designer, create a physical business process model out of the logical one. Create stub to develop code to represent the inlaying process. Such a physical model is shown below.

Figure 9. Physical Business Process Model

b) Creating and mapping Logical Data Dictionary (LDD). The LDD is a master reference table containing each and every attribute used in the business process. The meta data pertaining to each attribute is described in the table such as data type, data size, default value, list of values if enumerated, definition of attribute, container hierarchy (xPath) and type of attribute. The relative location of the attribute depends on the structure of the format where the attribute is located as shown in the figure below.

Figure 10. Data transformation and mapping in data formats.

The naming convention and associated meta data information are captured under each domain specific formats. For example, three attributes - order number, social security number and credit card type as it passes through different domain formats are shown below.

Figure 11. Logical Data Dictionary

The LDD is used as a reference document by analysts, architects, designers, developers, managers and testers for their respective needs. If LDD becomes too big to manage, it can be split into domain specific categories. The initial investment in the form of effort and time to build a Logical Data Dictionary is considerable. However, it is worth every penny as it prevents potential problems during the subsequent application development.



c) Creating the Canonical data structure. A canonical document, usually in XML format has to be derived based on the attributes collected in LDD. Thus, the LDD contains every attribute and its structure based on xPath. Different types of strategies can be used to arrive at the canonical XML. The canonical XML can be a subset of industry standard (as MISMO in mortgage industry), a combination of MISMO and trading partner proprietary XML, derived from Business Objects or entirely a new XML structure as shown below.

Figure 12. Derivation of canonical data structure.



d) Identifying and creating Unique Id. Every instance in the Business Process is identified by a unique id, similar to RFID (Radio Frequency IDentification). This id enables to maintain the life cycle of the instance even if it leaves the business process engine. For mortgage assets, it can be MIN (Mortgage Identification Number) which is analogous to social security number in mortgage world.

Figure 13. Canonical document based on MISMO secondary data set (Loan Delivery)


e) Develop necessary code within the created stub. once physical BPM model is created, a stub code can be generated to hold the underlying business process. Generate and test the code within the stub.
f) Monitoring the Business Processes. Once deployed into production, each instance can be monitored using a monitor or BAM enabled portal interface as shown below.

Figure 14. Monitoring of an BPM instance at run time, waiting for first BPO to arrive.

Figure 15. Monitoring of a BPM instance at run time, waiting for Second BPO to arrive.

Figure 16. Monitoring of a BPM instance at run time - the completed life cycle of the foreclosed asset.


5) Big Data analysis in BPM:
As BPM process gather large amount of data, those data can be used for big data analysis. These data can reside in various sources in various format such as Object data in S3, NoSQL data in DynamoDB, Relational data in RDS,  Warehouse data in RedShift, Archived data in Glacier and Streamed data in Kinesis. These data can be used, for example Dodd-Frank Act stress tests. To test the financial variables against the time series (ARIMA - AutoRegressive Integrated Moving Average) model or against random walk (MCMC - Markov Chain Monte Carlo) using Python as shown below.

Figure 17. Big Data analysis using EMR (Elastic Map Reduce) Cluster.

• EC2 instances are created in a VPC(Virtual Private Cloud) in the respective Availability Zone.
• A master node and slaves nodes are created in each EC2 instance.
• Hadoop, Spark and Python code to run ARIMA mode is installed in the Master node. Hadoop and Spark are managed by YARN in the master node. Fail over is managed by AutoScaling group in the cluster.
• Input data is read from any of the data sources and processed by the Python code. The results are written to one of the data storage for further analysis.

5) Conclusion.

Most of the ills associated with the current application development is the inability of the business stake holder to have proper oversight. Most of the software development environment do not provide any such tools. The important benefits of BPM are

a) SAVING MONEY: By completely automating all the business processes, virtually eliminates the unnecessary overheads in the loan processing and saves millions over the years.
b) LESS HUMAN ERROR: By automation, business processes have less human intervention and thus human error is minimized.
c) INCREASED PRODUCTIVITY: Faster loan processing enables better throughput (loans processed per unit time).
d) SUPERIOR OVERSIGHT: Upper management or business stakeholder gets a birds eye view of the entire loan process. In other words, management knows what is exactly going on rather than being told.
e) MONITORING AND OPTIMIZATION: In-depth monitoring of data at every step of the business process.
f) SUPERIOR ERROR HANDLING: Easy resubmission of process at a failed step.
g) ROI: Investing in BPM implementation gives the best return in the long run.
h) USER FRIENDLY: These models are extremely user friendly and provide a visual representation of the business processes which can easily be understood even by non-technical or uninitiated.
i) Fast Development and Implementation: Very fast and easy development life cycle and process refinement.


__________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).