HP gives away Bluestone J2EE Server for free

Discussions

News: HP gives away Bluestone J2EE Server for free

Bookmark and Share Get thread feed

  1. HP gives away Bluestone J2EE Server for free (80 messages)

    The days of high priced base J2EE servers may be coming to an end. HP has announced that they are giving the Bluestone J2EE Server for free. HP plans to make make money by selling extra software on top of the base J2EE server.

    Click here for the CNet story.

    Reply to this

    Threaded Messages (80)

  2. HP gives away Bluestone J2EE Server for free[ Go to top ]

    This is very significant news. HP has recognized that the application server market cannot be penetrated using the usual 'tactics', and has taken an unprecedented step that could make a difference. A free server implementing many of the latest specs, backed commercially by HP? Sounds promising.

    Floyd
    Reply to this Reply to original

  3. HP gives away Bluestone J2EE Server for free[ Go to top ]

    This is a very good news indeed. But, before I rush out and download Bluestone, I would like to know which part of the application server is for free?

    Also, this is a bold strategy on HP part. Now, smaller application server companies such as ATG will struggle for survival if they don't follow suite.

    Reply to this Reply to original

  4. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Other vendors do not have to follow suite, they can leverage the HP Application Server software in their products for free and reduce the cost of goods for their product lines. The HP Application Server announcement allows ISVs/OEMs to bundle the application server software for free as well. Hence, ATG and others can build higher level software offerings and not have to incur the cost of building or licensing a J2EE application server.

    -Rich.
    Reply to this Reply to original

  5. HP gives away Bluestone J2EE Server for free[ Go to top ]

    The question is which parts of J2EE are included - basically all of them - Servlet, JSP, EJB, JTS, etc... It is not just a development package, but fully scalable with load balancing across hundreds of application servers. We have included significant out of box functionality, including over 90 Trailmaps on how to develop and deploy applications. While we have our own high capacity Servlet engine, it also bundles Tomcat, as well as a number of other Apache open source including Jetspeed, Cocoon, Struts, Xalan and Xerces. The management interface is all JMX-driven (we have a cool GUI for controlling the app server).

    The server is built on our Core Services Framework - meaning that you can add your own services and API's very easily, as well as actually embed the app server within your own application - this is perfect for ISV's. We've done cool things like plug JADE, JXTA and GNUTELLA into it.

    And performance is pretty darn good. We have rearchitected the app server from the ground-up, and it screams.

    It does not ship until Nov. 19 - but you can signup on our web site now - http://www.bluestone.com/products/hp-as/default.htm
    Reply to this Reply to original

  6. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bob,

    I've recently downloaded the HP Internet Server. It seems that HP Internet Server was released under GNU LGPL, what is the relationship between the HP Internet Server and this announcment?

    Mohammed Firdaus
    Reply to this Reply to original

  7. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Regarding the LGPL license for HP Internet Server. In reality, we had wanted to do the same thing with HPAS. The problem is that Sun's J2EE license restricts us from doing this. Sorry...
    Reply to this Reply to original

  8. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bluestone always delivered crap. Free is way too expensive for this despite what Travis Bickel (Bluestone's minister of propaganda) might have us believe.
    Reply to this Reply to original

  9. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Dear Albert Einstein,

    My name is Bob, not Travis... And I do admit to being from HP and previous to that Bluestone, and liking our product.

    Bob Bickel
    HP Middleware
    Reply to this Reply to original

  10. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Travis,

    You talkin' to me?

    Of course you like bluestone's products; when HP was suckered into buying them we're sure you made quite a pile of cash for yourself. You and bluestone should be congratulated on that business coup (not for your engineering)

    As for the product HP deserves the .0000005% market share they have for java appservers. The documentation is the worst in the industry; no documentation would have been better than what you delivered. The "appserver" was a shaky core surrounded by 3rd party plugins. (The BS in UBS certainly does not stand for what your marketing states.)

    The "new" "free" bundle: oooo, you package struts and cocoon and a ton a other widely available packages. Thank god. It's soooo hard to get a hold of struts....

    Reply to this Reply to original

  11. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Dear "Albert Einstein",

    1. Bob Bickel is the CEO of the HP Middleware Division and used to be the CTO of Bluestone Inc., acquired by HP. In other words, he know's what he is talking about.
    2. Bluestone used to be a "techie" company; they know J2EE. The documentation shipped with TeS might not have been one of the best but if you know J2EE, you have enough with it: nothing is proprietary, which can not be said of many other application servers. Thanks to the acquisition by HP, documentation will for sure be more "for dummies" like yourself.
    3. Don't underestimate the girls & guys in Philly: they are the driving force behind JCA, CSF (Core Services Framework) and HP is still the company of e-Speak, the precedor of todays web services. HP spoke about e-Services (todays web services) many years before IBM, MS and Sun. Unfortunately for HP, they have poor marketing...

    No offence whatsoever...

    Cheers,
    Olivier "Mad Inuk" Swyngedouw
    e-Business Solutions Specialist
    Reply to this Reply to original

  12. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Does it support J2EE 1.3? including EJB 2.0 support? The article refered to talks about JMS being an add-on! It also states that transaction support is rudimentary. does this mean it isn't XA? I know that HP bluestone didn't have its own JMS provider but used sonic MQ, Is this still the case? This would explain having JMS as an add-on.
    Reply to this Reply to original

  13. HP gives away Bluestone J2EE Server for free[ Go to top ]

    They can't call it J2EE 1.3 unless a message transport is bundled AFAIK. So, the JMS question will be interesting.

    I wonder if HP and other vendors start selling supported free J2EE servers, what does this mean for jBoss etc?

    I guess HP will still be charging for support for this even though the runtime is free..
    Reply to this Reply to original

  14. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Billy,
    Regarding what this will mean for JBoss. As has been said for quite some time, J2EE support is becoming a commodity thing. This is true for JBoss as well. But, JBoss is so much more than just free J2EE. The upcoming JBoss 3 will break new ground in terms of clustering and JMX support, which will be way ahead of the rest of the crowd. In fact, I would probably dump EJB's entirely, and implement my application logic as MBean's instead, since they provide a better and simpler programming model, and also many of the features available in EJB. At least when intelligent use of JMX is provided, which is what JBoss 3 is all about.

    regards,
      Rickard
    Reply to this Reply to original

  15. HP gives away Bluestone J2EE Server for free[ Go to top ]

    I agree with what you say. Once WSIF and WSDL arrives then I'd view application servers as infrastructure hosting components. Those components could be EJBs, they could also be MBeans as you say, jini objects, .Net components etc.

    I think we'll start to see application servers becoming basic plumbing that we can attach various component models to, of which EJB is just one choice. WSDL coupled with WSIF should, eventually anyway, allow this abstraction to be made.

    Thats what I see as the meat behind the current web services hype.

    What are your thoughts as regards jBoss and WSIF and WSDL? I remember Marc Fleury saying that he views containers as service containers which are attached to various protocols (RMI/IIOP is but one) using adapters, a view I agree with completely. This is very like the promise of WSDL/WSIF.

    Cheers
    Billy
    Reply to this Reply to original

  16. HP gives away Bluestone J2EE Server for free[ Go to top ]

    As Marc said, protocols are going to be adapters in JBoss 3 that can invoke things, be they EJB's, MBeans or whatever. I'm not much into Web Services myself (since I'm not in a corporate environment that requires integration work of that kind), but for those who are I believe JBoss is going to be the premium infrastructure framework to build components with, since you are in complete control over how things work, and since JBoss 3 will provide quite amazing hot-deployment of services (or server modules), and not just EJB's. The entire server is in fact hot-deployed, so you only need a 1.44 disk to install it :-) The rest is streamed from the net, as it should be.

    Ah well, until it's released this is all hype-ware though :-) But when it is, the game is over.

    /Rickard
    Reply to this Reply to original

  17. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Rickard-
    I played with JMX (JBoss, Sun's RI and IBM's container)
    as a possible replacement for the bloated EJBs.
    However, what appers to be a winner is a little known
    Jini-based container, called RIO (see at www.jini.org, registration required). The RIO service beans are a lot
    easier/better than JMX beans (IMHO), benefit from the supperior Jini transaction layer, JavaSpaces (which appears as JMX-like standart in-container service) and Jini/RMI protocol!
    The bean container itself is a state-of-the art one, with Swing UI management console and QoS support (so you can easily do robust clustering). In fact, I have an experimental XDoclet code to even further simplify RIO/Jini Beans. For persistent objects, you can use JavaSpaces, Castor or something really smart such as db4o (www.db4o.com)

    Hristo
    Reply to this Reply to original

  18. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Hristo,

    I tried out Rio, to see if it was any good. From the homepage description it seemed very powerful, so I downloaded it. The install went ok-ish, although the XML-config is somewhat confusing.

    However, when I had started it and looked around I realized that it centered around the usual Jini-ism that all services should have their own JVM. To me this is completely nuts. If I was building a large application, and all services had to be in separate JVM's (let's say I had 30 services for example), not only would it perform really bad from all the networking, it would take loads of system resources. The first rule of distributed objects is to...*drumroll*... not use distributed objects. So, I'm still betting on JMX being a better base model, since it is more centered around in-VM components while still allowing for distributed use.

    /Rickard
    Reply to this Reply to original

  19. HP gives away Bluestone J2EE Server for free[ Go to top ]

    RE J2EE 1.3, JMS and JTS support

    The app server in its free form is NOT a serious consideration. Without durable JMS there is no guaranteed mnessaging and without 2phase commit it's a lost cause.

    So what is free could not be used to develop serious J2EE applications.

    But I guess that's what you are relting on.

    I would also question your right to state J2EE 1.3 support without durable JMS and 2phase commit.

    And what is CSI...?
    Reply to this Reply to original

  20. CSI[ Go to top ]

    This is the IIOP interoperable security.

    Billy
    Reply to this Reply to original

  21. HP gives away Bluestone J2EE Server for free[ Go to top ]

    The assertion that Rio relies on the usual Jini-ism that all services should have their own JVM is false.

    Rio provides a dynamic container (called a Cybernode) which provides basic lifecycle management of services called Jini Service Beans (JSBs). JSBs are provisioned to available Cybernodes based on a declaritive QoS model. A Cybernode dynamically instantiates multiple JSBs within its own VM. JSBs discover other JSBs based on what they need to do.

    /Dennis
    Reply to this Reply to original

  22. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Dennis,

    That may be. I just noticed that all the default services used their own JVM, which is bad. I didn't look further at that point, so you may be right.

    /Rickard
    Reply to this Reply to original

  23. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Rickard, my friend!
    You got it wrong about RIO. RIO Cybernodes (=JMX container) require a single JVM and allows for several JSBs (=MBean)to be managed within. Please, read carefully "Rio architecture overview". Not only that, but you'll find the typical for a
    bean containers JDBC and thread pools to be shared by the JSBs in the same JVM! I think if you compare feature by feature JMX and RIO, you will quickly appreciate simplicity and good OO ( and I know you have a taste for it!). Here
    are some comparisons:
    ----------------------------------------------------
    Jini Service UI<-->Http based management of the JMX container
    JSB(Jini service beans)<->MBean
    Cybernode<-->JMX container
    lease-based Jini RMI<--> home-grown RMI ?
    Distributed event<-->(client-server) JMS?
    Jini look-up<--> (client-server) JNDI?
    Jini distributed transactions<-->???
    QoS parameter for JSBs<-->clustered/redundant JMX containers
    Op strings<-->MLET service
    ----------------------------------------------------

    I think what RIO needs is XDoclet !!! The only problem
    with RIO is that though it is free, it is only partially "open source", but that is worked upon as per Dennis Reedy from Sun.



    In regard to JMX I'd like share my thoughts with you.
    JMX is very focused on the container and the beans within, but leaves unaddressed the network. It does provide some fancy features (quering bean properties, relation service), but they are rearly needed and usually done in an easier way. Think simplicity! Also, the JMX specs refuse to define RMI-like, JMS-like and JNDI-like protocols, transactions for now, so you do it in non-standard way (JBoss or IBM's Tivolli JMX container). I think JMX container could be
    very usefull in Swing GUI applications as a replacement
    of the BeanContext API, have you thought about that?
    It would have been nice if Sun consolidated their "bean"
    APIs ( ... and provided more featured bean introspectors, to save code for WebWork, Commons BeanUtils and other projects). Oh, well ... dreaming

    By the way, there is one more container, Apache's Avalon
    which is like JMX. Why was it developed at all, I do not know, but unfortunately, there are already some serious apps (e.g. JAMES) based on the Avalon container.

    More and more, it sounds like an JavaWorld article
    "Modern java containers and beans frameworks" is needed to compare EJB, JMX, RIO, Avalon and Jiro ...

    Have a nice day,
    Hristo
    Reply to this Reply to original

  24. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Hristo,

    Alas Java Report is no more. They are replacing it with a generic programming publication covering C++, Java, C# etc and it will only be out every other month.

    Reply to this Reply to original

  25. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Rikard

        If that is what you got from examining Rio, then you haven't understood it at all. Rio is designed around a "Container" model and so many services can be in such a container. There is absolutely no requirement that they all be in separate containers.

        While the example that comes with Rio do show a separate container, that is not the rule. Such an example exists for pedantic purposes and for such purposes an easy example is good. I think M$ rejected the petstore and it's underlying technology in much the same way.

    Regards
    larry
    Reply to this Reply to original

  26. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Larry,

    I need to take another look then. I'm a bit confused here. The entire idea of Rio is to provide a container for Jini services, and then nothing of that is used for the basic bootstrap services, since all of them launch their own JVM's. Strange.

    Thanks for pointing out the flaws in my description though. Glad to hear I was wrong :-)

    /Rickard
    Reply to this Reply to original

  27. HP gives away Bluestone J2EE Server for free[ Go to top ]

    By basic, do you mean basic jini or basic Rio.

    If basic jini, then this would include jini lookup service, thransaction manager etc. A reggie lookup service could be on another machine somewhere on the network or it might be on the same one. If the same one then yes, it has a separate VM although I was able to get it to start as a separate thread in my project.

    If by basic Rio, then this would include webster, cybernode, provision monitor, lincoln, etc. Webster can be started as a separate thread under the cybernode by a command line param. A provision monitor can be on another machine so it is is in it's own VM. Although I did the same trick to get is to run in a separate thread.

    I used Rio a bit and found it was very useful for simplfying Jini. But, I know Dennis listens to people (although he has been known to bite ;)) and is quite interested in building ideas people have suggested into it.

    Regards
    larry
    Reply to this Reply to original

  28. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Just thought I would mention my jini project, Vagrant
    which does in fact run all of the basic Jini services
    in a single VM (and has done for 12 months now)...but not designed for production use like RIO.

    Having said that I have 'successor' project to Vagrant
    called Lamp which uses the OSGi standard for lifecycle
    management of services - and it also hosts all services
    in a single VM - still haven't released it but maybe one
    day ;-)

    Finally the Alewife release of Jini allows activatable
    services (inlcuding the core jini services) to run
    in a single VM - unfortunately you still need RMID
    running => two VMs
    Reply to this Reply to original

  29. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Regarding JBoss, there is a difference in that we (HP) are not allowed by our license agreement to make our source code available. This is a restriction of all J2EE licensees, which we are. We would like to see this changed - if you would too, please let Sun know.

    In terms of JMS and scalable features - these are all bundled in HP Application Server V8.0. This is quite a full-featured, technically advanced product.

    Bob Bickel
    HP Middleware Division
    Reply to this Reply to original

  30. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Sun knows full well that source is always available to a
    ridiculous degree from any vendor, solely due to
    a "distributed reflection requirement" of the java platform, invented by Sun, a feature which
    nobody really uses except to obtain source from a
    vendor :-) It's absurd.

    just switch to royalty-based licensing scheme, and us
    customers will be fine. If your
    product is as advanced as you say it is, then we'll
    find ourselves using it, so you can charge us more hit
    points for what we use it for. unlimited licenses even
    for add-on features are a joke. why do customers always
    bear the brunt of risk by having to commit all this cash
    up front, when we know the *unexpected* is always lurking
    around the next corner?
    Reply to this Reply to original

  31. Out of topic - MBeans the next EJB killer...[ Go to top ]

    To my understanding MBeans don't have declarative transactions and security, which is basically the number one value-add with ejbs. (I never want to build a system with explicit begins and commits again, it's _really_ a pain in the ass.)
    Reply to this Reply to original

  32. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Well, yes and no. The thing is that both declarative tx and security are implicit in terms of code. There are two ways to introduce them in a JMX system:
    1) the JMX server can provide it as a service to the MBeans when an invoke() is being dispatched
    2) the MBean itself can handle it internally. If you're using ModelMBeans or DynamicMBeans this becomes very easy to code (just get the invoke, do the tx stuff, and delegate to real code).

    Personally I'd use 2, since one makes you dependent on the features of the particular JMX server you're using. And I have also just implemented a system using 2, and it is very easy to do. So, I get the good stuff from EJB (which is as you say the declarative stuff, amen to that), but also the good stuff from JMX (I can configure it, add MBeans at runtime, do relations, manage them remotely, introduce my own protocol adapters, and so on and so forth). To me this is much more value add than EJB, which is just a lot of complexity for not so much gain.

    There are also some things I can do with JMX, that just isn't possible with EJB. For example, I can have dynamic dependencies between MBeans so that when A depends on B, a setB() method will be called on A with a reference to B. In EJB you'd use JNDI home lookups to do similar things, but that requires way more code, plus the good thing about the JMX way is that if B goes away I can detect that (BTW, how do you detect EJB's that go away? YOU DON'T) and call setB() with null, *or* let setB() be called with a reference to another MBean that satisifes the requirements. I.e. fault tolerance that is very easy to code and understand. And that's just the beginning of the list... JMX rulz :-)

    The above *does* require a basic framework to get it going (barebones JMX is a bit rough), but once you have that (and I do), the rest is a breeze.

    /Rickard
    Reply to this Reply to original

  33. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Hi Rickard!
    Interesting thoughts you are sharing. In my opinion EJB is a kind of restricted in the way I need an application server (to much session/client driven). Though , as a database wrapper it would be great.
    If you think MBeans will enable me to realize a more 'serverdriven' app.server (with or without EJB) I definitly will take a look at jboss3.0.

    /Jon
    Reply to this Reply to original

  34. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Thus spake Rickard:

    <quote>
    There are also some things I can do with JMX, that just isn't possible with EJB. For example, I can have dynamic dependencies between MBeans so that when A depends on B, a setB() method will be called on A with a reference to B. In EJB you'd use JNDI home lookups to do similar things, but that requires way more code, plus the good thing about the JMX way is that if B goes away I can detect that (BTW, how do you detect EJB's that go away? YOU DON'T)
    </quote>

    Right, but this way, it is *fast*. And scalable. That's the typical compromise between static and dynamic typing. The more you can get our of your way at the early stages (for EJB's, that means deployment), the faster it will be. You lose some flexibility, like listeners for objects that go away, but the resulting framework is *fast*.

    The downside with this model is that you only find out that an object is gone at the last minute, but this compromise turns out to be acceptable because you are basically programming for the most common case (which is: your object has *not* gone away).

    EJB's have proved they could scale.

    JMX used as a replacement for EJB's needs to prove itself (and I believe it will fail to scale in that particular area).

    It's an interesting concept, though, and I give you total credit for coming up with it.

    --
    Cedric
    Reply to this Reply to original

  35. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Cedric,

    Interesting reply. Could you please briefly state why EJB's are scalable? Having implemented 3 EJB containers myself I do have some ideas, but would like to know your opinion. What are the key reasons EJB's are scalable?

    regards,
      Rickard
    Reply to this Reply to original

  36. Out of topic - MBeans the next EJB killer...[ Go to top ]

    <quote>
    Interesting reply. Could you please briefly state why EJB's are scalable? Having implemented 3 EJB containers myself I do have some ideas, but would like to know your opinion. What are the key reasons EJB's are scalable?
    </quote>

    I was just observing that considering the tens of thousands of sites deployed on EJB technology and scaling well, they do not need to prove themselves, as opposed to JMX-based technology.

    We can start comparing notes when we see "JMX EJB" clusters with a hundred nodes deployed commercially and performing as well. I'm not saying it won't happen, just stating that there is no such thing as of today.

    --
    Cedric

    Reply to this Reply to original

  37. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Cedric,

    Thanks for the non-reply ;-) So, there are no key reasons why EJB's are scalable (or none that you want to mention anyway). Thus, there are no inherent reason why JMX components could not do the same. That said, I must say I'm a bit curious about the "tens of thousands" number "scaling well" considering the recent poll on servlets.com (http://www.servlets.com/polls/results.tea?name=ejbs). Many comments are directly related to performance, and they're not exactly saying it "scales well".
    But you're right, there's no such thing as JMX clusters today, so JMX still has to prove itself.

    regards,
      Rickard
    Reply to this Reply to original

  38. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Rickard wrote:

    <quote>
    Thanks for the non-reply ;-)
    </quote>

    Sorry if that's the way it looked, it wasn't my intent. I just thought that the question "Tell me why EJB is a technology that scales" is ludicrous because it is necessarily implementation dependent. We all know that a specification is not enough to make a technology scale: implementations make technology scale.

    However, a specification can make a technology not-scaleable, because it fails to address (or it over-defines) certain points that turn out to be showstoppers in the real world.

    Once again, I'm not saying that JMX can't scale, my points are simply:

    1) I'll wait until we start seeing clustered app servers based on JMX scale as well as EJB's

    2) I still think the flexible nature of JMX is a red flag for scalability. You see the static nature of EJB deployment as a hindrance, I see it as a competitive edge that enables scaling

    --
    Cedric
    Reply to this Reply to original

  39. Out of topic - MBeans the next EJB killer...[ Go to top ]

    As to scaleability of EJBs:

    Basically the thousands of sites that's running hundreds of load-balanced nodes are scaled on the web-server/servlet/jsp level. Ie. you have a http-load-balancer, replicate the http-session state to fail-over nodes and none of the ejbs are distributed/load-balanced. I have yet to seen somebody do a succesful two-tier load-balanced architecture (ie. with the service/ejb-layer distributed and load-balanced). Well, you could do it and I've seen people do it, but for most applications there simply is no point.

    EJB has entirely different pros. It's a strict programming model which enforces the programmer to "do the right thing". This, oftenly (such as Entities and CMP), is on behalf of scaleability and performance. (Nothing is faster than assembler/machine code anyway so there's no need to argue. :-)
    Reply to this Reply to original

  40. Out of topic - MBeans the next EJB killer...[ Go to top ]



    Rickard,
    Do you think EJB's are not scalable? Earlier you mentioned that you would dump EJB - why is this?


    Cedric,
    "Queues are always non-durable, only Topics can be durable"
    Either I misunderstand what you have written or I dont agree with this - can you clarify what you mean?

    Reply to this Reply to original

  41. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Nick,
    RTFM ;) -> JMS spec 1.0.2 about durable subscriptions to JMS topics. . There is no need for P2P messaging model (JMS queue) to have durable subscriptions, beacuse there is only one concumer who receives message.
    Reply to this Reply to original

  42. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Nick,

    Yes, I think EJB's are scalable, but not due to some inherent feature of EJB but more due to things like connection pooling (which you can use without EJB's).

    Yes, I *have* dumped EJB's in my current project, and I'm very happy with the result. I can do many more interesting things, and the codebase size was significantly reduced. Lesser training issues too. As for the full alist of reasons why I did this, will have to wait as it's too big a topic for a simple forum post :-)

    regards,
      Rickard
    Reply to this Reply to original

  43. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Nick,

    Actually, let me restate regarding EJB scalability. They may be scalable upwards, but not really downwards. One of the gripes I have with EJB is runtime configurability. EJB's are configured through XML descriptors. These are in the package you deploy, such as an EAR file. If you want to update the settings in that file you will have to change the descriptor, repackage, and redeploy. This will take your entire system offline for awhile, during this upgrade, since EAR files are monolithic. For large EJB systems this is not a problem, since you can upgrade one cluster node at a time, and always have the system as a whole running. If you're using a one-server setup, it becomes worse though. I would guess that one-server setups are by far the most common, due to the inherent complexity introduced with clustering. For some time your entire app is going to be inaccessible. That's bad.

    If you instead use servlets+JavaBeans, or servlets+JMX, then you can define yourself how configuration is done, and thus be able to do changes at runtime without too much trouble.

    In this sense, and many others (development skills needed for example), EJB is not downwards scaleable, which I believe is a vital aspect of scalability as a concept.

    regards,
      Rickard
    Reply to this Reply to original

  44. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Hmm... Couldn't this non-dynamicity of deployment descriptors be solved by using the java.lang.reflect.Proxy-functionality in JDK1.3? Instead of generating code for containers, everything is implemented via proxys which only need to be reactivated to read the deployment descriptors again.
    Reply to this Reply to original

  45. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Rickard wrote:

    <quote>
    I would guess that one-server setups are by far the most common
    </quote>

    Wow. Could it be that your experience is a little tinted because since JBoss doesn't support clustering, all JBoss users you've ever talked to are all running on single machines?

    Be ready for a shock when you add clustering to JBoss...

    <quote>
    EJB is not downwards scaleable, which I believe is a vital aspect of scalability as a concept.
    </quote>

    The concept boggles the mind :-)

    I know that .coms are bombing and all, but I wouldn't go as far as saying they're going to sell machines from their clusters in order to cut down their costs :-)

    --
    Cedric
    very surprised
    Reply to this Reply to original

  46. Out of topic - MBeans the next EJB killer...[ Go to top ]


    Rickard,

    You are right, it is a big topic for a forum post. I'd be interested to discuss offline.

    I agree with a couple of your points regarding downward scalability and configuration (though, I would argue that the XML DD's are a compromise place for configuration - half way between hard-coding and using LDAP for truly dynamic config).

    For me the big advantage of EJB is that it is a well-known framework that your business-domain developers can work on. The less system code these guys write the better. Lets face it, the guys at IBM, BEA, Borland, JBOSS etc etc are more likely to know how to write system code than most of these developers (after all, thats how they make a living).

    On a different tack - I think I need to find out more about JMX. The usage you talk about doesnt fit with my (superficial) understanding of what JMX is for (administration). Do you have some good stuff you can point me to?

    Reply to this Reply to original

  47. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Nick,

    Re: configuration. IMHO using a dynamic way is better, since then you can either introduce caching techniques or use a push model to push the LDAP config out to whoever needs it. With a hard-coding strategy (such as the XML DD's represent) you have no way to update the config at runtime even if you wanted to.

    Plus, the multi-instance approach to session beans complicate things further. You more or less *have to* use a pull-method where each instance "pulls" the config from some repository, thus making it harder to update it since there's no active way to get the new config settings into the SB's.

    Re: well-known framework. I've found that it's a huge training issue. EJB is tough to learn, and not only API-wise, but conceptually. It's off-limits for a large number of people, just because of the inherent conceptual difficulties. Heck, I even see supposed gurus make statements about EJB showing they haven't understood things completely (myself included, yes ;-). Point in case: the biggest discussion on the EJB-INTEREST list right now is about state in stateless session beans, and you'll see many conflicting answers, although in some cases all are right depending on viewpoint. What's a simple developer to do? Sure, training sessions with TMC (for example) alleviate, but still. Advice gained through TSS also help. But still. I'm not convinced.

    Also, re: system code. Application servers are great at providing implementations of various system code things, such as transactions, pooling, remote access, etc. And that is truly a great win for any user of an application server. However, EJB is more of *a* way to access these API's than *the* way to access them. You can avoid EJB, and still make use of that system code that is available in an application server.

    Sometimes you also *want* access to the underlying system, in order to use it effectively. With EJB you are so tucked into a nice little cushioned environment that, while comfy, it can get annoyingly restricted. Again, point in case, the common discussions on the EJB-INTEREST list re: "I can't use file I/O!??!".

    Re: JMX. No, this is not how you'd view JMX ordinarily. However, compare with Jini that is supposed to be used to let toasters talk to each other. Is that how people are using Jini? Nope, and the same applies to JMX. It's a very interesting API, that can be applied in many different ways. The JBoss server uses it as the kernel, and not necessarily for administration purposes. Heck, JBoss doesn't even have a decent admin GUI yet, and is still one of the more interesting use-cases of JMX.

    And so on and so forth :-) Blah, too long for a forum post, but there you go :-)

    HTH

    /Rickard
    Reply to this Reply to original

  48. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Basically the reason that it is so difficult to learn EJB is that it simply is difficult building high-quality enterprise-systems. Actually it is very reassuring that you say that some people simply can't learn it, well, maybe they should find another profession. I would never learn how to do professional-level ice-skate-dancing, and, well, maybe I just shouldn't...

    EJB does do things more simple, for somebody who _already_ know how to write enterprise-systems.
    Reply to this Reply to original

  49. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Jon,

    Yes, it is difficult to write high-quality enterprise-systems. Does EJB make it as easy as possible? IMHO a definite no.

    I think more people would be able to write high-quality enterprise-systems if EJB wasn't designed that way it is, because it introduces complexities that IMHO are not really necessary. If those complexities weren't there it would allow more people to use it. To say "they should find another profession" is rather arrogant, and not really helpful.

    Also, for someone who *do know* how to write enterprise-systems, EJB is limiting since your hands are tied on so many points. You want to do things, you know how to do them, but there's just no way to do it. Is that a) good b) bad. *shrug*

    /Rickard
    Reply to this Reply to original

  50. Out of topic - MBeans the next EJB killer...[ Go to top ]



    Well there is some truth in the fact that there are people doing software development that shouldnt be. A lot were attracted to development for the money - rather than any aptitude. And to some extent, building enterprise systems is a specialist task - not suited to all developers.

    However, what unnecessaary complexity do you think could be removed from EJB to make it more accessible?
    Most of the limitations have good reason for being there, in my mind (though they do add up). The connector architecture is a good place to step out of the ejb model - for such things as file system access (should you want it).

    For me, the only thing missing is an in-memory-only transactional object like an entity bean that doesnt require a persistant store. However, perhaps the JCache JSR might give a comparable solution. Better integration with messaging is needed - but I am confident that this is coming anyway.

    Reply to this Reply to original

  51. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Rickard,

    In my experience EJB has worked very good in several projects. With the enhancements added with EJB 2.0 (which I have tried some, and some not) I expect it to be working even better.

    I do _not_ agree that EJB makes it more difficult for people that are competent in writing enterprise systems. On the contrary, it helps these people. For writing magical things "outside" the framework we now have connectors and with addition of interceptors we will have even more power. This is my opinion of course, based on the type of systems I have built and been in contact with in other ways (enterprise-level administrative web-based systems mostly in the field of b2b e-commerce). To this domain ejb has worked very well. You may have had experience of other systems where ejb has not been entirely suited.

    I _do_ agree that EJB makes it more difficult for people that are _not_ competent. (Compared to writing things in the naive way.) And I don't wish it to stay that way, but I don't think there is another way. There's no easy path to a high quality system, I've seen many failures to this.

    Of course, this is just opinions and I wish maybe I had a little more time to analyze the different aspects of EJB that makes it easier for the competent, and harder for the incompetent. To state my case better.
    Here are maybe some:
     - Maintenance of conversational state. The naive approach is to keep these as instance or class-variables. The http-session tracking and the SFSB makes this easier but are harder to use than instance/class-variables.
     - Persistence. The naive approach is to not have a domain-model and just write the sql and run it. Plain and simple. CMP makes it easier to maintain a real domain-model while still having the possibility to write more complex queries in sql outside the EB. Also maybe in J2EE1.3 EB with BMP and Connectors could be combined. Using CMP is fairly complex, BMP even more so.
     - Message-handling. The naive approach is to process and send messages synchronously. Just started to work with this but message-beans is very simple and yet so elegant, earlier using plain JMS was a real pain in the ass. Processing and sending message async is _very_ complex.
     - Distribution. Distribute everything in contrast to understanding the difference to distributed/non-distributed programming. EJB doesn't make it easier to design good distributed facades, if you do it wrong you're basically fucked. EJB does however make it easier to distribute and activate thing when you have made the correct design.
    I guess there may be more but this might be getting out of hand... :-)

    As for arrogance, it may have sounded a little bit arrogant and to that I am sorry, it was not my intent. I would have liked it to maybe sound a little bit more bitter. Working with enterprise development for quite some time and having a little bit of pride in the profession that one posess it gets a little bit depressing seeing people who have no interest in the profession and whose only in it for the money. Building these kinds of complex systems do take some dedication. This has changed now though, with the downturn of the economy. Problem is that now only experienced people (such as I) is kept while inexperienced people that may have had a genuine interest and talent are sacked. Hopefully when the economy goes up again we will have a more realistic view on this profession. (I am a strong believer of dialectics... :-)
    Reply to this Reply to original

  52. Out of topic - MBeans the next EJB killer...[ Go to top ]

    Indeed interesting experiments. Yes, when I looked at the JMX-model I did agree that it was a very elegant light-weight component framework in comparison to the very heavy model of ejb. I have also always considered languages such as Smalltalk and LISP-derivates (ie. Scheme) to be more appealing than syntax-savvy ones of C++/Java.

    The pro of lightweight frameworks/languages are that you are very flexible in how you can solve things. I do like that.

    The con of lightweight frameworks/languages is also that you are very flexible. In a large project spanning a long time (if you include maintenance) and a large number of people, flexilibity is almost always bad. A heavy framework does force all people to implement things in a more or less similar manner, which in these cases are a good thing.

    So, with a framework on top of JMX you can do all kinds of cool things such as declarative transactions etc. and when you went to do things that are out-of-scope to the framework you can always "step out of it" and still comply to the basic JMX-framework.

    With EJB there is for most situations a given way of doing things, for some situations that are out of scope you can do a little bit of magic but for most of these there is no way of doing it in EJB. (I've done some playing around with EJB2.0 though, and with the addition of messages-beans many things that were impossible previously now have very elegant solutions.)

    So, the two component-models are complimentary as they were went to be. EJB are ideal for large-scale enterprise _projects_ (note: I do not say _systems_) while JMX as you say may be a little bit more general purpose than it's original intent.
    Reply to this Reply to original

  53. Out of topic - MBeans the next EJB killer...[ Go to top ]

    I agree, typically you would build a simple framework that removes some of the flexibility of JMX, and introduces some rules. This makes it much easier to use, and makes code more similar and introduces patterns on how to do certain things.

    However, you can always bypass that framework and whatever you want, or build in bypass-point into the actual framework. I've done the latter, so that pieces of how things work can be replaced if necessary. This is the best option IMHO, and provides a nice blend between rigidity and flexibility.

    JMX without any rules/framework at all is too rough. You need at least rules for configuration, lifecycle, and inter-MBean communication/dependencies. But these are all one-shots that can be heavily reused.

    regards,
      Rickard
    Reply to this Reply to original

  54. HP gives away Bluestone J2EE Server for free[ Go to top ]

    JBoss won't break any 'new' ground. The simple fact is that WebLogic has been doing both object and application clustering for over three years. They even support statefull session bean failover automatically. New ground indeed...
    Reply to this Reply to original

  55. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Robert,

    The "new ground" comment was not about clustering, but the JMX support and features.

    /Rickard
    Reply to this Reply to original

  56. HP gives away Bluestone J2EE Server for free[ Go to top ]

    To answer your questions: J2EE 1.3: It implements almost of all of J2EE 1.3 except CSIV2. JMS: we bundle a non-durable, low end JMS. We will be shipping a fully durable and transactional JMS in early January as an add-on or stand alone, and this will be our own JMS implementation called HPMS. The full 2-phase commit is also available as an add-on. That means we ship only one phase commit in the base HP App Server.
    Reply to this Reply to original

  57. HP gives away Bluestone J2EE Server for free?!?!?!?[ Go to top ]

    Bob Bickel,

    "We will be shipping a fully durable and transactional JMS in early January as an add-on or stand alone, and this will be our own JMS implementation called HPMS. The full 2-phase commit is also available as an add-on. That means we ship only one phase commit in the base HP App Server."


    So... how much would the 2-phase commit add-on cost?

    I doubt anyone could run any enterprise applications with a 1-phase commit application unless if its just for pulling of simple data, which of course, jBoss could do very well.

    Also, what's HP's commitment to supporting current and future Web Services standards?? Would future versions be free as well?

    Thanks,
    Jason Ong
    Reply to this Reply to original

  58. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Yes, we think this is a significant move on our part. We are serious about this space. I think folks will really like this product when it ships the week of November 19.

    Bob Bickel
    HP Middleware
    Reply to this Reply to original

  59. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bob:
       Would you please elaborate on "If we get this free app server" what kind of support we can get? If you can add little bit more light on this interesting announcement then that will be a great help...

    Thanks
    Reji
    Reply to this Reply to original

  60. HP gives away Bluestone J2EE Server for free[ Go to top ]

    To answer a couple questions regarding price and packaging:

    - Support. There will be a listserv that will be free if you register. For enterprise support, we will charge for that, and make it like traditional 24X7 support coverage. We are expecting customers with critical environments will want to purchase this. I think the price is something like $3K per CPU.

    - JMS. We bundle a light version of Sonic, and will continue to have a partnership relationship with them. We will also be bundling our light JMS implementation in HPAS that is based on multicast, non-durable queues. Customers can also buy our HPMS at $1K per CPU that will have durability as well as transactionality. HPMS will not ship until January. Our implementation in HPAS makes it very easy to add other JMS vendors - we have tried out Softwired, Fiorano and Spiritsoft in the past.

    - Resilient Bundle. This includes HPMS. Also a persistent state server - HPAS comes with in memory state. Also a full 2-phase commit for transactioning. People sometimes get this confused - HPAS has full JTA/JTS support, but implements it as 1 phase. 1 phase is fine for a single data source (i.e. all my transactions are against Oracle), but 2-phase is for multiple back ends (I'm going against Oracle and SAP and I want to make it transactional). This resilient bundle costs $5K per cpu.

    Bob Bickel
    HP Middleware
    Reply to this Reply to original

  61. HP gives away Bluestone J2EE Server for free[ Go to top ]

    You can look at the spec sheets at http://www.hp.bluestone.com/products/hp-as/default.htm
    Reply to this Reply to original

  62. HP gives away Bluestone J2EE Server for free[ Go to top ]

    One more thing to be clear about. For CMP 2.0., we are working with Toplink, and bundling an evaluation version of that product.

    Bob Bickel
    HP Middleware
    Reply to this Reply to original

  63. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bob,

    AFAIK, Toplink is an alternative to CMP and CMR.
    Reply to this Reply to original

  64. HP gives away Bluestone J2EE Server for free[ Go to top ]

    tssstt..TopLink runtimes are only 6 grand a server...cash up front, but, if you're looking meaningful spending
    blips, there you have it. Why even say a server is
    free if folks are looking for meaningful spending blips?
    don't understand
    Reply to this Reply to original

  65. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bob -
    In other words, HPAS will not be implementing CMP/CMR and users will be required to purchase toplink in order to achieve that sort of functionality. Why was this decision made?

    Thanks
    Ray
    Reply to this Reply to original

  66. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bob Bickel wrote:

    <quote>
    We will also be bundling our light JMS implementation in HPAS that is based on multicast, non-durable queues.
    </quote>

    Queues are always non-durable, only Topics can be durable. I thought you might want to know if you're going to ship this :-)

    --
    Cedric
    Reply to this Reply to original

  67. HP gives away Bluestone J2EE Server for free[ Go to top ]

    I assume by durable Bob you mean persistent queues and durable topics?

    Are you supporting both?
    Reply to this Reply to original

  68. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bob Bickel (of HP Middleware fame):

    I hear that HP is discusssing potential co-marketing and sales initiatives around BEA WebLogic software offerings and HP OpenView management solutions (this was also reported in the trade rags).

    Looks like that "free" bluestone thing might just get yanked underneath you ...


    Reply to this Reply to original

  69. HP gives away Bluestone J2EE Server for free[ Go to top ]

    I think that at the end we will have 15K$ or 20K$ per CPU with these additional modules for HP-AS. So what is the point of free "ripped" version, just marketing trick ? ;)
    Reply to this Reply to original

  70. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Giedrius,

    "I think that at the end we will have 15K$ or 20K$ per CPU with these additional modules for HP-AS. So what is the point of free "ripped" version, just marketing trick ? ;)"


    Like I've commented earlier on, I don't think it's the 15-20K that you should be worried about, spending on those modules. It's the 150-200K that you might end up spending on HP global services to get your enterprise solutions up and running...

    =]
    Reply to this Reply to original

  71. HP gives away Bluestone J2EE Server for free[ Go to top ]

    register HP-AS :
    http://www.bluestone.com/products/hp-as/default.htm
    HP-AS is expected to ship November 19th, 2001.
    Reply to this Reply to original

  72. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Isn't this in a sense "dumping".
    Reply to this Reply to original

  73. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Isn't this in a sense "dumping".


    No, this is a demonstration of the highest level of commitment to the J2EE platform and community.

    By providing the means to extend the basic operating system to the Internet Operating Environment at as low a cost as possible - HP is enabling the J2EE community with the means to innovate above the application server.

    The Internet Operating Environment is the platform that enables innovation of current and future technolgies - bridging the gap of .NET and J2EE, powering web services and peer to peer applications and leveraging the investment companies and developers have made in J2EE.

    We look forward to continuing development and support of the HP AS as well as contributing to the evolution of J2EE through the JCP.

    I am personally very proud of this product and and excited to see it embraced by the developer, OEM/ISV and corporate environments.

    Enjoy.
    Reply to this Reply to original

  74. HP gives away Bluestone J2EE Server for free[ Go to top ]


    Sounds like a desperate attempt to enter the market...

    Also, you may be getting the app server for free but the amount invested in HP Global Services is going to amount up to something costing between building a beach-front mansion along Florida Beach to the price of a nuclear warhead.

    Pay attention to the TOTAL COST of the project.

    I'm sure we've all learnt our lessons from the Global Services arms of other vendors.



    Reply to this Reply to original

  75. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Exactly what are they giving away? The web site says that it will not support guaranteed messaging.
    Reply to this Reply to original

  76. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Rickard,

    You are right, you should be glad to be wrong.
    It is very human to be wrong.
    An opposite to being wrong is being an icon.

    Icons are crafted and imposed perceptions.

    Your serverside video looked very much like you are being iconized :) After watching it, I have read this Bluestone converstation and was relieved to learn that you are quite human indeed. Thanks God! Ha-ha:)

    Viktor

    Reply to this Reply to original

  77. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Viktor,

    Thanks for noticing :-) IMHO, such imposed perceptions are often crafted by others than oneself (this being one of those cases), and if you're not careful you might buy into it yourself. I have tried as hard as possible to avoid buying into my own icon status, which I believe is the only way you can stay focused and be able to cut through your own crap, so to speak ;-)

    Keep pointing out when I'm wrong, and I'll try to do the same :-)

    regards,
      R
    Reply to this Reply to original

  78. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Bob (from HP)

    You mention that you will be supplying your own JMS provider (HPMS). Will this really be your own or are you just OEM'ing SonicMQ?

    If it is your own what are you going to do about transactionally driving message driven beans using foreign providers (using CMT). The J2EE specifications do not cover this and so it seems each app server vendor is creating their own propritary interfaces. What will you be doing?

    Will you have your own persistence manager or will you be OEM'ing this?

    Do you have full CMP 2.0 support, including CMR, local interfaces and message driven beans?

    If I have an MDB that needs to write information to a database atomically with the message receipt how will I achieve this using HPAS/Bluestone?
    Reply to this Reply to original

  79. HP gives away Bluestone J2EE Server for free[ Go to top ]

    The JMS specification does specify an interface for participation in global transactions, but it is unfortunately broken. We have an abstraction layer that allows us to integrate with the XA capabilities of Sonic, whom we are presently shipping with. Extending it to other JMS implementations (including our own) should be straightforward.

    I'm surprised by the consternation over full XA support in JMS considering that no major JMS vendor supplied this functionality a few months ago. In any case, it's an issue we've already dealt with at a technical level.

    Greg
    Reply to this Reply to original

  80. HP gives away Bluestone J2EE Server for free[ Go to top ]

    doesn't mqseries provide full xa support?
    Reply to this Reply to original

  81. HP gives away Bluestone J2EE Server for free[ Go to top ]

    Greg,

    As I understand it, most JMS providers do not have transaction managers and so cannot start a transaction before sending a message to a destination that an MDB listens to. This means that an MDB listener cannot include the message receipt/ack in the same transaction as any other work that the MDB does (for exmaple using an entity bean).

    The work around is to have the message receipt rettrospectively injected with the transaction context but this is not defined in the J2EE specifications. If it is please enlighten me.

    To get around this WebLogic have come up with the MDBTransaction interface, and foreign JMS providers must implement this in order for the WebLogic transaction manager to inject the transaction context.

    Because J2EE does not cover this area, each app server vendor could potentially come up with a proprietary solution and this creates a nightmare for the JMS providers.

    If you are looking to support a range of JMS providers then this is a problem.

    Can you direct me to the JMS spec section that discusses this issue, and then tell me why it is broken.

    Thanks
    Reply to this Reply to original