N-Tier Session Management Question...

Murray Gordon — Thu, 29 Sep 2005 11:55:00 GMT

I have a question for anyone who might be able to help.

I am building a SmartClient app that uses .NET Remoting to communicate with it’s BLL (Business Logic Layer). The app ultimately speaks to an IBM 3270 Host to execute units of work. The BLL and DAL (Data Access Layer) are for the most part, pass through layers to the real business logic on the mainframe. As the app evolves, functionality in the host might be moved onto other systems.

My question is… I have to maintain state or a session between all the layers of the application.

· Do I need to create a “Session” class to maintain this state in each layer of the application?

· How would I sync state across all layers?

Here’s the conceptual design diagram. Notice I have “Session” object on all three layers. Am I off on this approach?

Here’s my session class. It has a bunch of properties that about the user and their session that need to be passed around. This is what I’m trying to pass around to be used on the UI, BLL and DAL.

Thanks in advance for anything.

How to modernize mainframe 3270 applications? Without throwing away your investment...

Murray Gordon — Tue, 14 Jun 2005 15:26:00 GMT

How to modernize mainframe 3270 applications?

Without throwing away your investments...

I have recently been faced with an Integration and Deployment dilemma with one of our customers. The customer is a multi-billion dollar national distribution organization, with facilities around the country. They are currently running our Control I Order Management System on IBM 3270 mainframe.

They were initially interested in implementing our Control II version of the software that leverages a relational database and a completely re-architected code-base. It's a client/server solution that runs some of the largest distribution facilities in the world. But it's not a SOA-based solution, which is the direction that the client is looking to go for modernization. Fortunately our Control.NET application is a SOA-based solution. We are currently migrating our Control II order management system to run on the .NET CLR (Control.NET).

The new Control.NET application leverages all the great features of the Microsoft server and .NET related technology offerings:

The relational database is SQL Server 2005.
The development environment is Visual Studio 2005 Team System, though we are still using MKS Source Integrity to manage our code, until we adequately test Team Systems code management features.
13 million lines of ANSI COBOL, recompiled to run on the .NET CLR using Fujitsu's COBOL.NET compiler.
BizTalk 2004 as the Business Process Management System (BPMS) for communication and message coordination between systems.
SharePoint Portal Server 2003 for personalize and targeted information worker content and dashboarding.
SQL Reporting Services 2005 for business intelligence and reporting.
ClickOnce deployment for web-enabled thin-client deployment that allows rich user interface functionality.

I am trying to find a solution that would allow the customer to use our new Control.NET order management system, but still be able to leverage the existing data on the mainframe without being forced to do a complete systems switch-over. They would like to migrate and modernize their system over time.

This approach requires our system, Control.NET, to be able to access data (i.e. Inventory, Customer or Vendor data) not from our relational database, but rather from the existing IBM 3270 mainframe data that exists in IMS and VSAM data files. Unfortunately this presents a dilemma. IMS and VSAM data files are not relational databases, but rather IMS data is a hierarchical database and VSAM data is just indexed files.

Our Options…

We have a few options for how we might solve the problem:

Option 1 – Synchronize Databases. This option would require synchronization between the relational database we use for Control.NET and the VSAM / IMS data used in Control I. There are a few options we could go with here.

There are six approaches that you could pursue. As background and for IBM's recommendations, take a look at chapter 8 of the IBM Redbook titled, Cross-Platform DB2 Stored Procedures Building and Debugging, posted to http://www.redbooks.ibm.com/abstracts/sg245485.html. This IBM Redbook compares most of the approaches that are available to you:

1. Employ IBM DataPropogator to synchronize IMS DB records with SQL Server records.

2. Connect the IMS region to a DB2 instance using the IMS attachment facility, then use DTS to poll DB2 to capture changes. If you need to push changes to IMS, then see the next approach.

3. Update DB2 using SQL Server Replication or DTS, then pass the changes to DB2 to IMS DB using the standard DB2 stored procedures (see Redbook).

4. Call IMS program (using Transaction Integrator) that would read/write to IBM DB records on behalf of Microsoft SQL Server (albeit in a non-SQL way--you'd have create your own SQL consumer application to map from SQL Server Replication INSERT, UPDATE, DELETE statements to record access commands via TI). Also, you can use this same approach to call CICS program (using Transaction Integrator) that would read/write to IBM DB records on behalf of Microsoft SQL Server (albeit in a non-SQL way).

5. Create a new IMS program that calls SQL Server via the HIS 2004 Transaction Integrator for Host-Initiated Processing.

IBM solves this problem with a commercial software application. Microsoft offers enabling technology only. You need to determine which platform is in the control position: SQL Server or IMS DB.

Option 2 – Direct ODBC Calls using 3rd Party App. This option would allow us to make calls to our DAO (data access objects), which would then make ODBC calls into a 3rd party application sitting on the Mainframe. The 3rd party application would be running in its own region on the mainframe waiting for ODBC commands from our application. When it receives a command, it would execute that ODBC call against the IMS database or VSAM files, depending on where the data is located. In essence our application would think it’s calling a relational database, when in reality it’s executing changes against VSAM data files or IMS hierarchical data. We would have a possible issue with two phased commits.

Option 3 – Direct DAO to DAO Calls through BPMS. This option would allow us to make calls to our DAO (data access objects), which would then write the commands to MQ messages. The MQ messages would be sent to a BPMS (BizTalk or WebSphereMQ or Fuego -whatever the client wants). The BPMS executes the DAO’s on the mainframe side and sends a transaction complete response to our application. In this case the BPMS would handle our two phased commit issues.

Personally I like Option 3. The 3rd party solutions tack on a minimum of an extra $150K in software licensing. Needless to say I would love to find a solution that doesn’t require that kind of added expense for software.

Visual Dev - Host Integration

N-Tier Session Management Question...

How to modernize mainframe 3270 applications? Without throwing away your investment...