ObjectJuice is an enterprise java Application Development Framework (ADF); it provides common functionality necessary to develop an application in a form of several Application Services: Security, Access Control, Persistence, Schema and Query. ObjectJuice ADF is fully compatible with J2EE applications and it is meant to replace (or supplement) EJB.
- Posted by: Max Shuleman
- Posted on: August 26 2002 20:50 EDT
See product website for the complete details.
ObjectJuice Application Development Framework (ADF) aims at the significant reduction of the costs of enterprise Java development by lowering the training requirements and simplifying application lifecycle.
ObjectJuice ADF provides all the common functionality necessary to develop an application in a form of several Application Services: Security, Access Control, Persistence, Schema and Query. ObjectJuice ADF abstracts and hides the implementation details of these Services behind the few very well defined Java interfaces.
These services can be deployed on multiple machines over local network, intranet and the Internet with complete network transparency.
At the configuration time, you tell ObjectJuice components where to reside and how to communicate with the others; your application has no idea how many computers it runs on and which network protocols it uses.
Scalability, failover, resource pooling and deployment are handled internally by the framework.
ObjectJuice ADF is easy to extend by writing your own resource- and network connectors. Number of pre-built connectors for popular databases, socket- and HTTP-based network connections are included.
ObjectJuice ADF allows transparent integration of the data and services that are NOT built on traditional database platforms (legacy applications, XML data, light-weight applications)
ObjectJuice ADF is fully compatible with J2EE applications and it is meant to replace (or supplement) Enterprise JavaBeans (EJB) solutions. It can be used for J2SE and J2ME development as well.
ObjectJuice ADF supports flexible User and Group structure where permissions are inherited as defined by Group relationships.
ObjectJuice ADF offers object-based (not class-based) access control by default ("Customer #27 is read-only for this group of Users, not all the Customers")
ObjectJuice ADF supports flexible object structure combining best of both relational (master-detail relationships) and object-oriented (inheritance) worlds.
ObjectJuice is brought to you by netprogrammer.com LLC, a Texas startup dedicated to researching, developing and marketing of the new enterprise software technologies.
Comments and suggestions are always welcome.
info at objectjuice dot com
- EJB Alternative ObjectJuice Announced by Tom Pridham on August 28 2002 10:50 EDT
- EJB Alternative ObjectJuice Announced by Ray Harrison on August 28 2002 15:11 EDT
- EJB Alternative ObjectJuice Announced by Max Shuleman on August 28 2002 15:50 EDT
- EJB Alternative ObjectJuice Announced by Steve Muench on August 30 2002 07:52 EDT
EJB Alternative - The Death of EJB as we know it? by Dilip Ranganathan on August 30 2002 11:02 EDT
- EJB Alternative - The Death of EJB as we know it? by Robin Sharp on August 30 2002 11:46 EDT
EJB Alternative - The Death of EJB as we know it? by Ray Harrison on August 30 2002 04:23 EDT
- EJB Alternative - The Death of EJB as we know it? by Dilip Ranganathan on August 30 2002 10:14 EDT
- EJB Alternative - The Death of EJB as we know it? by Paul Sijpkes on September 03 2002 01:42 EDT
- EJB Alternative - The Death of EJB as we know it? by Dilip Ranganathan on August 30 2002 11:02 EDT
- EJB Alternative ObjectJuice Announced by Steve Muench on August 30 2002 07:52 EDT
- Another EJB alternative JDSM by noam camiel on March 21 2003 11:30 EST
I was excited about an EJB alternative....until I read the pricing page for this product.
I have never been a fan of metered software. A few coding mistakes can be costly (in more ways than one). It gives me a feeling of paying a penalty each time I make a call to the "metered interface".
Just my opinion.....
Yeah, I agree. Definitely gonna skip any "metered" pricing.
Agree 100% on the metered pricing - that's not an option and most enterprises I know avoid that sort of pricing structure (granted I don't know what every enterprise does, of course). Also, who has implemented this in production and what sort of applications were these that were implemented?
Additional info (had to add after reading the first comments):
The next version of OJ ADF scheduled for October 2002 will
include the following features:
XML / Web Services integration (including ability to use non-Java clients)
New management module
And, yes, traditional per-server and per-site licensing too.
Oracle's enterprise Application Development Framework for J2EE developers called "Business Components for Java" comes for free with our JDeveloper9i IDE.
It can also be used with or without EJB, your choice.
There are no runtime fees for using the J2EE framework, just the $995 cost of the IDE.
It's been in production for over two years, and we have over 800 internal developers using BC4J to build J2EE web applications (along with lots of external customers, too).
Apps built using BC4J work excellently against Oracle database and with Oracle9iAS app server, but can deploy to any J2EE server and use any JDBC-reachable SQL92 database as well.
Have a read of this whitepaper for an overview:
I came across this really interesting article at O'Reilly.net
The current trendy thing to do is to bash EJBs to smithereens - the author of the referenced article is no exception. As he seems to write articles/books primarily concerned with .NET, I would suggest that his frame of reference is (likely) without a tremendous amount of relevant experience. I don't find EJBs too difficult or inefficient to work with - used correctly and with the right container, they work great. However this is true only if you use them as intended. Many people try to use them strictly for persistence or as a reflection of an existing database, as examples. Doing so has the potential to be both difficult and inefficient. And the fact is, EJB containers have improved greatly with 2.0 and will continue to evolve and get better both in the specs and in the container implementations. And hey - EJBs are not a magic bullet - they're just a part of a tool set called J2EE. Use each tool for their intended purpose and you'll be better off.
Oh man.. you don't know just how wrong you were. and btw, for the correct "Frame of reference" you can look up http://discuss.develop.com/advanced-java.html and search the archives for the name Ted Neward. you'd know exactly where the expertise comes from...
If you'd read the article you will have noticed that Newards's main point was that EJBs are not as portable as Sun has painted them to be. Our team experienced this, and we have gone back to writing the business framework ourselves simply because it's more efficient and flexible.
He also mentions that the bean locks for each request, a fact that really sucks for apps with traffic of more than a couple of requests per second, and if your going to write an app expecting such low traffic, then why use EJBs? EJBs require a massive memory greedy process, in the form of an EJB server, all to achieve some very simple functionality. Newmans point is not "EJB bashing" it's simply saying that to justify the use of such a server, you really do need to research whether you actually need the "power" that EJBs provide. Neward's article reads as a healthy analysis of an area that has had a lot of hype and just does not seem to be delivering.
So far you happen to be the only person to have actually _read_ the article. and you made some really logical observations. Hope we can continue in this same vein...
Hi Paul -
Thanks, but I have read the article. Ted's points are the same three arguments that are always given and in my mind two of the three are becoming much less of an issue, at least in my experience. The three points are:
1.) (As you mention) EJBs are not as portable as Sun claims:
That's certainly true, but with EJB2.0 and with a number of containers with solid CMR implementations, I find this particular point to be much less pertinent than dealing with the ejb1.x style implementation and improving all the time - I quite easily move between JBoss 3.0, Weblogic 7, Sybase EA Server and Oracle 9iAS with minimal effort (all systems, by the way, can handle far more than a couple of requests per second without gobbling up memory)
2.) Vendor Specific hooks affect portability: Well sure they do but so what? Typically they aren't hard to learn and they offer value added functionality to the stack - tuning, locking implementations, etc.
3.) Hard for average programmers to learn: EJBs are very useful if you have a need for them. You point of research before use is well taken. That said, while using EJBs does help when writing transactional, secure, distributed systems and simplifies many tasks, writing distributed systems isn't neccessarily a walk in the park. While a stated aim of EJBs from the spec is "making enterprise applications easier for developers", as Ted points out, it doesn't say that the so-called average programmer will be able to pick it up in a couple of days. Distributed enterprise applications aren't always simple - many programmers have never dealt with them before including the concepts of synchronization, transactions, etc. The fact is that it will take time to learn.
I hardly find Neward's article a healthy analysis and is itself more hype and less investigative in nature than I at least would like in such efforts.
I have to admit that I hated EJBs at first when moving from jsp/servlets/jdbc.
but after working with it, i have to say that I can't think of writing enterprise software any other way, so EJB-QL might not be as cool as SQL, but it's getting better with
People seldom port between EJB servers, that I agree but isn't EJB about declarative programming and keeping
system's logic out from our codes ? transactions, security, persistence, etc.
if you have never built an EJB using IDEs like JBuilder7 - EJB designer, please do, and you will see it's true power.
I love the idea behind EJBs, it's learning curve is worth it.
btw, it's not a question of whether people port their codes between ejb containers, but a question of if they wanted to, can they ? a resounding yes!
JDSM (Java Distributed Service Management) is a lightweight and simple alternative to EJB implemented on top of RMI
Please take a look at: