DETAILED DESIGN

Project Code: MIF

Project Name: MIF Project
Account: Pitney Bowes Inc
Vertical: TMTS
Location: Bangalore
Customer Name: Pitney Bowes
Technical Manager/ Email ID: SOPIHA/[email protected]
Project Manager / Email ID: Nagaraj Iyer/[email protected]
Quality Coordinator / Email ID:
Pitney Bowes Inc
Customer Contact Information: WHQ, Stamford
Connecticut
USA

Prepared by/Date Reviewed by/Date Approved by/Date

Lalmohan Mohanadoss/09/08/07
 Detailed Design DD MIF Enhancement_v1.0.doc

Revision History

Version Date of Description of Change Reason for Affected Approved By

(x.yy) Revision Change Sections
1.0 09/08/2007 Initial Draft

Affected Groups

List of Reference Documents

Table of Contents
 Detailed Design DD MIF Enhancement_v1.0.doc

1. INTRODUCTION.................................................................................................................................. 4
1.1. BACKGROUND.....................................................................................................................................................4
1.2. SCOPE AND OBJECTIVES.....................................................................................................................................4
2. DETAILED DESIGN............................................................................................................................. 5
2.1. MODULE NAME AND DESCRIPTION....................................................................................................................5
2.1.1. Design Alternatives.................................................................................................................... 5
2.1.2. Design Details........................................................................................................................... 7
2.1.3. External Interfaces................................................................................................................... 17
2.1.4. Assumptions............................................................................................................................ 18
3. CRITICAL FUNCTIONS AND FOCUS FOR TESTING.....................................................................18
4. LIMITATIONS.................................................................................................................................... 18
5. TRACEABILITY TO REQUIREMENTS............................................................................................. 18
6. Acronyms and Glossary..................................................................................................................... 18
 Detailed Design DD MIF Enhancement_v1.0.doc

1. Introduction

1.1. Background
MIF stands for Message IF. MIF is an interface which lies between the
MQ adapter and the applications. MIF has the capability to support the
environments like Win NT/2000, HP-UX, and AIX. MIF is capable of
supporting the languages like C++, Java, COM interfaces, Oracle PL/SQL.
MIF uses separate libraries / DLL’s to communicate with MQ directly.

MIF is designed to support the applications to send or receive the

messages that act as the communication media for the source and target
applications. A client wishing to request a service presents MIF with a
Service Name and the Payload information to be sent. The MIF uses the
Service Name to retrieve the corresponding Service Profile, which
specifies the immediate next target for the message and all configuration
information to get the message to that target.

A server is an application that accepts a single request message,

processes it, and returns a completion code, and optionally a reply
message. The Message IF includes a sample server shell called the IPA
Adapter. This sample component, which is included in both C++ and Java
flavors, uses the MIF to:

a. Listen for requests

b. Invoke a native object (COM or Java) passing the Payload
c. Accept the response code and optionally reply Payload from the
native object
d. Return the reply Payload to the client.

The IPA adapter design pattern, which then only requires the server
developer to write the “native object”, is generally well-suited to
services which will take advantage of message queuing in a
straightforward way. Because the MIF does not append any mandated header
or trailer to messages, it can be used by clients to request services
that are not MIF aware.

1.2. Scope and Objectives

Scope
 Requirements Analysis. This includes an evaluation of the existing
EPP features and impact analysis.
 Complete Design and Coding of the system.
 End to end Unit Testing and System testing.
 Integration testing with external systems.
 Support & fixes for acceptance testing.
Detailed Design DD MIF Enhancement_v1.0.doc

 Support for Production Launch.

Objectives
 The objective of this design document is to add a plugin framework
to the existing MIF.
 The plugin framework will be given the capability to load and
initialize the plugin’s dynamically during runtime.
 The MIF plugin system will read the available plugin’s from the
configuration XML file for each service that exists with a
particular MIF instance.
 In memory and disk based caching of the configuration file should
be included into the MIF system separate for every service.
 Detailed trace log functionality should be included as part of the
MIF system.
 XSL Transformation of the incoming XML messages on demand should
be provided.

2. Detailed Design

2.1. Module Name and Description

2.1.1. Design Alternatives

 IN MEMORY AND DISK BASED CACHING:

 In the existing MIF adapter an extensive string operation is done

