Technology change. Which one?
Hello,
I work for a bank as a java programmer. We have products like loans and systems that help the office clerks to sell that loans. Now we use self made RMI client-"server" architecture. The client is a Swing GUI connecting to the RMI server object. We are planning to have more kind of clients for example WEB browser based client as well (actually we have one web based application which connects to our server via RMI). (our applications are using JDK 1.3) We are gonna refactor the database structure as well.
We are in front of a big refactoring and maybe we will rewrite the whole system. Because of that we are considering other technologies. As far as we have 3 options.
1. stay with the POJOs and simple RMI client server architecture, just refactor that. I suppose even if we chose this we would use something for persistance ( for example hibernate ) and of course we can do transaction handling as well.
2. use JEE5, EJB and stuff like that
In that case there is a huge technology risk because the JEE5 is brand new so there is not so much experience with that it may contain a lots of bugs and I'm not sure the market is ready for that technology ( I mean for example there are not enough app servers... ). And if we chose that our programmers should be trained to use JEE.
3 use JINI
One of us proposed using JINI, but I'm not sure if this would help as at all. I can not see the future of JINI (for example I can not find a JINI topic here among the topics) and I don't think it created to use that in a banking environment where transaction handling, persistance are important. I can not see how it would serve us.
4. other
What is your opinion, which option we should choose?
[1759 byte] By [
Miklewa] at [2007-10-2 22:33:26]
> 2. use JEE5, EJB and stuff like that
> In that case there is a huge technology risk because
> the JEE5 is brand new so there is not so much
> experience with that it may contain a lots of bugs
> and I'm not sure the market is ready for that
> technology ( I mean for example there are not enough
> app servers... ). And if we chose that our
> programmers should be trained to use JEE.
You said a part of the answer for this option...
I'm not project manager, but as far as I know in my engineering field of study, risks should always be minimized as much as possible... Thinking about a technological issue is always an "hot subject"...
Anyway, was only my (little) point of view
> I work for a bank as a java programmer. We have
> products like loans and systems that help the office
> clerks to sell that loans. Now we use self made RMI
> client-"server" architecture. The client is a Swing
> GUI connecting to the RMI server object. We are
> planning to have more kind of clients for example WEB
> browser based client as well (actually we have one
> web based application which connects to our server
> via RMI). (our applications are using JDK 1.3) We are
> gonna refactor the database structure as well.
Wow. Big job. Need some help? 8)
> We are in front of a big refactoring and maybe we
> will rewrite the whole system. Because of that we are
> considering other technologies. As far as we have 3
> options.
>
> 1. stay with the POJOs and simple RMI client server
> architecture, just refactor that. I suppose even if
> we chose this we would use something for persistance
> ( for example hibernate ) and of course we can do
> transaction handling as well.
I agree that POJOs might be a good way to go, but I'd use them with a Java EE app server and Spring. I'd imagine that you'd have some requirements around clustering and scalability that an app server is written for. Spring can help you with the view layer, the persistence, remoting, 2 phase commit and transactions, etc.
> 2. use JEE5, EJB and stuff like that
> In that case there is a huge technology risk because
> the JEE5 is brand new so there is not so much
> experience with that it may contain a lots of bugs
> and I'm not sure the market is ready for that
> technology ( I mean for example there are not enough
> app servers... ). And if we chose that our
> programmers should be trained to use JEE.
Training would be a big issue here. You can do Java EE without EJBs, of course. I'd recommend Spring highly.
> 3 use JINI
> One of us proposed using JINI, but I'm not sure if
> this would help as at all. I can not see the future
> of JINI (for example I can not find a JINI topic here
> among the topics) and I don't think it created to use
> that in a banking environment where transaction
> handling, persistance are important. I can not see
> how it would serve us.
Wow. I haven't heard much about Jini in a long time. A beautiful technology, a beautiful thought, but I don't think it's gotten much traction in the market place. I think you'd be better off sticking with Java EE. It's a more conservative bet.
> 4. other
Service oriented architecture is the trend du jour. You should be looking into that. It'll fit into Spring and Java EE.
> What is your opinion, which option we should choose?
One thing that Spring has is a Swing UI module. I believe it will allow both a Swing UI and a browser talk to the same services. Worth a look.
http://www.springframework org
%
I recommand using J2EE 1.4 and Struts. I worked with struts and i can say that it is very powerful framework.We made a web application that uses oracle database and is accessed by thousands of users online and it works very well.
Yeah, using Struts/Hibernate/J2EE 1.5/mysql/Xdoclet....at job and....wow ! All of these frameworks together are very powerful tools.A bit hard to configure it all at the begining I found, but wayyyy powerful and worth it after !
about struts: actually the web client which connects to our RMI "server" uses Struts and Tomcat.
But now the most important part of the system is the Swing clients connected to our server using RMI protocol. I don't know yet if that clients stays Swing based clients but probably yes.
This server and the client need to be changed as well because of the rigidity, fragility, immobility and viscosity ( See http://www.objectmentor.com/publications/Principles%20and%20Patterns.PDF )
The new technologies ( JEE, Spring, Hibernate ) are very promising, I know, but because of the lack of knowledge they are risky as well.
Yeah... get to your books then :-?br>Actually, they are not very hard to use. To me, the biggest part was the configuration and settings to set correctly...
struts will constrain you to web ui only. how does it help with swing ui?
i'd prefer spring because it can help with the web ui, including playing with struts, but it adds a lot more help with things like persistence, remoting, etc.
a risk to learn, but worth the effort. it's risky to be too conservative, too
%
The main problem is we have to make the managers accept the risk. So they have to so what they got in return.
> The main problem is we have to make the managers
> accept the risk. So they have to so what they got in
> return.
Right. Here's what I'd tell them:
(1) Open source framework that's getting terrific traction. A good foundation on which to build for the future.
(2) Well-designed, well-tested framework that saves you from having to write plumbing code.
(3) Can deploy enterprise apps without EJBs; can deploy on servlet/JSP engines like Tomcat, Resin, etc.
(4) Framework promotes Java best practices (e.g., use of interfaces, well-layered code) that will make modifications and extensions more feasible in the future.
%
> The main problem is we have to make the managers
> accept the risk. So they have to so what they got in
> return.
Do you have an enterprise architecture document(s). Or an architect who is currently tasked with creating that?
Do you have process control in place which includes architectures and designs and the formal reviews for all?
I ask because it appears that the refactor is not management driven.
And this is a long term project.
Embarking on an enterprise refactor on a whim or just for fun only leads to more disparate infrastructure for the next guy to maintain. And if that is the situation then refraining from big scope designs just to solve very small problems. Especially with new technologies it is likely to lead to a system that is hard to maintain and is poorly designed. And in that situation smaller projects, to gain experience if nothing else, are better.
This kind of situation I face very frequently in my project. This was built in 1999 (some kinda ice age system - legacy J2ee!) and maintenance/upgradation has become a real nightmare. Any change request involves a huge amount risk from management perspective. So, I'll discuss how I handle that.
Its all about showing the greener bank and keeping the risk within the achievable mitigation point. I write documents that detail out the functional and non functional benefits the new system will bring in, including how new development and long term maintenance will be affected. There should be tangible benefits the new system brings in your team. I have seen managers hardly care if you use spring or winter. What they care is about managing existing manpower, development life cycle, cost of delivery and last not the least is the gross margin of operation. Once the expectations are set, I'll write the risk management in a tabular format, indicating probability, impact possibility, rationale, mitigation plan and the contingency plan. I have seen this is what middle management bosses want (I guess they present to their superiors this section only). I strongly suggest creation of a Proof-of-Concept to illustrate what you want to do. For many seeing is believing! Once the POC is done you can put up a final findings document, updating the risk section to give better clarity to your superiors.
For me this has worked over the years. You may give it a try if you think it is worth.
jschell, even if the changes are not for "fun", I think you are right.
We really have no experience in JEE, Spring, JINI either. We just used POJOs and cowboy programming so far (no architect). So if we changed technology we really need a small project to try that before using it in the production system.
The need for refactor was initiated by us, the programmers and we try to make the managers accept that. It seems they accept this need so far.
