Where to put 900 parameters(variables)?

[ruijin yang]

Hello,
We are developing a financial product system based on parameters setting.There are
about 900 common variables in this system.We use WebSphere Application Server Enterprise V5 and DB2 7.2.
PTM(stateful session bean)-->Catalog,Fulluse, TCP,DEX,REL,SEL,CUP(These are help calsses)--> Entity Bean.
Now,PTM and these help classes need to access 900 common variables(get or set their values).
Note:"-->" stand for "call".
My problem is:Where to put 900 parameters(variables)?
My boss told us that He used COBOL to develop this system at previous time and he created a block of memory for each logined user to put 900 parameters(variables) and used paging technique.
But in Java,we can not directly manage memory and use paging technique.
Any idea is very appreciated.
Regards.
ruijin yang

[Kunal Aher]

Hi,
Just need to know , if u require a common pool of variables that are referred by all or a data structure soring the 900 variables for each logged user ?
In the former case , a singleton class can serve the purpose and in the latter , there is not much choice.
900 variables really is a big number !
But again there are chances that u can categorise those variables and have different classes for them.This can help u organise more just in case there is a possibility that U instantiate only a set of those variables based on the user role / business logic .
I work with ATG dynamo , and here we have the components ( basically a Java Bean ) where we store the values . The server then stores these variables to a Properties file.
This soln is applicable just if in case the values are required to be initialised with constants that can be stored in the Prop files and set during the initialising of the component.

I know the above solns are not definitive but we can discuss it out.
All the best .

[Kyle Brown]

Do an OO design. You NEVER have 900 bare variables -- you always have some number of objects -- what I'm saying is that ONE of you needs to learn OO design and J2EE design FAST and apply it! Good grief, this isn't a design, it's a monstrosity. Seven objects and 900 variables? That's insane!
READ several books on OO design. READ the Domain Language Patterns pages. HIRE a consultant who actually knows what they are doing and has done OO design before because otherwise this sucker will fail miserably!
Kyle

[ruijin yang]

Hi,Kunal:
The case is the latter.Only a little part of 900 variable is constant,for example,they are Date,Bank Location,Bank Unit,Currency Type,etc.
In fact,we need a data structure to store 900 variable for each user and every object(PTM,Catalog,Fulluse,SEL,DEX,REL,CUP,DEX,PGM,MAP,etc) is convenitent to access to them.These objects do business processing(need to access database and 900 variables).
We now have following considerations:
First of all,we can not put 900 variables inside PTM(stateful session bean) because help classes(Catalog,Fulluse,SEL,DEX,REL,CUP,DEX,PGM,MAP,etc) need to access to them;
Secondly, if we put 900 variables in database(as an Entity Bean),the performance is very low;
Third,we declare 900 variables within a java class.When a user logged in,we create an object and put this object into a hashtable.The user name can be hashtable's key.This hashtable can be declare as static inside another java class.In this circumstance,every object can access to 900 variables.But when user become more and more,this hashtable become bigger and bigger.
In addtion to,why so many variables(900)?Because our system is a financial product,it is parameter-driven system,user can do parameter setting according to their needs.
Welcome more help.
ruijin yang

[Kyle Brown]

I don't care that it's a financial product system. I've done dozens of highly complex systems in the financial arena (including derivative trading, banking, insurance policy adjustment and other areas) and they ALL have been implemented using standard OO design techniques that split up variables among objects. You're not doing that. Start there and then come back to us...we can't fix a bad design with a J2EE pattern, and this is a bad design.
Kyle

[Simon Brown]

And I thought that this was supposed to be a friendly place for greenhorns... :roll:

[Kyle Brown]

Sorry, but sometimes we have to be firm. Some things can't be helped by short term fixes -- you have to get to the root cause, and the root cause of this is a bad design.
Kyle

[ruijin yang]

Hello,Kyle:
Thanks for your posting.
This system was developed in COBOL at previous time.Now,we are writing this system in Java(J2EE).We have not redesigned this system.
ruijin yang

[Chris Mathews]

Originally posted by ruijin yang:
Hello,Kyle:
Thanks for your posting.
This system was developed in COBOL at previous time.Now,we are writing this system in Java(J2EE).We have not redesigned this system.
ruijin yang

You have not redesigned it yet? Or you are not going to redesign it?
If you are not going to redesign the application, then why are you even going to rewrite it? By merely copying the old application design, glaring faults and all, you are just commiting the sins of the past and not gaining a single iota of benefit in the process.
If you do not redesign the application, I will guarantee that you will have the same problems in the "cutting edge" Java version as you had in the "old school" COBOL version, maybe more, and your project will be seen as a failure.
If the application is important enough to your organization that they are willing to pay to rewrite a current working version, then it had better be important enough to you to do it right.
[ March 03, 2003: Message edited by: Chris Mathews ]