in order to retrieve the configuration data from the configuration
file.

 The configuration file is a XML file and the adapter will be using
the flexibility of the XML parsers for retrieving the
configuration details for each service associated with a
particular instance of MIF.

 The MIF adapter caches the configuration details in a Map and

uses it rather than loading the file for the configuration details
of the services every time.
Detailed Design DD MIF Enhancement_v1.0.doc

 The dynamic refreshing of the profile also will be done, so that

the profile can be changed with out restarting the MIF system.
(Caching can be invocation based or time based).

 SAX Parser (xalan) will be used for the parsing XML configuration
files in java.

 IMPLEMENTATION OF DETAILED TRACE LOG:

 In the existing MIF interface there is option to log the Success

and Error messages.

 The logging functionality also has to be enhanced in MIF interface

to include trace log functionality.

 PLUGIN FRAMEWORK:

 The plugin framework will be incorporated into the MIF system.

 There are three service types that the MIF interface work with,

1) SEND (Specifies that the message is send to the Queue)

2) RECV (Specifies that the message is received from the
Queue)
3) RPRQ (Specifies that the request is send and reply is
received Online)

 Plugins are added to include some special functionality to MIF by

which the data that flows through the MIF can be transformed or
translated or enriched.

 There are four invocation flow scenarios where the plugin

functionalities are loaded and invoked for the data that comes to
the MIF. There can be more than one plugin utility for each of the
invocation flow scenarios and the plugin will be sequentially
invoked in the order it appears in the configuration file.

1) Before sending message to target queue (PreSend).

Data Flow,
- Data comes to MIF from the source application.
- Data which comes to MIF will be passed to each loaded plugin.
- Functionality of each plugin will be applied to the data.
- Resultant data will be passed back to the MIF system from
each loaded plugin.
- Data is send to the target queue.

2) After sending message to target queue (PostSend).

This invocation flow Scenario is still under investigation.

3) Before receiving message from source queue (PreRecieve).

This invocation flow Scenario is still under investigation.
Detailed Design DD MIF Enhancement_v1.0.doc

4) After receiving message from the queue (PostRecieve).

Data Flow,
- Data comes to MIF from the source queue.
- Data which comes to MIF will be passed to each loaded plugin.
- Functionality of each plugin will be applied to the data.
- Resultant data will be passed back to the MIF system from
each loaded plugin.
- Data is send to the target application.

 The plugin details will be added in the configuration (Service

Profile) XML file for each of the available services.

 Along with the other configuration details cached in the Map for
each service, the plugin details also will be cached for each
service.

 XSLT Transformation:

 XSLT transformation functionality has to be included in the MIF

system as a plugin.

 XSLT transformation can be added to the data that use a particular

service. When any of the application sends the message using that
service through MIF, the plugin frame work should invoke this
service and apply the XSLT transformation functionality.

Note: The message that is passing through the service which is

configured to perform a XSLT transformation should be a XML
message.

 The plugin functionality is applied to the data that passes a

particular service just like any other plugin. The configuration
file will have the plugin information’s, which will be invoked in
the same order specified in the configuration file.

2.1.2. Design Details

 IN MEMORY AND DISK BASED CACHING:

 The disk based in memory caching will be done for each service
depending on the <ReCache_Invocations> tag in configuration XML
file. This will be particular for a specific service associated
with a MIF instance.
Detailed Design DD MIF Enhancement_v1.0.doc

<ReCache_Invocations># of invocations</ReCache_Invocations>

 The caching will be invocation based. I.e. Number of invocation

after which the configuration detail for the service should be
recached.

 The caching invocations limit can be from “00000” to “99999”.

 If the invocation limit is “99999” then configuration details will

be cached for the first time message comes for a specific service
and it will not be cached for the further messages associated with
that specific service.

Note: If the invocation limit is “99999” the caching is done

only once and will not be done again. so if the configuration
details are changed after the MIF starts and the
configuration is read into the memory, there is no
possibility of changing the configuration file dynamically
during the runtime.

 If the invocation limit is “00000” then every time the message

comes for a specific service, the configuration details will be
cached.

 If the invocation limit is between “00000” and “99999” which

indicates the number of invocations after which the service
profile should be cached. The service profile will be cached after
that many invocations.

