Home

News: EJB Alternative ObjectJuice Announced

Bookmark and Share Get thread feed

  1. EJB Alternative ObjectJuice Announced (14 messages)

    • Posted by: Max Shuleman
    • Posted on: August 26 2002 20:50 EDT
    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.

    See product website for the complete details.

    Press Release
    =============================
    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

    Reply to this

    Threaded Messages (14)

  2. EJB Alternative ObjectJuice Announced[ Go to top ]

    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.....
    Reply to this Reply to original

  3. EJB Alternative ObjectJuice Announced[ Go to top ]

    Yeah, I agree. Definitely gonna skip any "metered" pricing.

    -Newt
    Reply to this Reply to original

  4. EJB Alternative ObjectJuice Announced[ Go to top ]

    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?

    Thanks
    Ray
    Reply to this Reply to original

  5. EJB Alternative ObjectJuice Announced[ Go to top ]

    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
    Clustering guide
    And, yes, traditional per-server and per-site licensing too.


    Reply to this Reply to original

  6. EJB Alternative ObjectJuice Announced[ Go to top ]

    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:

    http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
    Reply to this Reply to original

  7. EJB Alternative - The Death of EJB as we know it?[ Go to top ]


    I came across this really interesting article at O'Reilly.net

    http://www.oreillynet.com/pub/wlg/1922
    Reply to this Reply to original

  8. EJB Alternative - The Death of EJB as we know it?[ Go to top ]

    Try this one -

    http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf
    Reply to this Reply to original

  9. EJB Alternative - The Death of EJB as we know it?[ Go to top ]

    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.

    Cheers
    Ray

    Reply to this Reply to original

  10. EJB Alternative - The Death of EJB as we know it?[ Go to top ]


    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...
    Reply to this Reply to original

  11. EJB Alternative - The Death of EJB as we know it?[ Go to top ]

    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.
        
    Reply to this Reply to original

  12. EJB Alternative - The Death of EJB as we know it?[ Go to top ]

    Paul

    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...
    Reply to this Reply to original

  13. EJB Alternative - The Death of EJB as we know it?[ Go to top ]

    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.


    Cheers
    Ray
    Reply to this Reply to original

  14. EJB Alternative - The Death of EJB as we know it?[ Go to top ]

    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
    each release.

    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!
    Reply to this Reply to original

  15. Another EJB alternative JDSM[ Go to top ]

    JDSM (Java Distributed Service Management) is a lightweight and simple alternative to EJB implemented on top of RMI
    Please take a look at:
    http://www-106.ibm.com/developerworks/java/library/j-jdsm/

    Noam.
    noam@telemessage.com
    Reply to this Reply to original