[ruijin yang]

It is a good product system in COBOL.Please no more comment on this previous system.
Now,we are just interested in building a new good system in Java(J2EE).If it is necessary to redesign this system,we will go this way.
ruijin yang

[Kyle Brown]

Ruijin,
It is necessary that you redesign the system to make it a good J2EE system. COBOL designs are NOT appropriate for Java. You cannot apply any of the design principles from the COBOL system to your new J2EE system. You need to start from scratch with a functional description (requirements) and totally redesign the system from the ground up.
I'm dead serious. HIRE someone (as a full timer or a consultant) who has done lots of J2EE designs (and who hopefully has years of Object-oriented design experience) to help you with this. I strongly sense that your team does not have this depth of experience from your question. Your team is making assumptions about the design of the new system that WILL NOT work in Java and J2EE. If you do not completely redesign the system it will fail, plain and simple.
I've been doing OO design for 14 years. I've been doing Java for seven. I've written three books on the subject. Please trust me on this. Your approach will not fly. You have to start from the bottom on this one.
Kyle
[ March 04, 2003: Message edited by: Kyle Brown ]

[JeanLouis Marechaux]

Just my 2 cents to tell I'm with Kyle on that.
The way you consider your "900 parameters" sounds like global variables.
Global variables are not supposed to be used anymore in OO design. This is not even a J2EE constaint. An OO client/Server application should not use them either.
If you just plan to rewrite the Cobol application "as is"... please think about it twice 'cause it will fail. No doubt the Cobol application is a good one. But lot of customers I know missed their Java/J2EE switch because they wanted to keep exactly the same sytem. This is simply not possible with a 3-tiers application.

Btw, Kyle is a kind of reference in the J2EE world. So please trust him. If you don't, then trust Chris. And if you don't, then trust me. We are only tring to help you.

[Kunal Aher]

Thanks Kyle for the suggestions, It made me realise that I must start thinking from ' out of the box ' and just not to go along with the obvious.
Anyways I am really curious , of how someone should go about writing new J2EE systems based on legacy ones. Especially in the case where there is a one to one mapping of functionality required in the new system,the natural tendency would be to simply do a line to line conversion of code :-( .
Your experience would help to throw some light on this.

Regards
[ March 04, 2003: Message edited by: Kunal Aher ]

[Kyle Brown]

Well, there are a couple of approaches we can take:
(1) Consider the existing program to be an "executable specification" and then develop Use cases from the existing user interactions with the system. Then proceed into standard OO design and NEVER look at the source code of the original system.
(2) Consider writing a new J2EE system on top of portions of the existing legacy system. Standards like the Java 2 Connector Archicture allow us to connect to COBOL applications from within J2EE. So, you may be able to keep some or all of your business logic in COBOL while putting an entirely new Java front-end on the system.
Kyle

[ruijin yang]

Hello,
I am one of our team members for this project and I am not the decision maker.I have mailed the url of this topic to my boss.I think we can get benefits from these helpful suggestions.
I think Kyle's statement("split up variables among objects") is a good idea.I have read several of Kyle's articles.I feel I can trust on Kyle.
ruijin yang

[Chris Mathews]

Originally posted by ruijin yang:
I think Kyle's statement("split up variables among objects") is a good idea.I have read several of Kyle's articles.I feel I can trust on Kyle.

Just to be completely redundant, this is not just Kyle's wacky advice. It is the advice of the entire OO Community, based on years and years of experience. It is the very foundation for OOP.

[Kunal Aher]

Hi ,
Those are real good suggestions . It really makes good sense to have a new interface built around an existing time tested system , that might have evolved and perfected over the years. No doubt IT managers would love that idea .

And Ruijin , you have already shown the initiative. I am sure your manager will appreciate that. And I think that Kyle didnt mean creating separate classes to split up the variables. The classes will evolve naturally as result of the OO Design. So dont take that statement literally ( Correct me if I am wrong Kyle )
All the best .
Good , now I need to go back to my books for some real serious reading on OOAD.
Kyle , I must thank you for the EJB Workbook . Without it I would have never learnt deploying EJB's on WS .
Keep it up .

Cheers
Kunal
[ March 04, 2003: Message edited by: Kunal Aher ]

[Mark Herschberg]

Originally posted by Kunal Aher:
Hi ,
Those are real good suggestions . It really makes good sense to have a new interface built around an existing time tested system , that might have evolved and perfected over the years. No doubt IT managers would love that idea .

My guess is that if it was built using COBOL and memory paging, it's not as powerful or flexibile as new technologies would allow it to be. Time tested is fine for some things, but you won't see me riding around in a ox-cart.
--Mark