E.g. If the value for ReCache_Invocations tag is “00002”,

<ReCache_Invocations>00002</ReCache_Invocations>
then the service profile will be cached after every two
invocations.

 The caching utility will not be a separate thread and will be

included as a part of existing MIF services. Whenever the message
comes into the MIF for any service, MIF services will check for
recaching the service profile of that service for every invocation
based on the ReCache_invocation value.

 For backward compatibility, if ReCache_Invocations tag is not

present in the service profile file for any service then the
default invocation limit is taken as “99999” and the service
profile is cached only once for that specific service.
 Since this functionality is specific to every service, the
implementation will be in the java files which implements the
services.

PSUDO CODE (In Memory disk based caching):

1. while message comes into MIF.

Detailed Design DD MIF Enhancement_v1.0.doc

1.1. Object SERVICE = Obtain the service that should process that
message.

1.2. If first message for SERVICE

Then Configuration = Read the configuration file.

1.3. Pass the message and configuration to SERVICE.

/*
ReCache_Invocation tag may not present for all services. This is
considered as this is a new functionality and in the existing system
this tag is not present.
*/
1.4. ReCache_Invocation=configuration.READ(“ReCache_Invocation”).

1.5. If ReCache_Invocation equals null

/*
Since the ReCache_Invocation is not present for the configuration
file, the default(“99999” – never cache) is assigned.
*/
Then ReCache_Invocation = “99999”

/*
invocation_counter will be the tracker for the number of messages that
comes through a particular service.
*/
1.6. Get invocation_counter from the SERVICE.

1.7. If ReCache_Invocation not equals “99999”

If ReCache_Invocations less than or equals invocation_counter
Then configuration = RECACHE(configuration file)

1.8. Process the message reading the configurations.

1.9. Return to MessageIF.

1.10. Wait for the next message to process.

RED: New changes.

BLUE: Existing.
GREEN: Comments.

Set of files which will get modified are,

No. Implementation File Implementation Method

1 MessageIFMQ.java protected payload run(Payload)
2 MessageIFJNI.java protected payload run(Payload)
3 MessageIFHttp.java protected payload run(Payload)
4 MessageIFHttps.java protected payload run(Payload)
5 MessageIFPojo.java protected payload run(Payload)
6 MessageIFTCPIP.java protected payload run(Payload)
7 MessageIFSSL.java protected payload run(Payload)
Detailed Design DD MIF Enhancement_v1.0.doc

8 MessageIFSAP.java protected payload run(Payload)

9 MessageIFSMTP.java protected payload run(Payload)

 IMPLEMENTATION OF DETAILED TRACE:

 Trace log functionality will be enhanced in the MIF system. Apart

from the existing log functionality where there is no provision to
catagorize the log messages(like Start, END, Info, etc…), new such
traces will be added to the MIF system services. These are
presented in four levels,
 LOG LEVEL 1
 LOG LEVEL 2
 LOG LEVEL 3
 LOG LEVEL 4

 The trace log will now include the following scenarios which comes
in different combinations in the trace log,

1) Start – to track the details when the application starts.

2) End – to track the details when the application shuts down.
3) Success – This is already present and logs all success info.
4) Error – This already present and logs all Error info.
5) Warning – to track the undesirable behaviors happening.
6) Info – to track down the general information.

Shown is a matrix that shows the dependency of the log level with
the log scenarios,

Log level Start Info Warning Error Success End

1   
2    
3     
4      

The configuration file will include the following tag,

<LogLevel>#LOG_LEVEL</LogLevel>
 The Logger implementation will be given in the class MIFLogger.
This class takes the file to which the log trace should go from
the configuration file. A new file will be created on daily basis
with time stamp. The log file also can change as the configuration
changes and recached into the Map.

 The existing MIF will be modified to uses the interface exposed by

the MIFLogger for the logging purpose.

API exposed,
MIFLogger.log (String Message, String Log_Type, FileWriter _MQfr)

E.g. MIFLogger.log (“ABCD”, “SUCCESS”, _MQfr)

 Depending on the log level given in the configuration file the

messages for the category will be logged in the log file.
Detailed Design DD MIF Enhancement_v1.0.doc

 The application which uses the MIF can be multithreaded

environment, in which case the log entries for the services should
be synchronized and sequentially written into the log file.

 Since this functionality is specific to every service, the

