Y2MJI: Yet 2 More JBoss Interviews

Discussions

News: Y2MJI: Yet 2 More JBoss Interviews

  1. Y2MJI: Yet 2 More JBoss Interviews (69 messages)

    Two more interviews have been published this week about JBoss. "The bottom line there is that Sun doesn't really want to acknowledge that a compliant app server is free." said Marc Fleury in a CNET interview. OETrends interviewed Sun's Rick Saletta who said "What JBoss is doing gives me heartburn."

    Read Behind the story at JBoss (CNet interview with Fleury).

    Read Open Source, J2EE Voices Ask If Success is Spoiling JBoss (OETrends interview with Saletta).

    Is more evidence needed that they should pay the Tab for J2EE Compliance?, "Sun doesn't really want to acknowledge that a compliant app server is free", well obviously if you don't pay them thay dont have to Certify you, after all they want the same cake IBM, BEA, and Oracle are after: $$$

    Threaded Messages (69)

  2. Recent related TSS news threads:
    JBoss Unveils Profit Sharing
    Sun and JBoss "in talks" over J2EE 1.4 Licensing
  3. JBOss is yet another business with a different Business Model.

    JBoss will certainly change the Appserver Market and i guess the IBM's and BEA's will have to rely more on Services and pretty much give the Appserver free.

    Maybe , the Appserver development might go the route of IDE's . (Eclipse and netbeans).
  4. Saletta: There are J2EE methods they've chosen not to implement.

    OET: Which methods? What is the impact on developers of these non-standard methods in JBoss?

    Saletta: There are two methods I am aware of to date: One is: the javax.resource.cci.InteractionSpec fails to extend the interface java.io.Serializable. Two, additional methods [JBoss has implemented] in the Java Mail API lead to failures.

    Me: OH THE HORRORS! PANIC! I certainly haven't witnessed such blatant spec breakage from any other J2EE vendors, ever!

    /T
  5. Y2MJI: Yet 2 More JBoss Interviews[ Go to top ]

    McNealy should fire this guy, and his boss for the strategy. I wholly agree, what a joke. Get off the fence and do something about it that is "real" to the umpteenth thousands of developers that are making their bread and butter on Java and Java technology. This is starting to sound slimy from Sun's part (JMHO), sort of like the "solaris on intel, no wait, oh ok, solaris on intel", "sun linux, no wait, ok, no more sun linux". If the Sun brand app servers are on par (quality wise) as others, what is their to be afraid of? The lingering stench from the kiva iplanet debacle I would imagine.
  6. Rick Saletta interview[ Go to top ]

    McNealy should fire this guy, and his boss for the strategy.


    I think the rot starts with McNealy himself. His entire worldview on J2EE vs. .NET is all wrong, and we in the Java world are going to pay dearly for it.

    Basically, McNealy believes that to fight .NET, you need a large marketing budget, and the only way that J2EE vendors can afford that budget is by being able to charge big bucks for their app servers. Following this logic, Open Source products like JBoss are hindering the ability of J2EE to compete against .NET by deflating the app server market.

    But he's wrong, all wrong! And I'm amazed that he doesn't see it even after the successes of Apache, Linux and even Tomcat. Open Source is spreading like wildfire and nothing can stop its advance. His Solaris salesmen must be giving him more bad news each passing day.

    The truth is -- Open Source J2EE is the one that will stop .NET, not "Open Wallet" J2EE. If Sun is concerned about the larger battle between J2EE and .NET, it should quickly get behind the weapon with the greatest chance of success against .NET.

    Sun should support JBoss. Not passively, not on an equal basis vis-a-vis the commercial app servers, but actively, by elevating JBoss to the status of the J2EE reference implementation! They should make another Tomcat out of JBoss, and market it like hell!

    If JBoss fails to pass the J2EE certification, Sun should take it as their problem, not the problem of the JBoss Group LLC, because it really is their problem if the greatest weapon in the J2EE camp is not upto scratch.

    My advice to Rick Saletta is to forget the JBoss Group and think about Microsoft. If he thinks about Microsoft day in and day out, the way Microsoft surely thinks about all their competitors, he will see with blinding clarity what needs to be done w.r.t. JBoss.

    We want the world to remain a Java world, and not succumb to the closed and insidious Microsoft influence. I hope the thousands of Java developers out there do not have to pay a high price for Sun's continued blindness.

    Ganesh Prasad
    Independent Java Developer
    Sun Certified Programmer for Java 2
    Sun Certified Web Component Developer for J2EE
  7. Rot starts with McNealy?[ Go to top ]

    I think the rot starts with McNealy himself. His entire worldview on J2EE vs.

    > .NET is all wrong, and we in the Java world are going to pay dearly for it.

    > Basically, McNealy believes that to fight .NET, you need a large marketing
    > budget, and the only way that J2EE vendors can afford that budget is by being
    > able to charge big bucks for their app servers. Following this logic, Open
    > Source products like JBoss are hindering the ability of J2EE to compete against
    > .NET by deflating the app server market.

    Then why does Sun itself offer a free J2EE app server? And why did it force other vendors such as IBM and BEA to recently reduce prices through its own aggressive pricing? In fact McNealy probably knows that they won't be able to (or maybe just won't) outspend MS in marketing against .NET and that the way to win the battle is to offer choice and value - ie. free or inexpensive.

    > But he's wrong, all wrong! And I'm amazed that he doesn't see it even after the
    > successes of Apache, Linux and even Tomcat. Open Source is spreading like
    > wildfire and nothing can stop its advance. His Solaris salesmen must be giving
    > him more bad news each passing day.

    Funny thing is, Solaris ships with a bunch of open source software, including Apache. Why would Sun do that if McNealy viewed open source as bad for business?

    > The truth is -- Open Source J2EE is the one that will stop .NET, not "Open
    > Wallet" J2EE. If Sun is concerned about the larger battle between J2EE and .NET,
    > it should quickly get behind the weapon with the greatest chance of success
    > against .NET.

    Sun's position on open source is that it gives customers a choice and a reference point to keep Sun and other vendors honest. If a commercial product does not offer sufficient value above that available to the customer from an open source alternative, then the customer will choose the open source option. You can see this scenario with Sun's products: Open Office vs Star Office, Netbeans vs. Sun ONE Studio, Apache/Tomcat/JBoss vs Sun ONE App Server, Apache vs Sun ONE Web Server.

    Have you got any arguments to support your assertion that open source J2EE is the only or best way to stop .NET? (BTW: I doubt that Sun or even McNealy would have a goal of "stopping" .NET. Just getting a fair share of the market should be enough.)

    > Sun should support JBoss. Not passively, not on an equal basis vis-a-vis the
    > commercial app servers, but actively, by elevating JBoss to the status of the
    > J2EE reference implementation! They should make another Tomcat out of JBoss, and
    > market it like hell!

    Why should Sun market a product that it makes no money on and which doesn't help sell Sun products and services?

    > If JBoss fails to pass the J2EE certification, Sun should take it as their
    > problem, not the problem of the JBoss Group LLC, because it really is their
    > problem if the greatest weapon in the J2EE camp is not upto scratch.

    No, it's not Sun's problem.

    > My advice to Rick Saletta is to forget the JBoss Group and think about
    > Microsoft. If he thinks about Microsoft day in and day out, the way Microsoft
    > surely thinks about all their competitors, he will see with blinding clarity
    > what needs to be done w.r.t. JBoss.

    According to tghe article, Saletta is Group Marketing Manager for J2EE Licensing, not Chief Competitive Officer. How do you think he could do better by Sun and the J2EE community by thinking about Microsoft "day in and day out"?

    > We want the world to remain a Java world, and not succumb to the closed and
    > insidious Microsoft influence. I hope the thousands of Java developers out there
    > do not have to pay a high price for Sun's continued blindness.

    Are you suggesting that if Sun doesn't "adopt" JBoss, all the Java developers will flee into Microsoft's arms? I don't think so.
  8. Rot starts with McNealy?[ Go to top ]

    Just a thought, anyone who has used iplanet application server in the past already has a bad taste in their mouth for sun app server's. Not to say that sun one is the same, but the perception has already been laid down, and it would have served Sun much better to have an application server product ready to go from the beginning that was better than the reference implementation. That said, I don't think that Sun has had a choice in bundling open source software, and I don't think that they had a choice in offering free "versions" of their product (not the full blown clustering version, at least I don't think), for the same reason that they pulled back on bundling their own distribution o Linux.

    All I am trying to say, is that its an uphill battle in many respects in perception, at least for me and other developers that I talk to, and it is this perception that will cause a great amount of harm to the company.
  9. Re: Rot starts with McNealy?[ Go to top ]

    Stephen,

    You said:

    > Then why does Sun itself offer a free J2EE app server? And why did it force other vendors such as IBM and BEA to recently reduce prices through its own aggressive pricing? In fact McNealy probably knows that they won't be able to (or maybe just won't) outspend MS in marketing against .NET and that the way to win the battle is to offer choice and value - ie. free or inexpensive.
    [...]
    >Funny thing is, Solaris ships with a bunch of open source software, including Apache. Why would Sun do that if McNealy viewed open source as bad for business?

    I'll let you hear my rebuttal from the horse's mouth. Here's an excerpt from a Scott McNealy interview:

    http://www.oetrends.com/cgi-bin/page_display.cgi?77

    "So, potentially you could make an argument that the open source thing is just screwing up all the revenue models and we aren't getting the advertising, because it isn't the best technology that always wins, it's who advertises more. You could make a very strong argument that says, "No that's messing with it." And in fact Bill Gates may be sitting up there laughing his butt off because the open source community is cutting the legs out from under all the R&D and promotion efforts of all the open interface strategies -- not open implementation, but open interface strategies."

    The guy really believes Open Source is getting in the way of J2EE's competitive ability vis-a-vis .NET. He believes that J2EE app server vendors must have the revenues to support a huge advertising campaign against Microsoft. He believes that can only come if Open Source doesn't "cut the legs out" from under them by lowering prices.

    I haven't misinterpreted McNealy. In fact, he couldn't have stated his position more clearly. And I think he's absolutely wrong.

    You also said:

    > Sun's position on open source is that it gives customers a choice and a reference point to keep Sun and other vendors honest. If a commercial product does not offer sufficient value above that available to the customer from an open source alternative, then the customer will choose the open source option. You can see this scenario with Sun's products: Open Office vs Star Office, Netbeans vs. Sun ONE Studio, Apache/Tomcat/JBoss vs Sun ONE App Server, Apache vs Sun ONE Web Server.

    Do you have any basis for your statement? Have they said so anywhere? My position is based on a very clear quote from McNealy which spelt out his thinking, which I believe is utterly misguided.

    Yes, I reiterate my position that the rot starts with McNealy and he will end up doing the Java community a great deal of damage.

    You also said:

    > Have you got any arguments to support your assertion that open source J2EE is the only or best way to stop .NET? (BTW: I doubt that Sun or even McNealy would have a goal of "stopping" .NET. Just getting a fair share of the market should be enough.)

    As an independent contractor who has worked with some very large companies in Australia, I know that these companies are going with .NET for "tactical, non-mission-critical" applications even though their official architecture strategy says J2EE. The reasons given are cost and productivity. Open Source Java yields both benefits (cost benefits are obvious; re. productivity, think Ant and xDoclet). This is purely anecdotal, I agree, but that's why I think Open Source J2EE has the best chance of stopping .NET.

    And as for a definition of what a "fair share" of a market is, it's sobering to remember this famous quote from Mike Maples of Microsoft:

    "My job is to get a fair share of the software applications, and to me that's 100 percent!" (Do a Google search if you think I'm making this up)

    If you understand Microsoft's mentality, you will also understand why they need to be stopped.

    You also said (in response to my statement below):

    >> If JBoss fails to pass the J2EE certification, Sun should take it as their
    >> problem, not the problem of the JBoss Group LLC, because it really is their
    >> problem if the greatest weapon in the J2EE camp is not upto scratch.

    >No, it's not Sun's problem.

    Well it is, unfortunately. If Sun doesn't mind retiring from the contest and leaving the app server market dominated by .NET, then I agree with you. However, I don't think anyne at Sun, or any Java developer, wants to see that happen. It *is* Sun's problem. Whether they wake up in time to realise it is another matter.

    Finally, you said,

    > Are you suggesting that if Sun doesn't "adopt" JBoss, all the Java developers will flee into Microsoft's arms? I don't think so.

    Not as a direct consequence, but if Sun bungles the J2EE-.NET battle and Microsoft gains a significant share of the market, you will see significant Java programmers follow the money and (perhaps reluctantly) migrate to C# and .NET. Wouldn't you?

    Regards,
    Ganesh Prasad
  10. Well Said[ Go to top ]

    Sun should support JBoss. Not passively, not on an equal basis vis-a-vis the commercial app servers, but actively, by elevating JBoss to the status of the J2EE reference implementation! They should make another Tomcat out of JBoss, and market it like hell!


    Well said. This is the day to day reality. Project budgets are very tight in the UK at the moment and being able to offer a client a low cost high quality application acrhitecture instead of the usual Microsoft nonsense makes sense. If Sun gave their badge of approval JBoss would be the defacto standard. A high quality open-source application server with approval from a known vendor.

    Then Sun et al. could get on with marketing the less generic and more specialised products required by larger organisations. We take Apache for granted these days; soon I feel we will think the same way with JBoss. They could then move on to the higher levels of complexity we face not keep battling out on this low-lying playing fields of the J2EE spec.
  11. Back up your acussation[ Go to top ]

    Thomas,

    I only know of one instance where an app server vendor clearly doesn't follow the spec, but this could well be a mistake (JMS transacted sessions should be ignored in the context of a JTA transaction but as of WLS 6.1sp3 transacted sessions ran in isolation from JTA). There are many instances where the Sun specifications do not go far enough, leaving vendors to implement the way they see best.

    I'd be very interested to hear about methods, for example, that app servers have not supported, that you are referring to. How have they cleared certification?

    Aaron
  12. Back up your acussation[ Go to top ]

    Aaron,

      The pre-release version of Sun One Application Server was J2EE 1.3 certified. It did not implement commit-option A in its Entity Beans. This is a far more egregious violation of the spec than the piddling issues that Saletta raises, and destroys performance on enterprise systems. It also establishes without a doubt that:

    1) The compatibility test does not verify basic elements of compatibility; or
    2) Vendors lie when they self-report their results.

    I can not prove it, but external evidence leads me to believe that both of these are true. Either way, it's hard to argue that JBoss has done more damage to J2EE compatibility than Sun has with a shoddy certification process.
  13. Commit options are not mandatory[ Go to top ]

    <em>
    The pre-release version of Sun One Application Server was J2EE 1.3 certified. It did not implement commit-option A in its Entity Beans.
    </em>

    The specification doesn't mandate the implementation of either commit option, so not implementing one of them doesn't make you non-compliant.

    --
    Cedric
    http://beust.com/weblog
  14. Saletta: There are two methods I am aware of to date: One is: the

    > javax.resource.cci.InteractionSpec fails to extend the interface
    > java.io.Serializable. Two, additional methods [JBoss has implemented]
    > in the Java Mail API lead to failures.
    >
    > Me: OH THE HORRORS! PANIC! I certainly haven't witnessed such blatant
    > spec breakage from any other J2EE vendors, ever!

    Yeah, those are some pretty pathetic examples. However, we've actually gotten hit with the Javamail differences with our application, and it sucked. Anytime appserver behave differently, it's a major pain in the butt. :(

    -Matt
  15. War is On[ Go to top ]

    This is a declaration of war from Sun. Saletta does not specifically threaten legal action against JBoss. But he used the magic words. He said JBoss is misusing the J2EE trademark.

    Under US intellectual property law, you are REQUIRED to defend trademark infringements, or else the trademark passes into the public domain.

    Since I don't believe Sun is ready to relinquish all rights to the J2EE trademark, this means they ARE preparing to bring the hammer down on the JBoss Group.
  16. Saletta: A large number of JBoss customers and members of the media and developers do not realize that JBoss is not J2EE compatible.

    Interesting... a large number of JBoss' customers (presumably including the paying ones) aren't aware that JBoss isn't compatible? What this tells me is that, as far as they can tell, it IS compatible.

    I think any J2EE developer who's been in the game for a while can point at version X of app server X that didn't behave according to the spec. There's 2 different issues here, but Sun seems to want to make them the same - compliance and certification. Compliance indicates that the product functions in accordance with the published specifications it is claiming. The second issue is certification, which indicates that a product was been ceritified by Sun as compliant.

    I believe the reason Sun has, thus far, resorted to threats rather than legal action is that they would have a hard time proving that JBoss is less compliant than products that Sun has put their stamp of approval on. Unless JBoss is materially less compliant than the worst of the bunch, they're not causing any damage to Sun other than keeping the annual six-figure check for the TCK in their own bank account instead of Sun's.
  17. Compliance VS Certification[ Go to top ]

    I have used JBoss, Weblogic, iPlanet, and WebSphere. ALl of which are J2EE compliant, but not all of which are certified. If I am correct, WebSphere 3.5 was not certified. To me, JBoss is the most compliant of all the app servers. Why? They have the least to lose. They do not need to write proprietary hooks into their app server to keep people around.

    Let's take a poll, which is the most J2EE 1.3 compliant app server you have used?
  18. Compliance VS Certification poll[ Go to top ]

    Currently using JBoss, Weblogic. Same app, different app servers, no probs.

    Getting tired of the BS coming out of Sun. I could care less about certification because I can quickly see if my apps work on a paticular server. Also managing my department, I'm able to make the calls on which app servers we go with.

    For some I image, trying to justify the lack of certification to higher ups could be a prob. Thank god it's not my prob. :0

    Ben
  19. OpenSource software= Frankenstain[ Go to top ]

    JBOSS is gonna kill the J2ee someday. Open source software shall bring the software industry down.

    Remember that the people who contribute to open source have got their skills working on commercial software.

    If there are no commericial software left there would not be any free software.
  20. OpenSource software= Frankenstain....[ Go to top ]

    Come on man, are you serious. Look at the net, without free software like TCP/IP, Perl, Apache, PHP, Tomcat, JBoss, etc, would the net even exist? Wake up and realize that JBOss is not going to kill J2EE it is merely the new J2EE that does not let the massive standards body bog down the innovation. CORBA went the same way, it is natural once standards bodies become too large. They can no longer innovate.
  21. OpenSource software= Frankenstain[ Go to top ]

    " JBOSS is gonna kill the J2ee someday."

    I hope this turns out to be right. If it does, then it's a good thing. Here's why:

    What is the purpose of a standard? To avoid vendor lock-in. To provide an exit strategy. What is the purpose of the GPL? To ensure that no exit strategy is ever needed. Therefore, a spec like J2EE can be effectively be replaced by a GPL'd app server that does the same things in a different way.

    There are many examples where this happened. For example, ANSI C is a standard. But most people will just use gcc, which compiles for 100 different architectures. At this point, who cares if you use gcc-specific extensions of C? The gcc compiler will always be available to you.

    Therefore, a standard is good, but a GPL'd project is better.

    Guglielmo
  22. Gugliemo-
    Don't you see that's the JBoss strategy.
    The reason why that's wrong is the reason why C is not used in the enterprises anymore.
    J2EE standard is not just a runtime standard alone it's the ability to reuse these skills and mind-share across enterprises.
    When I learn J2EE, I expect to reuse my knowledge across different app servers and not just JBoss.
    If JBoss really want to innovate why not participate in JCP and help J2EE efforts. It will be beneficial to everybody.

    -Raj
  23. I don't think Jboss is gonna kill J2ee[ Go to top ]

    You can see some examples.Takeing mysql as an example,it exist with oracle,db2,at the same time.
  24. Beyond J2EE[ Go to top ]

    Jboss is building the app server of the future. J2EE is there bread and butter, but what they are building now is a new paradigm based on their AOP framework. I wonder how long it would take the spec writers to come up with this. J2EE applied to POJO's. Can't wait to take it for a spin. I think this is what is scary to Sun. Jboss has hit critical mass and Sun is afraid they will decide they don't need the spec anymore. We shall see. I love competition!

    tx

    Matt
  25. Embrace, Extend and Exterminate[ Go to top ]

    <matt>
    Jboss is building the app server of the future. J2EE is there bread and butter, but what they are building now is a new paradigm based on their AOP framework. I wonder how long it would take the spec writers to come up with this. J2EE applied to POJO's. Can't wait to take it for a spin. I think this is what is scary to Sun. Jboss has hit critical mass and Sun is afraid they will decide they don't need the spec anymore. We shall see. I love competition!
    </matt>

    It's called embrace, extend and exterminate and when Microsoft has tried to do it in the past they've been rightly condemned.

    If JBoss guarantee to implement the whole of J2EE then it's fine with me if they do all their neat AOP/POJO magic on top. But if they take a "pick and choose" approach to J2EE then I'd recommend current JBoss users consider their exit strategy. Other containers may not be free but there is much more competition now at the low end and any vendor worth their salt is adding real value on top, not just trying to impress fellow hackers with neat coding tricks.

    The cost of following JBoss Group on their fool's errand of preferring cool coding to providing guarantees of basic core functionality (web services support, IIOP) and correct J2EE behaviour (class loading semantics, parameter passing semantics, decent JMS) could be very high in the long run. I like and use JBoss, but if they can't support J2EE fully then I'll move on.

    Ian.
  26. Being based on J2EE is our bread and butter. Its why most people initially come to JBoss. We will continue to follow the specs religiously.

    AOP + EJB:

    For JB4, the average every-day J2EE developer won't notice anything. But, implementing EJB in terms of the AOP framework will greatly enhance the abilities of ISV's, system integrators, and third-party tool vendors to tightly integrate with JBoss.

    How?

    1) The JBoss 3.x series has some limitations in regard to interceptor chains and configuration. Sure, you can add new interceptors easily to container configurations, but, if you want to add any time of configuration, you have to modify JBoss code. AOP will provide a pluggable mechanism for those who want to extend JBoss configuration. Basically, interceptors and their configuration will be formalized into a packaged format. You'll be able to deploy extensions to the EJB framework in much the same way you deploy a SAR, WAR, EAR, RAR, etc....

    2) The AOP framework will also give third-party integrators the ability to actually expand the EJB API. For instance, if a distributed caching vendor wanted to provide a Caching API to every EJB deployed they could easily do it as a deployed package. Users will be able to use these new API's simply by typecasting:

    {
       MyEJB ejb = home.create();
       CacheAPI cachedObj = (CacheAPI)ejb;
       cachedObj.flushCache();
    }

    3) In JB4, metadata/configuration will be resolved through the context of the Invocation enabling interceptors to override existing configuration on one side, or to provide default configuration values cross-cluster.

    IMHO, these features alone will make JBoss the preferred platform for ISV integration since they will so easily, completely, and tightly be able to integrate their products with all aspects of JBoss.


    New AOP Services: Beyond J2EE

    Now for beyond J2EE, we're also doing some very cool things. IMO, Aspect Oriented Programming is the next big wave on par of what OOP did to functional programming. One of our main goals is to totally isolate infrastructure from business logic by providing system-level aspects for: security, transaction demarcation, caching, ACIDity, remoteness, clustering, and persistence. This means you can write plain old Java classes and either statically or dynamically apply these types of aspects making your business logic totally INDEPENDENT of any system level API's. This is a grand departure from following specifications like CORBA or J2EE in that these standards create specification lock-in.

    AOP gives us other advantages as well by being able to dynamically attach behavior to any type of object at runtime. Need to dynamically monitor a specific object for debugging purposes? Deploy and aspect at runtime. Need to expand the scope of a system-level aspect? Write your own interceptor. Need to apply your own system-wide proprietary API? AOP will provide you with the hooks.

    Our new AOP framework and services, also, IMHO, take you beyond J2EE where J2EE fails or is inflexible. For instance, the J2EE specification really has no concrete concept or definition of caching or ACIDity.

    Conclusion:

    We are strictly adhering to the new J2EE 1.4 and EJB 2.1 specifications. J2EE is a fine and good specification and JBoss will remain J2EE based. The new AOP framework will allow JBoss extension writers better and tighter integration with EJB and the rest of the JBoss core. The AOP framework and AOP services will take developers beyond J2EE to simplify application development and provide services where J2EE leaves off. Development with JBoss AOP finally allows business logic to be totally INDEPENDENT of system-level infrastructure.

    Regards,

    XXXXXXXXXXXXXXXX
    Bill Burke
    Chief Architect
    JBoss Group, LLC
    XXXXXXXXXXXXXXXX
  27. <Bill>
    We are strictly adhering to the new J2EE 1.4 and EJB 2.1 specifications. J2EE is a fine and good specification and JBoss will remain J2EE based. The new AOP framework will allow JBoss extension writers better and tighter integration with EJB and the rest of the JBoss core. The AOP framework and AOP services will take developers beyond J2EE to simplify application development and provide services where J2EE leaves off. Development with JBoss AOP finally allows business logic to be totally INDEPENDENT of system-level infrastructure.
    </Bill>

    It's good to hear such a clear statement of compliance from JBoss Group. Of course, Marc Fleury has said recently (don't ask where - I couldn't find the reference) that JBoss Group were going to implement J2EE 1.4 but not the web services part. Maybe they've had a change of heart.

    But we're still left with the fact that JBoss sometimes passes by reference when it should be passing by value, has its own classloading semantics and probably has many other minor deviations from the spec. These things count because they cause software to fail. Standards are important and checking compliance with standards is important. When the next great open source app server comes along that does J2EE better than JBoss do you want to be stuck? When you find that JBoss is not the "best" container for your particular set of circumstances do you want heavy porting costs because you used lots of JBoss-isms? Personally, I do not.

    Ian.
  28. Penny pinching[ Go to top ]

    <Saletta>
    The truth of the matter is if JBoss were to become J2EE compatible, that would in no way increase a revenue stream to Sun Microsystems. It would prevent fragmentation in the Java community, and that's what we're trying to protect. There is no money to be made from this [for Sun].
    </Saletta>

    <Saletta>
    Let's say you did start your own Open Source company, and Sun makes you an offer on something we sell for 20-30x. We make an offer [to you] at X or 2X; you don't want those terms to float to the public.
    </Saletta>

    i guess all the chaos emerge from the single fact that the supposed licensing price for the TCK is too heavy for JBoss. i dont believe that JBoss is being offered the offer at 10 or 20 times less the normal price, as saletta says.
    So either Sun doesnt accept JBoss as a open source effort, or it is a challenge to JBoss to prove that it actually is denting BEA or IBM's profits. and i think it is more on these lines as saletta mentions twice or thrice in the interview.
    lack of transparency in no way suggests that Sun is doing a favour to the open source community. If that would hv been so, then there would be a lot of "certified" open source appservers. leave JBoss, can Sun even name any other open source appserver it has convinced to get certiied?
    while compliance is a basic need,certification is always better, and any so called compliant product should hv no problem in passin the tests.
    and as far as the open source debate goes, i think, companies are even making quite good money selling the free linux-think Redhat or Suse.
  29. Double standard[ Go to top ]

    What's different about what JBoss is doing from what Microsoft did? It's not like JBoss is a non-profit pure OSS company. And from _my_ perspective, splintering J2EE is probably more harmful than splintering Java.

    Sun is suing Microsoft for $1B and is also suing them to include Java in every future shipment of Windows, including Windows Update service--to pay for the "irreperable" harm Microsoft did to Java by not implementing 100% of the spec or adding their own extensions.

    So, this is what I understand their policy to be: If somebody doesn't conform, but claims to be compatible, only sue them if they are unpopular with the community or with Scott McNealy; otherwise negotiate and go the diplomatic route.
  30. JBoss is Microsoft Wannabe[ Go to top ]

    Now where have I heard this before ???

    So let me get this straight: you are smarter than all Standards comitteee members, standards stifle your innovation etc. etc. You started out with a product that was a knock-off of an existing product and now you are going to make these additions that are not standards compliant yet so attractive for developers that they would not mind making non-standards compliant bindings to their source.


    Congratulations -- you have earned yourself an MBA from the Bill Gates School of (evil) Business.

    I wish Apache would adopt JONAS
  31. JBoss is Microsoft Wannabe[ Go to top ]

    Thats an idea, but dont they have openejb or something?

    I am in the process of learning JOnAS, and I really like the design.
    However I am surprised that it is so quiet on the JOnAS side, i.e eclipse
    plugins (any recent update?) and to JOnAS related stuff/technics.

    Why this hoopla with JBoss but not with JOnAS??
  32. Embrace, Extend and Aproximate[ Go to top ]

    XXXXXXXXXXXXXXXX
    Bill Burke
    Chief Architect
    JBoss Group, LLC
    XXXXXXXXXXXXXXXX

    Perhaps off-topic, and certainly not intended to influence the direction of the conversation, but Bill, you accidentally forgot to log out as "j2ee master" and log back in as "bill burke". Or perhaps you were just using Mr. Master's computer? ;-)

    I was curious who was giving those poor Iona chaps a hard time.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  33. Embrace, Extend and Aproximate[ Go to top ]

    Cameron read the titles to the posts as well.

    J2EE Master title <quote>Embrace, Extend and Exterminate - found this on JBoss Dev </quote>

    I guess J2ee master pulled it off of Jboss dev.

    tx

    Matt
  34. Embrace, Extend and Retract[ Go to top ]

    Matt: Cameron read the titles to the posts as well.

    Doh! It would appear that the mythical "j2ee master" has eluded our grasp again. (He would've gotten away with it too, if it weren't for those meddling kids ....)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  35. Embrace, Extend and Retract[ Go to top ]

    Shaaaaaaaaaaaaaaaggy?
  36. I am not Bill Burke.....[ Go to top ]

    I am not Bill Burke, I merely found that post of his on the JBoss Dev mailing list. Bill did not forget to log out. Once again, I am not Bill Burke, but wish I had the programming aptidute he does.
  37. no alias[ Go to top ]

    XXXXXXXXXXXXXXXX

    > Bill Burke
    > Chief Architect
    > JBoss Group, LLC
    > XXXXXXXXXXXXXXXX
    >
    > Perhaps off-topic, and certainly not intended to influence the direction of the conversation, but Bill, you accidentally forgot to log out as "j2ee master" and log back in as "bill burke". Or perhaps you were just using Mr. Master's computer? ;-)
    >
    > I was curious who was giving those poor Iona chaps a hard time.
    >

    First, I never alias. Second, I usually don't have time to post on these forums because I'm usually busy with REAL work.

    Bill
  38. bad idea[ Go to top ]

    Bill points out that the AOP facility in JBoss is designed around some "cool ideas": "One of our main goals is to totally isolate infrastructure from business logic by providing system-level aspects for: security, transaction demarcation, caching, ACIDity, remoteness, clustering, and persistence. This means you can write plain old Java classes and either statically or dynamically apply these types of aspects making your business logic totally INDEPENDENT of any system level API's. This is a grand departure from following specifications like CORBA or J2EE in that these standards create specification lock-in."

    There's nothing wrong with this as an internal implementation detail (though I don't know why the average end user would really care), but it's a really bad idea for end users. In general this functionality works best when it is used in complement to specific component models that encapsulate well understood patterns for managing the combination of complicated system level services (for example, transactioning) with the lifecycle of components hosted by the containers. When you strip away the container, you strip away correctness guarantees. And I guarantee that users are not going to understand how to achieve correctness -- and they're very likely to make mistakes in one-off scenarios even if they do. That's why a container is useful: it encapsulates these patterns in a framework that protects the user from the kind of mistakes that are going to occur from lack of understanding and plain old mistakes.

    Yes, you're "freed" from the constraints of standards. You're likely going to be making a devil's bargain for that freedom.
  39. AOP is future[ Go to top ]

    Bill points out that the AOP facility in JBoss is designed around some "cool ideas": "One of our main goals is to totally isolate infrastructure from business logic by providing system-level aspects for: security, transaction demarcation, caching, ACIDity, remoteness, clustering, and persistence. This means you can write plain old Java classes and either statically or dynamically apply these types of aspects making your business logic totally INDEPENDENT of any system level API's. This is a grand departure from following specifications like CORBA or J2EE in that these standards create specification lock-in."

    >
    > There's nothing wrong with this as an internal implementation detail (though I don't know why the average end user would really care),

    J2EE is a great specification and is a natural evolution from CORBA. JBoss is an OSS implementation of J2EE and is why people come to us and why we've had over 3.3 million downloads since inception. We would be fools to diverge from our core J2EE base or not follow the specification.

    With AOP and AOP services, we are positioning ourselves for the future. AOP is long term for us, NOT short term. You are right, the average end user won't even see JBoss AOP. Where it will really come of use in the short term is for system integrators, ISVs, and third party plugins to JBoss. Vendors who work with JBoss will have unprecendented ability to integrate with our J2EE engine. AOP will be this glue.

    That being said, distributed infrastructure applied transparently and implicitly to ordinary business logic is a perfect application of Aspect Oriented Programming. AOP and distributed computing are a clear match. What DCE, CORBA, J2EE, and Web Services all have tried to do is isolate the average everyday application developer from the complexity of remote invocations, transaction and security propagation, and persistence. AOP can complete this evolution because all this complex infrastructure can be applied to general business logic written as regular simple classes. The application designer can focus more on writing an object model that defines their business and business processes and worry less about how the object model must fit into a distributed computing architecture.

    There is already movement in place. Grady Booch is already predicting that AOP will have an effect on programming as much as OOP did the last 15 years. There was recently an AOSD conference on AOP that had a surprising number of participants. AspectJ has joined the Eclipse project. At JBoss, we're doing our part to by implementing our own pointcut facility and services built on top of it. We differ from AspectJ in that we are fully dynamic and we are XML based and 100% Java. Another big difference is that we're actually writing system-level aspects extracted directly from our J2EE code base. What's great, is that JBoss was already very aspect-oriented since our code is modeled on interceptor technology, so our existing codebase fits quites nicely into an AOP framework.

    more comments follow...

    >but it's a really bad idea for end users. In general this functionality works best when it is used in complement to specific component models that encapsulate well understood patterns for managing the combination of complicated system level services (for example, transactioning) with the lifecycle of components hosted by the containers. When you strip away the container, you strip away correctness guarantees. And I guarantee that users are not going to understand how to achieve correctness -- and they're very likely to make mistakes in one-off scenarios even if they do. That's why a container is useful: it encapsulates these patterns in a framework that protects the user from the kind of mistakes that are going to occur from lack of understanding and plain old mistakes.
    >

    Actually its much easier to encapulate these usage patterns through AOP and apply them to existing code. For example, a common mistake in J2EE programming is when developers forget to close ResultSets, Statements, or Connections. Because JBoss is interceptor based, we can easily apply an aspect that detects these leakages and can actually tell you the line of code that caused the leakage.

    > Yes, you're "freed" from the constraints of standards. You're likely going to be making a devil's bargain for that freedom.

    You're misinterpreting "freedom" here. Standards are very import, but manytimes applications and businesses outlive these standards and you get what I like to call specification lock-in. I've been on CORBA projects that had to spend huge man-hours porting DCE applications. J2EE projects that had to spend huge man-hours porting CORBA applications. Web Services and .Net is yet another waste of energy that sends everybody scurying again to move their existing applications to this "more powerful" architecture. My hope is the industry gets together on a standard that can finally and truly isolate your object models and business logic from distributed infrastructure so that we can avoid this "specification lock-in". AOP has the potential to do this and truly revolutionize the way we develop applications. When this eventually happens, JBoss will be ready. In fact, we hope to lead the charge.

    Bill Burke
    Chief Architect
    JBossGroup
  40. AOP is future?[ Go to top ]

    That's all well and good, and, when applied to distributed objects, not all that different conceptually (though *blessedly simpler* in practice) from programming with CORBA and moving the system level interactions out to PIs. As I've pointed out before, I've always thought IONA's ART core was ahead of the curve in taking a similar tact long before anyone had heard of -- or added refinement to -- programming with "aspects". But closing connections for an EJB automatically is one thing: but something like rolling your own system code for transaction processing around arbitrary object models is another thing altogether and, outside of specialized cases, a step backward.

    AOP is interesting and may turn out to be important; I'm not disputing that. I'm just saying that an application server is providing important services in controlled ways. When you step outside of those controls, you're asking for a boatload of problems if you don't know what you're doing. Those are domains that require specialized knowledge and experience -- I can't underscore the latter enough -- to get right. The whole point of the container is to remove some of that burden from the application architect.

    Greg
  41. AOP is future?[ Go to top ]

    I've pointed out before, I've always thought IONA's ART core was ahead of the curve in taking a similar tact long before anyone had heard of -- or added refinement to -- programming with "aspects".


    I was lucky enough to be on the original team that created IONA's ART core. This is why I was so impressed with JBoss when I first encountered it as they were using the same approach. Kind of validates the architecture doesn't it?

    >But closing connections for an EJB automatically is one thing: but something like rolling your own system code for transaction processing around arbitrary object models is another thing altogether and, outside of specialized cases, a step backward.

    Exactly, the application server, through aspects, should define these complex interactions. Let's give another example. We have an aspect that can be attached to a POJO that makes the POJO ACID with either pessimistic or optimistic locking. The algorithms for doing this are non-trivial and, if the application architect so desires, he/she can apply this transaction aspect to a plain java class AND the aspect takes care of the complexity.

    Yet another thing we're doing is a transactional distributed cache where all you have to do is:

    cache.put("key", pojo);

    And access to that pojo is transactional and state updates are automatically distributed across the cluster at commit time. How is this not the application server/framework hiding complex interaction from the application architect?

    >
    > AOP is interesting and may turn out to be important; I'm not disputing that. I'm just saying that an application server is providing important services in controlled ways. When you step outside of those controls, you're asking for a boatload of problems if you don't know what you're doing.

    Hmmm...I guess what you're really saying here is if you step outside the reach of J2EE you are going to encounter a boatload of problems. Let me tell you from experience. These specifications never solve all your problems and you always have to go beyond the specification to solve your requirements. I'm telling you that through AOP you can STILL apply these controls implicitly. We have the implementations to prove it.

    > Those are domains that require specialized knowledge and experience -- I can't underscore the latter enough -- to get right.

    Like the EJB spec got caching right or the container interactions with a cache. Commit Option A, B, C, now that's intuitive! Like EJB got persistence right. You still need huge proprietary deployment descriptors to describe anything other than a Micky Mouse O/R mapping.

    > The whole point of the container is to remove some of that burden from the application architect.

    Again, i do hope that a standards body gets together and defines an AOP standard and an AOP services standard. J2EE is our core, and with AOP were positioning ourselves for the inevitable future down the road.

    But, what we're really doing is changing how the application architect makes his/her decisions. Instead of deciding, does this object have to be implemented as an EJB? The application architect will decide things like, this object needs to be remote. This object needs to have a secure interface. This object needs to be cached. This object needs to be cached, transactional, and secure. Do you see the difference? We can do this because our AOP framework allows us to intercept object creation and field and method access and our system level aspects LEVERAGE our J2EE infrastructure like JTA, JCA, JAAS, etc....
  42. What are the cons?[ Go to top ]

    Bill, what (in your view) are the possible problems or drawbacks with the AOP approach to building enterprise systems?
  43. What are the cons?[ Go to top ]

    Bill, what (in your view) are the possible problems or drawbacks with the AOP approach to building enterprise systems?


    Interesting question. I hope to encounter these problems and drawbacks as we iterate. The first that comes to mind is that as you add more and more pointcuts to a give class/object instance, you have a greater chance of these pointcuts clashing against each other or the ordering of pointcut application may be important. What I think can alleviate some of this type of issue is pre-defining interceptor stacks that one can apply to a given object. For example, security is really made up of 3 different interceptors, Authentication, Rolechecks, and RunAs. You could predefined configuration that applies all three of these pointcuts to your class. Plus, I think a good aspect code will check for these types of dependencies/clashes when they design their aspects.

    Another problem might be is that since aspects are applied transparently, it becomes harder to know what's REALLY going on. This is one of the things I liked about AspectJ is that they have already defined eclipse plugins that allow you to visually see what aspects are applied to what class. Too bad they have no concept of dynamicity. Plus I really hate all the before, after, and handle shit. IMHO, an interceptor gives you the same thing and is much more intuitive.

    Still another is that for some types of things you may still have to define a contract with the application developer. Persistence is a great example. Take Hibernate for instance. This is a great example of applying persistence to POJOs, yet they require you to define your fields that are relationships as Java interfaces (Map, List, Set, etc...) because of obvious instrumentation issues with system classes.

    That's really all I've thought about and considered so far. If you have any references that might discuss some of the cons, I am very interested.
  44. What about introductions?[ Go to top ]

    Thanks for the suggestions. But, you didn't mention anything about introductions, so your response only covers half of AOP (what some people would call the "interception" part). Do you see any potential problems with using introductions when building enterprise systems?
  45. what do you mean by introductions?[ Go to top ]

    Thanks for the suggestions. But, you didn't mention anything about introductions, so your response only covers half of AOP (what some people would call the "interception" part). Do you see any potential problems with using introductions when building enterprise systems?


    Do you mean adding an interface, method, field to a class? I have designed this, but not implemented yet. We intend on implementing shortly and can easily do this with our current architecture.

    I don't like the idea of introducing fields as this would have an affect on non-AOP'ed remote clients and serialization.

    I see nothing but benefits so far with adding interfaces to an existing class. I really like the idea of a somebody being able to apply their own API to their advised classes. This will really kick with ISVs, tools vendors that want to integrate extra-tightly with JBoss.
  46. what do you mean by introductions?[ Go to top ]

    Do you mean adding an interface, method, field to a class?


    Yes.

    > I have designed this, but not implemented yet. We intend on implementing
    > shortly and can easily do this with our current architecture.

    Ok, if you say so :-)

    > I don't like the idea of introducing fields as this would have an affect on
    > non-AOP'ed remote clients and serialization.
    >
    > I see nothing but benefits so far with adding interfaces to an existing class.
    >I really like the idea of a somebody being able to apply their own API to their
    >advised classes. This will really kick with ISVs, tools vendors that want to
    >integrate extra-tightly with JBoss.

    Ok, I see. I think you're in for some interesting surprises, but I'm not going to spoil the fun for you :-) Good luck with it.
  47. what do you mean by introductions?[ Go to top ]

    Do you mean adding an interface, method, field to a class?

    >
    > Yes.
    >
    > > I have designed this, but not implemented yet. We intend on implementing
    > > shortly and can easily do this with our current architecture.
    >
    > Ok, if you say so :-)

    introductions are a joke to implement with javassist. You should really check out this intuitive powerful library.

    >
    > > I don't like the idea of introducing fields as this would have an affect on
    > > non-AOP'ed remote clients and serialization.
    > >
    > > I see nothing but benefits so far with adding interfaces to an existing class.
    > >I really like the idea of a somebody being able to apply their own API to their
    > >advised classes. This will really kick with ISVs, tools vendors that want to
    > >integrate extra-tightly with JBoss.
    >
    > Ok, I see. I think you're in for some interesting surprises, but I'm not going to spoil the fun for you :-) Good luck with it.

    Quite honestly, the reason introductions haven't been added yet is that I haven't encountered a use case for them yet in the several system-level aspects we have and are currently writing. Although they are sexy, they are definately not critical. But, sex sells, so they'll be in there for the 1st release.
  48. Introductions[ Go to top ]

    <bill>
    introductions are a joke to implement with javassist. You should really check out this intuitive powerful library.
    </bill>

    I think you are too focused on the implementation and not seeing the bigger picture. My guess is that Rickard is referring to consequences that introductions have on a distributed J2EE application.

    --
    Cedric
    http://beust.com/weblog
  49. Introductions[ Go to top ]

    <bill>

    > introductions are a joke to implement with javassist. You should really check out this intuitive powerful library.
    > </bill>
    >
    > I think you are too focused on the implementation and not seeing the bigger
    >picture. My guess is that Rickard is referring to consequences that
    >introductions have on a distributed J2EE application.

    Very perceptive of you! I'm also referring, for example, to the consequences that introductions have on persistence.

    But as I said, no point in spoiling all the fun, especially since Bill is such a good and experienced programmer. Since the deadline for JBoss4 is May 26 (see jboss-dev) we'll find out pretty soon just what that means.
  50. Introductions[ Go to top ]

    <bill>

    > introductions are a joke to implement with javassist. You should really check out this intuitive powerful library.
    > </bill>
    >
    > I think you are too focused on the implementation and not seeing the bigger picture. My guess is that Rickard is referring to consequences that introductions have on a distributed J2EE application.
    >
    > --
    > Cedric
    > http://beust.com/weblog

    Maybe so, but if you've any of my posts you'll see that we've actually used the framework to build actual aspects. In fact, ever since JBoss 2.0 (late 2000), JBoss has been increasingly implemented on top a set of aspects(interceptors). Rickard should know this. So as far as consequences goes, a most of them have been worked out. After all, what is EJB anyways but a transparent application of system level aspects on an object model?

    Anyways, talk != action, time for some real work.
  51. Introductions[ Go to top ]

    Maybe so, but if you've any of my posts you'll see that we've actually used the

    >framework to build actual aspects.

    Actual aspects, in an actual application, actually running somewhere in a production environment? If so, could you tell us more about it because it's the first I've heard about it.

    >In fact, ever since JBoss 2.0 (late 2000), JBoss has been increasingly
    >implemented on top a set of aspects(interceptors).

    "aspects" != "interceptors"
    interceptors (aka advice) is a subset of aspects.

    > Rickard should know this.

    I know that JBoss has interceptors, because I designed it that way. That, as has been pointed out by Ted Neward and others, has little to do with AOP, in any proper sense.

    > So as far as consequences goes, a most of them have been worked out.

    Oh really? And still you know very little about introductions, and what they are all about, even though they are (AT LEAST) 50% of what AOP is about. I can tell you that in the project I've been working on since last summer (a full CMS/portal running in production on numerous sites), which is based on AOP ideas, introductions are absolutely critical. And I don't think our project is special in any way.

    >After all, what is EJB anyways but a transparent application of system level
    >aspects on an object model?

    Well, it's not really that transparent, but you are correct that they are system level aspects. Which is, in my experience, an important but small part of what AOP brings to the table.

    > Anyways, talk != action, time for some real work.

    In deed.
  52. Pissing Contest[ Go to top ]

    This pissing contest is 1 part funny and 1 part disgusting... You guys are both smart. Why is it so important to prove it?
  53. Open Source[ Go to top ]

    Rickard,

    I am a big fan of your work from Jboss to XDoclet to XWork. Is there any chance you will be able to release your AOP framework in the open source arena as well.

    The thing I like about what JBoss is doing is that they are bringing AOP to the masses while still completing the whole J2EE stack. I believe in the power of open source and even if they were to stumble(not likely) it would be noted and probably fixed. Your feedback can only help so I don't see you as antagonistic to their cause of bringing AOP to the masses. More of a referee.

    Until your AOP framework is released we will have to do with Nanning, AspectJ, and JBoss's AOP frameworks. I enjoy reading about how you solved this or that problem with your implementation, but until it is released us mere mortals will have to do without. Of course you will probably say I should come up with my own implementation. And maybe I will.

    tx

    Matt
  54. Re: Open Source[ Go to top ]

    I am a big fan of your work from Jboss to XDoclet to XWork. Is there any

    >chance you will be able to release your AOP framework in the open source arena
    >as well.

    Yes, but there are many obstacles. Finding time to do it, figuring out what is part of the framework and what is our app, coming up with a good licensing model, etc. There's a LOT of issues, but the main reason it has not been done yet are mainly time and licensing.

    But I can't make any promises. Look at it this way: if it is OpenSource'd, be happy, if it's not, then there's a bunch of alternatives available so it's not like it's the end of the world. And new ones seem to be popping up regularly.

    > The thing I like about what JBoss is doing is that they are bringing AOP to
    >the masses while still completing the whole J2EE stack. I believe in the power
    > of open source and even if they were to stumble(not likely) it would be noted
    >and probably fixed.

    Maybe, maybe not. I've noted a number of issues with the way they do things now, and I doubt any of them would be addressed. We'll see.

    > Your feedback can only help so I don't see you as
    >antagonistic to their cause of bringing AOP to the masses. More of a referee.

    You're right, I'm not antagonistic, per se. I *am* very much against what the current implementation looks like, and the way they go about adding new features, because I don't see any understanding of the consequences or any overall vision in there. But that is nothing that I can influence really, and I honestly don't really care. It's not my problem.

    But if I say this, do you really think Bill B. would listen to it? It remains to be seen, but I doubt it.

    > Until your AOP framework is released we will have to do with Nanning, AspectJ,
    > and JBoss's AOP frameworks. I enjoy reading about how you solved this or that
    > problem with your implementation, but until it is released us mere mortals
    > will have to do without.

    Or you can believe the JBoss hype. They say their framework is the "AOP framework of the future". Maybe they're right ;-)

    > Of course you will probably say I should come up with
    > my own implementation. And maybe I will.

    Well, nothing is stopping you, right? ;-)
  55. standing on the shoulders[ Go to top ]

    Bill: Anyways, talk != action, time for some real work.

    I used to work for a company that had T-Shirts that said "Shut Up And Code!" ;-)

    Sometimes talk is good, because it can prevent a lot of wasted action. OTOH, I'm curious what you guys will come up with, whether or not it works out well. JBoss is definitely the geek's playground, and I mean it in the most respectful and complimentary way.

    Regardless of the outcome, it will move the AOP conversation forward significantly. Maybe you (JBoss) get it right first, maybe not, but in the scheme of things it's not going to matter in five years, because by then you'll have it working and AOP will probably be a significant part of the basis for the next generation of software, including the language that will replace Java as the de facto standard (which of course could just be the next version of Java, however that's like assuming C++ is an object-oriented version of C, which it really wasn't ... Java was the object-oriented version of C, and ??? will be aspect-oriented version of Java.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  56. Do you mean adding an interface, method, field to a class?

    It will be great fun to see this combined with distributed applications with two-phase commit transactions, persistence & cluster-cashing, O/R mapping, fine-grained - coarse-grained entity beans, etc..

    And I who thought it was not possible to mess up the whole J2EE business anymore!

    I am happy to hear that I was wrong..

    Regards
    Rolf Tollerud
  57. what do you mean by introductions?[ Go to top ]

    Ok, I think I see what you mean by introductions, (read your blog). Yes, you can add an interceptor to an individual instance. Remoting and Versioned objects (transactional objects) are a prime example of this. We are currently implementing a transactional distributed clustered cache as well in which when you insert into the cache, caching aspects get applied to the instance (and the rest of the graph). Besides adding interceptors to a given instance, you can also attach metadata to a given instance as well. What's great about our metadata is that you find it based on the context of the invocation and we can chain configuration domains.
  58. what do you mean by introductions?[ Go to top ]

    What's great about our metadata is that you find it based on the context of the

    >invocation and we can chain configuration domains.

    Which on the one hand maybe is great, but on the other is exactly what Greg Pavlik is talking about. If you play with big guns you're gonna get hurt, that's all I'm saying (having played with this particular gun for some time).
  59. what do you mean by introductions?[ Go to top ]

    What's great about our metadata is that you find it based on the context of the

    > >invocation and we can chain configuration domains.
    >
    > Which on the one hand maybe is great, but on the other is exactly what Greg Pavlik is talking about. If you play with big guns you're gonna get hurt, that's all I'm saying (having played with this particular gun for some time).

    Sorry, but this is my second (kinda almost 3rd) time playing if you know my background at all.

    Hmmm.. but maybe you and Greag are right and I should just give up. After all, children shouldn't play with guns, eh?
  60. what do you mean by introductions?[ Go to top ]

    Which on the one hand maybe is great, but on the other is exactly what Greg

    >Pavlik is talking about. If you play with big guns you're gonna get hurt, that's
    >all I'm saying (having played with this particular gun for some time).
    >
    > Sorry, but this is my second (kinda almost 3rd) time playing if you know my
    > background at all.

    Big words. We'll see what they amount to soon enough I suppose.

    > Hmmm.. but maybe you and Greag are right and I should just give up. After all,
    >children shouldn't play with guns, eh?

    If children don't mind getting hurt, sure, no problem.

    "Bringing AOP to the masses", as Marc calls it, is a daunting task. Perhaps not technically, but from a knowledge and maturity point of view. From my own experience there IS a lot of pain, a lot of mistakes, and a lot of confusion involved with working with AOP, but it also *can* pay off BIGTIME. It did for us. The question is: are the "masses" ready to take this kind of pain? Traditionally speaking I don't think so, since "comfy and safe" is what makes the world tick. EJB also involves some pain, but (as Greg points out), it also has that "comfy and safe" quality. Well, AOP isn't "comfy and safe", it is a big gun which can get you places, but can also induce a lot of pain. If you only tell the "masses" about the "get you places" part, sure, they'll love ya, but don't complain when they start crying from the pain...
  61. Well, Rickard, that's pretty much my original point. You have to tell people about the consequences of any architecture clearly as they may not see them straightaway, or ever for that matter. Some of the patterns literature does a reasonable job of treating the liabilities as strongly as the benefits; I don't see that happening here. If the implementers don't see the liabilities, that's a serious problem for end users. After all, architecture decisions are exercises in cost-benefit analysis.
  62. AOP is future?[ Go to top ]

    I know what it's like to be enthused about new architecture possibilities for middleware. But this is the statement that I originally wrote about: "One of our main goals is to totally isolate infrastructure from business logic by providing system-level aspects for: security, transaction demarcation, caching, ACIDity, remoteness, clustering, and persistence. This means you can write plain old Java classes and either statically or dynamically apply these types of aspects making your business logic totally INDEPENDENT of any system level API's." The point I'm trying to make is that willy-nilly adding certain services to arbitrary objects sounds great, cool, whatever, but it's also fraught with risk unless you really know what you're doing. You might. Lots of end users won't. If you're saying the aspect(s) will do everything correctly to an arbitrary object, who knows? After all, containers interact with components in important ways that have a direct correlation to the services they provide and manage: the EJB APIs map service interaction to lifecycle events that the component needs to be aware of and deal with.

    On the other hand, turning on or off system services for EJBs is great; it's also something virtually every application server can do to one extent or another. Aspects are a nice implementation approach.

    If you need to solve a problem that is outside the scope of the specification, that's a different matter. No matter where you go, you'll elevate your risk and for J2EE probably tie yourself to an application server.
  63. I do think SUN is shooting itself in the foot. My last two projects have been for very small start-ups with absolutely no budget for expensive appservers. JBoss is a godsend to projects with these budget constraints. I understand that SUN has to make money on Java & J2EE, but I think it's to the point where making money is more important than promoting software standards and innovative ideas. For example, I think JDO is a viable alternative to EJB, yet SUN doesn't promote JDO because they're making their money off EJB appservers. JBoss is bad for SUN's clients and SUN is stuck between a rock and a hard place. And his leaves a little room for Microsoft to move in.

    I don't know what the solution is, but I do think we developers need to organize and do something about it.

    Michael
  64. I doubt that JBoss is actually cistinG IBM and BEA that much sale.
    The pricing of WAS and WL are pretty high. The majority of JBoss
    users would probably have went from J2EE to Microsoft technology.

    So JBoss is good for J2EE.

    [and that the SUN products does not sell i ssomething SUN should
    blame on themselves instead of others]

    SUN owns J2EE - fine. SUN makes the TCK and administers the
    certfication - fine. SUN makes money from that - fine. All fine.

    But what I do not like is:
      - that the price tag is secret
      - SUN seems to think they can decide who are allowed to
        try and get certified

    The price should be public.

    The TCK and certfication should be available for anyone (who pays
    and sign the necesarry papers).

    The certfications should be observed and approved by an independent
    body.

    If J2EE are to be considered serious as a standard, then I think
    this is necesarry.

    And if SUN will not do that, then maybe possibilities not involving
    SUN should be considered.
  65. Sun decides who can certify?[ Go to top ]

    SUN seems to think they can decide who are allowed to

    > try and get certified

    Um, no, there are some pretty clear laws against that.
    The only people who decide who certifies are the
    developers of the container in question. They get to
    decide whether they'll pay, and whether they'll run the
    tests, and whether they'll fix anything the tests turn up.
    It is really simple.
  66. Y2MJI: Yet 2 More JBoss Interviews[ Go to top ]

    It is the J2EE brand coupled with the word FREE that makes JBOSS appealing. For this reason, JBOSS owes a debt of gratitude to Sun and the J2EE brand and
    therefore should be certified.

    Certification will do nothing but help both parties, I hope they can grow up and settle their differences for the good of the Java and J2EE community
  67. Sun has a point[ Go to top ]

    I am leaning towards SUN on that one. JBoss leveraged the J2EE brand to establish a market presence.

    If they actually break the J2EE standard then it is MS tactics. Sun in right in trying to make sure that JBoss doesn't abandon the J2EE specification.

    But I don't get the impression from Bill's post that it is the case. Could someone from JBoss clarify if JBoss plans on supporting J2EE in the future?
  68. Certification will help everyone[ Go to top ]

    JBoss benefited from its association with J2EE, and vice versa J2EE has been protected by lowend encroachment from dotnet by JB.

    It is clear to me that J2EE success is directly linked to JB' success as the defacto reference implementation.

    There is a symbiotic relationship and both JBoss and SUN should stop fearing each other.
  69. Certification will help everyone[ Go to top ]

    There is a symbiotic relationship and both JBoss and SUN should stop fearing each other.

    Strangely, some relationships are built on -- and thrive on -- antagonism. I think if JBoss and Sun started getting along, that JBoss would lose its way ;-). You're definitely right though that JBoss plays quite a big role both in the adoption of J2EE and the castration of proprietary non-J2EE platforms. While I don't personally care for the militant-in-your-face-constantly-anti-vendor approach that JBoss group takes, I think in the end they will do more to help (than hurt) the J2EE market place, including the big J2EE vendors like IBM and BEA that JBoss group constantly talks about trying to put out of business.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  70. Where JBoss is Not[ Go to top ]

    A little off-topic, but just checked out the JDJ Reader's Choice poll. JBoss is conspicously absent in the "best java application server category"--a category that includes such dominant players as Open for Business?