The Old Joel on Software Forum: Part 4 (of 5)

Delphi + CORBA vs. J2EE

I'am working in a small company (5 developers). We are developing accounting software for middle size companies. Before 3 years company decided to develop home-grown app server using Delphi and CORBA (and also Kylix for Linux).

I have worked only 1.5 years in this company and i cant ee future for such solution. I think J2EE is the way to go.

So, what are main arguments against Delphi + CORBA, or maybe this is good solution?

IJ
Saturday, May 8, 2004

WHat about .NET? A decision like that cant be made without looking in a lot more detail of the requirements than what you have given us. Software developers are notoriously religious and will recommend their favorite tools, either Corba, COM+, .NET, J2EE or whatever. Good developers pick the best tool for the job and have the skills to adapt to it rather than trying to adapt the project to the tool as is often done.

Craig
Saturday, May 8, 2004

J2EE. Most of the work has been cut to you.

Ribeiro
Saturday, May 8, 2004

I used CORBA several years ago. It seems that it has been on the way out for awhile. It also seemed byzantine (overly complex.)

Bored Bystander
Saturday, May 8, 2004

Interview some prospective users. Ask them this question:

Which do you prefer as a user interface?
a) Excel
b) A custom app designed to suit my job

Of course, answer (b) could be phrased in a more user-friendly way, but you get the point. Maybe even present them with a screenshot of your proposed app.

I don't know your target market, so I can't guess what the answer will be, but be prepared that more advanced accountants often prefer the flexibility of Excel as a front end. In addition, using Excel as a front end can save you reinventing the wheel.

I'm also somewhat unnerved that you specified J2EE when the market is small businesses - doesn't J2EE require an application server? Or is it really a synonym for "Java" (i.e. in a desktop environment)

I'll echo previous posters in that you need to evaluate *why* you think J2EE will serve the project better (development cost, deployment cost, maintenance cost). Identify the differentiators and determine why they apply in this particular case.

Finally, I've recently had an opportunity to use some modern Java apps, and they *still* feel "squidgy" to me - not crisp like Delphi, Python, or .Net apps. Since this makes it a case where the chosen development platform can affect the user experience, again I'd have to recommend doing a lot of user testing on demo apps to see which they prefer.

YMMV,
Philo

Philo
Saturday, May 8, 2004

I'm not a Java developer, but I noticed a recent comment on these forums from someone who is. The comment was a complaint about the complexity of J2EE and it went something like this:

"...a nightmare of libraries on top of libraries on top of libraries. I curse the people who decided that JSP was too messy so we needed Struts, but that was too messy so we need to use JavaServer Faces too."

So, if you do go with Java, watch out for the complexity of J2EE.

One other thing: you might like to consider sticking with Delphi. Sometime, maybe quite soon or maybe in a few years time, you can migrate it to .NET using Delphi for .NET. That lets you keep your existing code AND move to a modern platform.

See http://www.lemanix.com/lemanix/lemanixisapi.dll/Entry?ID=1167

John Rusk
Saturday, May 8, 2004

If you do stick with Delphi, you might want to check out the option of converting your current appserver from using CORBA over to using something like the RemObjects remoting library (perhaps also with their DataAbstract addon): http://www.remobjects.com . RemObjects can be used to make services that are accessible via SOAP to any client, while at the same time offering a more efficient binary transfer protocol to clients that can use it. Not sure, but I think they've already included ability to use the more efficient protocol with clients written in any .NET language.

Another Delphi remoting library that has some .NET interoperability is kbmMW: http://www.components4developers.com

Herbert Sitz
Saturday, May 8, 2004

> JSP was too messy so we needed Struts

Speaking of libraries, why did we need jsp?
Why do we need silly containers like spring
to do simple and obvious things? If it weren't
for the need to have a web server for servlets
we wouldn't fricken app servers either.

son of parnas
Sunday, May 9, 2004

Avoid J2EE complexity: http://www.springframework.org/
Avoid .NET complexity too: http://www.springframework.net/

Walter Rumsby
Sunday, May 9, 2004

Why JSP - because it's a lot easier to work with a template than to create the output in servlets. There are alternative templating solutions, e.g. Velocity, that provide a more "pure" separation of presentation and processing too?