implementation will be in the java files which implements the
services.

PSUDO CODE (Detailed Trace Log):

/*
Function which will be called by the classes when they need the trace
log. Filewriter will be specific for each and every service.
*/
Function log (Messge:String, Category:int, FileWriter filewriter)
{
/*
The log_level/category matrix is represented in a two dimensional
array.
*/
String LogEnabled[4][6] =
{
START, DISABLED, DISABLED, ERROR, DISABLED, END
START, DISABLED, DISABLED, ERROR, SUCCESS , END
START, DISABLED, WARN , ERROR, SUCCESS , END
START, INFO , WARN , ERROR, SUCCESS , END
}

/*
Read the LOG_LEVEL from the configuration cache.
*/
LOG_LEVEL = READ (“LOG_LEVEL”)

/*
If the category is not disabled in the matrix, then print the log
message to the log file.
*/
If LogEnabled[LOG_LEVEL][Category] not equals “DISABLED”
Then
filewriter.write(printTimeStamp()+Seperator+ LogEnabled[LOG_LEVEL]
[Category]+Seperator+Message)
}

NOTE: If there are lots of threads acting on the same services, synchronization has to
be done which will bring down the performance as a lot of I/O operations has to be
done. While one thread works on I/O other threads has to wait. It may not be a good
solution for the online communications.

Files which will get modified are,

No. Implementation File Implementation Method

1 MessageIFMQ.java All Methods
Detailed Design DD MIF Enhancement_v1.0.doc

2 MessageIFJNI.java All Methods

3 MessageIFHttp.java All Methods
4 MessageIFHttps.java All Methods
5 MessageIFPojo.java All Methods
6 MessageIFTCPIP.java All Methods
7 MessageIFSSL.java All Methods
8 MessageIFSAP.java All Methods
9 MessageIFSMTP.java All Methods

 PLUGIN FRAMEWORK:

 Plugin configuration is given to each of the services available in

the Java MIF system in an application.

 The configuration is read for each service when the data starts
flowing through the MIF for that service.

 For each of the services, when MIF reads the first message the
configuration is cached into a centralized Map with the service
name as its key.

 The configuration details for each service are also represented as

a Map containing name value pair.

 The plugin details are taken into the configuration detail Map
represented as string.

 When a particular service invocation happens, then the plugin

details are read from the configuration detail Map for that
service and the plugin utilities is loaded and initialized though
the plugin framework which is applied to the data which uses that
particular service.

Plugin Framework:

 MIF loads the plugin that are specified in the configuration

XML file through the plugin framework using the API’s exposed
by the plugin framework.

 The plugin handler will take the service name and message as
parameters. The handler will take the plugin details for that
particular service, loads and initialize the plugin utilities
present for that service.

 The initialized plugin utility objects will be cached and used

for the further invocations for a particular service.

 The plugin utility classes are loaded, initialized and the same
will be cached for a particular service whenever the first
message of that service flows through the MIF system and the
clone of that object is given to the plugin handler. For the
Detailed Design DD MIF Enhancement_v1.0.doc

further messages which use the same services, plugin object

will be cloned from the cached object available from the cache.

 The caching and cloning of the plugin utility objects are done
to lower the cost involved in initializing the objects.

 The plugin handler will now have the plugin details and pass
the message through all the plugin utilities and the resultant
message is passed to the MIF system.

E.g. suppose if there are four plugin utilities (plugin utility1,

plugin utility2, plugin utility3, plugin utility4) configured for
a particular service then the message will flow from the MIF into
each utility in the order plugin utility1, plugin utility2, plugin
utility3, plugin utility4. When the message is passed through all
the plugin utilities it is returned to the MIF.

Diagram below shows the data flow through the plugin utilities.

 The plugin framework will invoke the plugin object for the
service for invocation flow scenarios (PreSend, PreRecieve,
PostSend, PostRecieve) as per the configuration details for the
specific service.
Detailed Design DD MIF Enhancement_v1.0.doc

Plugin Utilities:

 Plugin utilities in java are coded as separate classes which

implements the MIFPluginInterface.
Detailed Design DD MIF Enhancement_v1.0.doc

 The abstract class AbstractMIFPluginUtil implements the

