Some users slow to adopt Enterprise JavaBeans


News: Some users slow to adopt Enterprise JavaBeans

  1. Some users slow to adopt Enterprise JavaBeans (20 messages)

    An article at Computer World is reporting that EJB adoption is slow. The article quotes "Yefim Natis, an analyst at Gartner Group Inc. in Stamford, Conn." "That a mere 20% of applications contain EJBs at present, but he expects usage to double to 40% by 2003." One of the companies repeating the benefits of EJB is VISA, which has used EJB to deploy apps quickly.

    Read article here

    Threaded Messages (20)

  2. 20% of what applications? I got lost.
    20% of web applications would be A LOT!
  3. 20%?? Where does this number come from? It really sounds like some marketing fluff. I'm rather surprised that such a serious site such as serverside would even entertain posting such a nebulous "metric". What did Gartner do? Manually count "all" (??) applications? Com on guyz...

    - sam
  4. The likes of Gartner, Giga etc. are infamous for plucking numbers out of the air ...

    A 'mere' 20% of applications(??) sounds like a serious takeup of the technology to me, given that EJB hasn't been around that long ...
  5. One problem is[ Go to top ]

    that EJB's model doesn't cover everything. When you're building a trading system, for instance, you need to build a bridge to a pricing and/or trade confirmation feed.

    This is an "active" process, with some concurrent programming. A component like this obviously should be abstracted away from everything else, but where does it fit into the architecture? The JMS SPI, EJB Connector, etc, all would seem rather intimidating to an enterprise developer, don't you think?

    So a "non standard" component is created, and booted up with something like weblogic's "startupClass" mechanism. It lacks fault tolerance (gotta write that yourself, or hook into a product's API like Veritas or Tib/Rendezvous), it doesn't integrate with the server very well (it's just a ThreadGroup sitting there).

    It's situations like these where a developer thinks.. well why the hell am I using EJB if I have to write THIS component without it? So they write the whole system without EJB. Some succeed, others fail (as concurrent programming is never easy).

    Just a rant..
  6. One problem is[ Go to top ]

    For the trading system, if you haven't heard of CORBA and CORBA Services, and never get your feet wet with Visibroker, IONA, TAO, or the likes, you do it like Stu.

    But we should dismiss this kind of statistics from specialized "market analysts" that don't have a clue what they are talking about, shall we ?

    Even if the EJB is not widely adopted, this is hardly a bad thing for Java community and for me as a developer in particular.
    And even if it is widely adopted, if we are smart enough we can easily find workarounds, so why should we care ?
  7. One problem is[ Go to top ]

    Billy, this is effectively what I'm doing as well - creating a message container to allow users to create message beans because it's otherwise too hard to write the components to talk to the underlying transport. Since we're only on WL5.1 we can't leverage MBeans though, so it's mainly going to be our own proprietary abstraction -- since writing a JMS SPI binding to my transport is somewhat overkill in the time-to-market area.

    On another note, regarding your failover scenarios, are you leveraging Tibco/Rv's fault tolerance over JMS? This is one of the major complaints I get when suggesting a 3rd-party JMS wrapper to Tibco. I think Tibco is releasing a JMS binding this year though.

    But as for J2EE not solving "everything" -- Costin, you're quite right it doesn't, and I was complaining that it doesn't. CORBA & CORBA services were another attempt at solving "the entire universe of problems" and of course it was a pipe dream. However, the value of having a standard approach for training & developer skills is still undisputable -- there just aren't enough developers with the talent/experience/knowledge to write their own multithreaded servers without the thing leaking memory and having more race conditions than an Olympic event (har har).

    But because J2EE can't solve our major problems, one of our major trading systems is moving away from WL JMS and over to TIBCO, but they're also thinking of trashing WL altogether and just running pure VM's with TIBCO fault tolerance. We don't use EJB, we just use RMI and JMS and JDBC. To me, I'm torn -- J2EE provides a lot of soft benefits in terms of skill support and standardizing training, but if it can't solve our problems, I guess we've got to get out the chisels and hammers and build stuff the old-fashioned way (granted, with a nice chainsaw like TIBCO to help us.)
  8. One problem is[ Go to top ]

    yeh .. i know about the hammers and chisels. they are the tools that we use to make a living. sometimes i am lucky enough to use a chainsaw and that is great too!!
  9. One problem is[ Go to top ]

    An interesting point has been raised about JMS and TIBCO.

    I dont have any 1st hand experience with TIBCO the company, but my experiences so far dealing with them have been rather poor. (10 business days to respond to a pre-sales enquiry! After at least 5 phone calls and voicemail messages)

    In particular, I am interested to gauge customer satisfaction with the Java API of RV.

    Mysteriously, TIBCO seem to be unconcernced about producing a JMS compliant product. Partly through arrogance I suspect, the response I have had from them is that they dont think that JMS is important enough for them to worry about. (yet they were one of the major contributers to the spec...?)

    I havent used TIB/RV, yet in the financial sector where I work it has a large following. Is this following justified? Comments? Feedback? Weak points?

    Why would I choose TIB/RV over SonicMQ?

    PS: My criticisms of TIBCO's service are shared with other UK developers.
  10. One problem is[ Go to top ]

    TIBCO was -swamped- with work up until recently. Though, interestingly, they're announcing major layoffs. Go figure.

    The Tib/Rv 6.x API is excellent. Prior versions were (uh) not. Especially the C api's.

    You could also purchase a small country for the same price of a RV licence. It's an excellent product in some ways, but the company has taken 10+ years to get it right... It's not that complicated either... me thinks their guru developers left long ago

    (standard disclaimer.. the above is complete conjecture, opinion, and perhaps without basis in reality)
  11. One problem is[ Go to top ]

    Oh, and as for RV vs. SonicMQ?

    JMS queues tend to be centralized / transactional. TIB/RV is not. It's peer-peer. It's also *very* fast, and comes with quite a useful message cache.

    It's mainly big in the financial world.

    As for competitors, I know that Softwired's iBus is probably the only other vendor that has a product with comparable academic roots (TIB/RV was originally TIB, or "the information bus" by Dave Cheriton & Dale Skeen in the 1980's. iBus is based on Silvano Maeffis' work on fault-tolerant peer to peer distributed communciation.)

    And I bet that iBus is actually reasonably priced, unlike another product....

  12. One problem is[ Go to top ]

    Speaking of trading systems....

    I'm currently heavily involved in this side of the business and am looking at ways for 'Joe Bloggs' to be able to build these systems. I've implemented a message bean container that is clustered. You can run this container on a number of boxes and together they act as a process pair. When you use it with a good JMS transport (and I mean Tibco RV with a JMS wrapper on top) then your bean runs in a very high availability cluster with guaranteed message ordering in the presence of fail-overs and you have < 1 second fail over times.

    One container gets elected as the leader and processes the work. The others shadow the work. When the leader fails, one of the others is elected leader, retries the pending shadowed work and then carries on. This is all transparent to the message bean programmer.

    I'm doing this because I think it's currently too hard for most people to do this. Implementing the above as an MBean that looks like a EJB 2.0 message bean container means that it is familiar to programmers who know message beans but it allows them to build a very high availability application with needing to do election algorithms, wave algorithms, heart beats etc, replication. The use of JMX allows the container to plugin most J2EE servers and actually be controlled/instrumented using the console that comes with the server.

    The general statement, J2EE is not useful here is correct, but if you look at my other comments here and in other threads, my point is that the portability of the skills is whats important and that when specialised containers (like mine, for instance) become commerically available, they do offer an advantage to companies looking to develop this sort of thing, especially at the high end which is where the container specialization is most applicable. The ability to leverage skillsets will always be useful and the J2EE abstractions can be a useful way to hide complexity.
  13. Billy, which EJB server?[ Go to top ]

    Billy, which EJB are you developing your message beans on? Websphere and EJB 2.0?
  14. Billy, which EJB server?[ Go to top ]

    WebSphere with my own custom MessageBean Container.
  15. Billy, which EJB server?[ Go to top ]

    But to be fair, it could be anybodies J2EE server or even a standalone java demon. You just give it an .ear file and configure the container and away you go.
  16. One problem is[ Go to top ]

    it is too easy for you to assume that YOU know what you are talking about Cozianu. there is CORBA but it alsways comes down to the developer. period. end of your story. J2EE is a huge framework but it does not solve the ultimate problem. Stu knows his business.
  17. One problem is[ Go to top ]

    Sure, I usually kinda don't know what I'm talking about :)

    Stu was blaming developers for not some J2EE project failures.
    My problem was that the example he gave was a typical case where J2EE was totally inadequate.

    So I think there are also project managers to be blamed for buying into Sun's marketing hype.

    Yes, Stu knows his business I totally agree.
    So, what's your point ?
  18. One problem is[ Go to top ]

    that was my point. J2EE is a fine delivery framework for the internet .. but a lot of work may need to be done outside of that framework.
  19. One problem is[ Go to top ]

    That was my point too,
    but Stu's point was that there are J2EE extension points (Connectors) or mechanisms (JMS) that will practically round up the whole thing, so you can still do a lot of extra things inside J2EE.

    I kinda disagree to the J2EE covers everything approach (not the first or last time I don't agree with Stu).

    Someone misunderstood something here , or Stu was not very explicit, or it's just my bad English :)
  20. One problem is[ Go to top ]

    throw in a bad day on my part and we have an interesting discussion. the only one who did not reply was Stu ::))
  21. I am one among those people.I did projects in dcom,corba.But I am unaware of j2EE.What could be j2EE?
    I know java,jsp.I want to switch over to EJB.I want your eminent advises in this.Please.