Why Spring - because J2EE applications can have oodles of nasty singleton objects, e.g. to represent your persistent layer; Spring applications should only ever have ONE singleton (the BeanFactory) and you can actually write nice classes that may or may not have "only one instance ever" in your application. The more you work with Spring the more you realise what a good idea it is.

If you're doing something simple, then no you don't need all these options - but that is Java's strength and weakness: a huge number of options.

Walter Rumsby
Sunday, May 9, 2004

Original post:

"I'am working in a small company (5 developers). We are developing accounting software for middle size companies. Before 3 years company decided to develop home-grown app server using Delphi and CORBA (and also Kylix for Linux).

"I have worked only 1.5 years in this company and i cant ee future for such solution. I think J2EE is the way to go.

"So, what are main arguments against Delphi + CORBA, or maybe this is good solution?"

Salient points:

* This company develops accounting software
* This company is developing its own app-server

If the company develops accounting software it should be focusing on developing accounting software and not on implementing an app server.

Why are they developing an app server? I dunno, perhaps because there is nothing in the Delphi world that does what they need (for the right price).

Developing an app server is a rather big distraction for a small team of developers who are supposed to be developing accounting software.

So yeah, Java, lots of app servers. Potentially these guys can (re-)focus on writing their accounting software and it is probable that potential customers would be comfortable with a Java-based solution (particularly if the solutions provide web-based user interfaces).

It's not really a Delphi vs. J2EE question - the question is "if your company isn't in the business of writing app servers is it better to write an app server or not write an app server?"

Walter Rumsby
Sunday, May 9, 2004

>Why JSP - because it's a lot easier to work with a
> template than to create the output in servlets.

That's a ton of extra crap to produce html. I don't
find it easier with anything complex. With groovy
there's even less of a reason.

>Why Spring - because J2EE applications can have
>oodles of nasty singleton objects, e.g. to represent
>your persistent layer;

What is nasty about them? They are simple, trivial,
and quick. They don't require any xml mapping layers
or frameworks. This whole IOC thing is a joke of extra complexity.

son of parnas
Monday, May 10, 2004

Phile wrote: "I'm also somewhat unnerved that you specified J2EE when the market is small businesses - doesn't J2EE require an application server? Or is it really a synonym for "Java" (i.e. in a desktop environment)"

JBoss is a great application server that is free. It allows you to have a low cost (at least inverstment-wise) working envrionment. Maintenance cost is another issue to consider. My experiences with JBoss are very positive. I've been running several in-house applications on it for over a year now and it has never given me trouble.

Say cheese
Monday, May 10, 2004

So many companies I've seen are running old machines that just creak along in their admin and accounts departments. Win95 and office 95 mostly infact etc.

Delphi sounds ideal. And you've been doing it long enough. Focus on the app, not a rewrite forced by a tool change!!

i like i
Monday, May 10, 2004

What's bad about singletons?

1. They're basically global variables, globals are bad.
2. They force you to interact with a class via the getInstance() method which is arguably a non-standard way and clutters up the code.
3. What say you want to change implementation? Or you realise that you need several implementations.
4. Essentially, static == inflexible.

re: JSP - JSP is Sun's "official" alternative to using out.writeln() in servlets, I'm not saying that it's my preferred approach, but I do think it is preferable to out.writeln(). There are a ton of alternatives in Java. Pick what works best for you.

IoC: don't knock it till you try it (on a large-scale project, it probably is a waste of time for a couple-of-page web app, but that's not what it's intended for).

Re: the original question. Should a company writing accounting software be writing an application server? I'm not sure they should. Why do they think they need to write an application server?

Walter Rumsby
Monday, May 10, 2004

> 1. They're basically global variables, globals are bad.

Yet a global configuration file and container is good.

>2. They force you to interact with a class via the >getInstance() method which is arguably a non-standard way >and clutters up the code.

XML mapping clutters up things more.

>What say you want to change implementation?
> Or you realise that you need several implementations.

Use a singleton / factory.

> IoC: don't knock it till you try it

Having a special framework is a waste. Clearly it
happens somehow in every app.

son of parnas
Monday, May 10, 2004