MIFPluginInterface and provides the partial implementation.

 The abstract class AbstractMIFPluginUtil implements the clone()

method. So the actual plugin utility classes will be extending
the AbstractMIFPluginUtil.

 The clone method will have the implementation for cloning the for
all plugin utility object. As mentioned above the cloning is done
to reduce the cost of initializing the plugin object for the
sequential incoming data.

Class diagram for the plugin utility objects,

Plugin Configuration:

The configuration file will be modified to have the plugin details.

The following entries will be included in the configuration XML
file.

!Plug-in functionality base (Root) node

<Plugin>
<Util1> !First library to load
<UtilName></UtilName> !Name of Class to load
<PreSend> !Contain list of methods to invoke before sending msg
<Method1></Method1> !1st method to invoke
<Method2></Method2> !2nd method to invoke
<Method3></Method3> !3rd method to invoke
…
<Methodn></Methodn> !nth method to invoke
</PreSend>
<PostRcv> !Contain list of methods to invoke after recving msg
<Method1></Method1> !1st method to invoke
Detailed Design DD MIF Enhancement_v1.0.doc

<Method2></Method2> !2nd method to invoke

<Method3></Method3> !3rd method to invoke
…
<Methodn></Methodn> !nth method to invoke
</PostRcv>
</Util1>
…
<Utiln>
…
</Utiln>
</plugin>

 XSLT Transformation:

 The XSLT transformation will be added the MIF system as a plugin.

 The functionality that has to be added as a plugin to the MIF

should implement the MIFPluginInterface.

 Abstract class AbstractMIFPluginUtil has provided a partial

implementation by providing the implementation of the clone
method.

 So the plugin utilities can extend the AbstractMIFPluginUtil and

give the implementation for the execute method which will be
called from the plugin framework.

Package com.mpb.mif.util.*;
……
Public class DefaultXSLTTransform extends
AbstractMIFPluginUtil
{
Public String execute (String data)
{
//implementation goes here
}
}
 Detailed Design DD MIF Enhancement_v1.0.doc

 Xalan utility will be used for the XSLT transformation.

 The Default XSLT plugin will be given with the MIF in msgif.jar.
If a customized XSLT transformation utility has to be build, above
mentioned procedure has to be followed and the class should be
placed in the predefined path in the server.

 For using the plugin utility, configuration file has to be

modified to include the utility into the MIF system for the
services.

For PreSend invocation flow scenario,

<Plugin>
<Util>
!Name of Class to load
<UtilName>com.pb.msgif.util.DefaultXSLTTransformUtil</UtilName>
<PreSend> !Contain list of methods to invoke before sending msg
<Method>execute</Method> ! method to invoke
</PreSend>
</Util>
<Util>
!Name of Class to load
<UtilName>com.pb.msgif.util.DefaultXSLTTransformUtil</UtilName>
<PostRcv> !Contain list of methods to invoke after recving msg
<Method> execute</Method>! method to invoke
</PostRcv>
</Util>
</plugin>

2.1.3. External Interfaces

Java MIF has external interfaces with SAP (JCO), C++ through native
interface, etc.

2.1.4. Assumptions

3. Critical Functions and Focus for Testing

 MIF should be tested for backward compatibility.
 Plugin framework should be tested thoroughly.
 Encryption and decryption of messages should be tested thoroughly.
 Compression and decompression should be tested.
 XSLT transformation should be tested.
 XML validation using DTD or schema should be tested
 Removal of RFH header should be tested.

4. Limitations
 Data will not be in human readable format in target service
component (MQ-Series and HTTP Web server) after data encryption
and compression. It will create additional maintenance overhead
for administrator.
 Detailed Design DD MIF Enhancement_v1.0.doc

 Third party libraries used for XSLT, Encrypt/Decrypt and

Compress/Decompress will result in degrade of performance due to
loading/unloading of these libraries.

5. Traceability to Requirements
Document reference Id & Description: (Doc Id from which this document is derived)

Sl No. Reference document Design document

Requirement/Feature (Section ID/Name) (Section ID/Name)
1. Plug-in framework 3.1.2
2. Inmemory and disk based caching 3.1.2
3. Implementation of detaild trace 3.1.2
4. XSLT Transformation 3.1.2

6. Acronyms and Glossary

MIF - MessageIF