A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm currently trying to answer questions about whether it's a good idea for my company's product (a real-time OLTP framework) to support J2EE. We currently support Java, but strictly as POJO's, via a web services interface.
I'm not a Java expert by any means, and even less of one in J2EE, but my impression is that the Java world has largely passed J2EE by. This because of:
1. difficulty in keeping up with the many different, and sometimes conflicting, specifications that make up J2EE;
2. extreme performance hit that results from the many layers of J2EE.
Number 2 is particularly relevant, as our product is geared towards real-time OLTP for industries like Wall St., telecoms, etc.
Can anyone confirm or refute the above? What has been your experience with J2EE for building large, high-performance OLTP systems?
Many thanks in advance...
What do you mean by "support"? Do you mean that people can deploy J2EE applications into your product? Or merely that you can natively speak to the standard J2EE appservers? Perhaps you mean that your product could be deployed to a J2EE appserver?
As to your numbered points:
1. A lot of the specs probably don't apply to your situation. For example, I don't see why you would need to learn anything about the Servlet API. I don't really understand what you mean about conflicting specs - can you give an example?
2. There is nothing inherent to J2EE that causes performance problems. Every J2EE app I've ever worked on (I know, bad sample size) has been bottlenecked by either the network or the database. If you need distribted transactions, then you need them ... but they're not free so you take a hit. If you need clustered sessions then you use them and you pay the price. If you don't use the expensive pieces, perfomance is rarely an issue (unless your app server implementation stinks).
Tuesday, July 12, 2005
By "support" I do mean that people would be able to deploy J2EE applications into our product. That is the crux of the question, and is the current objection to our product from one (large) potential customer.
It currently supports POJO's -- i.e., it will dispatch transaction requests to Java classes that have been registered as providing those methods as specified in a WSDL file.
However, it does not provide any of the scaffolding that would be required to serve as a container for J2EE apps.
FWIW, the performance target is to support somewhere in the range of 1,000 to 10,000 transactions per second on commodity hardware (i.e., 4-cpu Intel Linux), where each transaction performs a "reasonable" number (10-20) of database operations. (And yes, this requires specialized DBMS software).
We do this today with C++ apps, and with POJO's. I'm just not sure if this is realistic for J2EE apps.
>However, it does not provide any of the scaffolding that would be required to serve as a container for J2EE apps.
I'm no expert, but I guess the only reasonable way to do this would be to embed an existing J2EE Server. Which is not what they want, since they already have their own corporate standard, I bet you. The other solution would be to make (part of) your framework a J2EE application.
Whether it completely defeats the purpose of your framework or not is another story.
Wednesday, July 13, 2005
If your application is really realtime then embedding it into J2EE application containers is going to hurt you royally.
Saturday, July 16, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz