J2EE without a Container?

Home

News: J2EE without a Container?

  1. J2EE without a Container? (95 messages)

    When studying for the MCAD certification, I found a fundamental architectural flaw of J2EE as a platform compared to .NET.

    In .NET, all .NET services are available to all types of .NET applications, be it a console application, a WinForm application, a Web application/services, a Windows service application, or a remoting application.

    However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers, i.e., Web applications/services and EJB applications. These services are not available to other types of applications such as a standalone Java application (e.g. to be run as a cron scheduled job).

    JPA (Java Persistence API) maybe one step in the right direction, but will it be beneficial to open up all J2EE services to Java applications running outside a J2EE container instead of requiring a SLSB (or Web services) to access J2EE services such as JTA etc., therefore, makes the concept of a J2EE container obsolete?

    Threaded Messages (95)

  2. Spring is the answer[ Go to top ]

    I think that the J2EE spec writers must learn from the experience of the Spring framework.
  3. I would say before writing anything about comparing .NET and J2EE , there is no comparision guys. .NET is just a child before J2EE.
  4. I have worked only in J2EE. But IMO, Java community should not take competition lightly. We may very well dismiss things like .NET, Ruby, Rails etc as very simple (like VB was said to be housewives' language). But history points that best technologies and products have rarely been best-sellers. If you don't believe then ask Apple and Steve Jobs. So we should keep the ante up, take every competition seriously and try to improve upon shortcomings of J2EE. I am already hearing of several J2EE applications being converted to .NET.

    And speaking of EJB3, its very hard to convince people to return back to it who first spent efforts in EJBs, faced its failures and then moved to other techs like Hibernate/Toplink.
  5. Sun's deal with the devil[ Go to top ]

    Precisely what I've been feeling for four years of developing J2EE applications - why do I need a 'container' running to use basic features in a stand-alone application?

    For the most part the container is just unnecessary and gets in the way of running, debugging, deploying (which is only necessary because of the container), and generally makes everything overly complex.

    The only exception is when the application needs some kind of remoting which probably only applies to the interface layer for most sensibly architected solutions and probably never to EJBs (remotely accessible entity beans? What kind of sick joke was that?), with the exception of MDBs.

    Unfortunately I have a bad feeling that the choice of tying J2EE to the container was a deliberate choice meant to garner support from 'big architecture' vendors - and probably succeeded. But today we could do with as little as possible forced tie-in to an aplication server.
  6. Sun's deal with the devil[ Go to top ]

    I'm sorry, guys, but in every JEE spec, it's never stated that the containter must run the way JBoss, Weblogic run. That is: starting up, deploying applications the way they do, etc.
    There's nothing preventing us from having a JEE container that will allow us to run stand alone applications with the full JEE stack available. We just don't have any implementation out there.
    Don't blame the specs after judging the implementations.
  7. Sun's deal with the devil[ Go to top ]

    What is the J2EE platform?

    The J2EE spec or the total of certified J2EE servers.
  8. What is the J2EE platform?[ Go to top ]

    Sorry, should be a question mark.

    The J2EE spec or the total of certified J2EE servers?
  9. J2ee platform[ Go to top ]

    What is the J2EE platform?The J2EE spec or the total of certified J2EE servers.

    The J2EE platform is _any_ (not total) server that conforms to the spec. If i were to write programs conforming to the j2ee spec, i can be assured that it will run on any j2ee certified server on as many hardware platforms as any of the j2ee certified servers are capable of running. If there comes a JBoss Micro Edition tomorrow that runs on mobile devices, my application will be deployable to mobile devices. If there comes a websphere home appliance edition, my application will be deployable to my home appliances. As of currently, i can deploy my application to most all different versions of unix/linux, to as400, to sparcs, x86, etc.

    I can lookup ejb's or interact with servlets or remote jdbc datasources from a windows box to a non windows box. Can i do that with .NET? You say all the .net services are available in Windows. Are they available outside of windows? (Dont bother pointing me to things like MONO which are not microsoft certified .net).
  10. PREMISE ... ENTIRELY FALSE[ Go to top ]

    The premise for the orignial post of this thread is entirely false. Take the following statement ...

    In .NET, all .NET services are available to all types of .NET applications, be it a console application, a WinForm application, a Web application/services, a Windows service application, or a remoting application.

    Lest you forget that in the .NET world, WINDOWS ITSELF IS THE APPLICATION SERVER. .NET does not run in a vaccum. It ain't free or cheap .... :-)
  11. PREMISE ... ENTIRELY FALSE[ Go to top ]

    The premise for the orignial post of this thread is entirely false. Take the following statement ...In .NET, all .NET services are available to all types of .NET applications, be it a console application, a WinForm application, a Web application/services, a Windows service application, or a remoting application.Lest you forget that in the .NET world, WINDOWS ITSELF IS THE APPLICATION SERVER. .NET does not run in a vaccum. It ain't free or cheap .... :-)

    Very well said!!! Another point is, because the operating system acts as a container, many times a poorly written application brings down the whole system.

    More over, many of the Java EE APIs are available on Java SE platform. In a future version of Java SE, one can even develop web service on Java SE.
  12. J2EE without a Container?[ Go to top ]

    However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers

    This isn't really true. You can use JTA and JCA easily inside any JVM, ditto JMS, JNDI and EJB 3 persistence.

    I think its only true to say that EJBs are only available inside an EJB container. But given that .Net/Windows is a container anyway its a fairly meaningless distinction.

    James
    LogicBlaze
  13. J2EE without a Container?[ Go to top ]

    However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers
    This isn't really true. You can use JTA and JCA easily inside any JVM, ditto JMS, JNDI and EJB 3 persistence. I think its only true to say that EJBs are only available inside an EJB container. But given that .Net/Windows is a container anyway its a fairly meaningless distinction.JamesLogicBlaze

    I'd argue we don't need a "constrainer" and all that was originally meant by the term originally put forward all those years ago.

    What we do need are fundamental APIs (JTA, JMS, JNDI, JDBC and the rest) with which to design and construct our applications. JEE has, to a large extent, delivered on some of those fundamentals; with EJB perhaps not originally
    one of those...enter EJB 3.0 and all it promises.

    I wouldn't say .NET/Windows is the major container -
    certainly not for Java, anyway. The JSE and JEE infrastructure APIs are what constrain and contain Java. I'm
    currently heading up large scale migration off of Windows and Solaris platforms and onto Linux. The fact is, with Oracle and
    Java running on the top 2 Linux platforms (Suse and Red Hat)
    my client is happy; with a large investment in Linux up-front he's looking for the longer term savings...but
    that's another story.

    One of the original arguments for the container was it
    worked well with the division of roles: application developer, deployer, configurer and administrator. The roles
    are there but the practicality off assigning those roles
    to different individuals for the same application is often questionable.

    With the lightweight approach to development, we don't tie
    ourselves directly into container features anyway (like
    JNDI references, JDBC parameters, transaction managers etc.) and haven't done for some time.

    Are we rebelling to get out-of-the-box?

    Gary
    BeanPlanet.org
    __________________________________________________________
  14. I'll second and third that opinion[ Go to top ]

    However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers

    This isn't really true. You can use JTA and JCA easily inside any JVM, ditto JMS, JNDI and EJB 3 persistence.

    I think its only true to say that EJBs are only available inside an EJB container. But given that .Net/Windows is a container anyway its a fairly meaningless distinction.

    JamesLogicBlaze

    the original author of the post seems a bit fogy on J2EE technology. There are plenty of people using JTA on tomcat and resin without EJB. Just google for 30 minutes and you'll see plenty of results.

    peter
  15. I'll second and third that opinion[ Go to top ]

    the original author of the post seems a bit fogy on J2EE technology. There are plenty of people using JTA on tomcat and resin without EJB.

    You can also use JTA on Weblogic/WebSphere without EJB. That is not my original point.
  16. I'll second and third that opinion[ Go to top ]

    You can also use JTA on Weblogic/WebSphere without EJB. That is not my original point.

    George,

    It is perfectly possible to access JTS through JTA in a standalone application. Even in the JNDI tutorial there are samples on how to access one of the most famous directory implementations from a stand alone application (please note the difference between an API and a service).

    OTOH Why would you start distributed transactions from clients? Have you ever realized the effect on locked resources in the event of a single network failure?

    Please, be nice, ask for help, there would be many people willing to lend you a helping hand. Out there are the tutorials, the JDK documentation, newbies forums. Don't make so blatantly evident your lack of knowledge on the matter.


    Javier
  17. George,It is perfectly possible to access JTS through JTA in a standalone application. Even in the JNDI tutorial there are samples on how to access one of the most famous directory implementations from a stand alone application (please note the difference between an API and a service)

    My fault, it's possible to use the APIs you mentioned from a standalone application, eg. JTA and JNDI, I didn't meant to mix both.


    Javier
  18. I'll second and third that opinion[ Go to top ]

    Javier,

    Thank you for the lesson.

    There is a long list of APIs which are mandatory for any J2EE certified servers, not just JTA. (Sorry JNDI is definitly a bad example).

    Even JTA, would you please point to me how to call them from a client application directly with major comercial J2EE servers? Point me to some Weblogic doco or WebSphere doco please.

    Why want to use JTA in a client application? Say if I want the standalone Java application to be run as a night batch job (scheduled with cron) to reconcile two different databases and I don't want to write/deploy an EJB.
  19. Javier,Thank you for the lesson. There is a long list of APIs which are mandatory for any J2EE certified servers, not just JTA. (Sorry JNDI is definitly a bad example).Even JTA, would you please point to me how to call them from a client application directly with major comercial J2EE servers? Point me to some Weblogic doco or WebSphere doco please.Why want to use JTA in a client application? Say if I want the standalone Java application to be run as a night batch job (scheduled with cron) to reconcile two different databases and I don't want to write/deploy an EJB.

    I don't know what you're talking about. Do you want an in-process transaction management service or a transaction management service you can call from a client? In the first case you need an embeddable transaction server such as this one: http://jotm.objectweb.org/current/jotm/doc/howto-integrate-jotm.html
    In the second case look here: http://e-docs.bea.com/wls/docs81/rmi/rmi_api.html

    The fact that J2EE does not mandate that all application server vendors provide embeddable versions of every service does not mean those services are not available from other sources. There is, in other words, no technical reason I can see one can't provide those services as standalone or embeddable components if there is a business opportunity to sell the resulting products: the fact there is not a flourishing market of standalone JTA transaction servers mean that probably the world doesn't find application servers to be so bad, as tools for doing the same thing.
  20. Javier,Thank you for the lesson. There is a long list of APIs which are mandatory for any J2EE certified servers, not just JTA. (Sorry JNDI is definitly a bad example).Even JTA, would you please point to me how to call them from a client application directly with major comercial J2EE servers? Point me to some Weblogic doco or WebSphere doco please.Why want to use JTA in a client application? Say if I want the standalone Java application to be run as a night batch job (scheduled with cron) to reconcile two different databases and I don't want to write/deploy an EJB.
    I don't know what you're talking about. Do you want an in-process transaction management service or a transaction management service you can call from a client? In the first case you need an embeddable transaction server such as this one: http://jotm.objectweb.org/current/jotm/doc/howto-integrate-jotm.htmlIn the second case look here: http://e-docs.bea.com/wls/docs81/rmi/rmi_api.htmlThe fact that J2EE does not mandate that all application server vendors provide embeddable versions of every service does not mean those services are not available from other sources. There is, in other words, no technical reason I can see one can't provide those services as standalone or embeddable components if there is a business opportunity to sell the resulting products: the fact there is not a flourishing market of standalone JTA transaction servers mean that probably the world doesn't find application servers to be so bad, as tools for doing the same thing.

    You are using RMI to break into the Weblogic container to access JTA. This does not contradict my original statement.

    Anyway, as another post said, there is not a market demand there to do things the way .NET does. After all, this may not be a big issue (to access J2EE APIs from outside the container with HTTP/SOAP/RMI to get through the J2EE container wall).
  21. What about Windows as a Container?[ Go to top ]

    George, since you're being obstinate in not accepting answers people have given you instead of twisting them from J2EE cannot do this to J2EE containers cannot do this to J2EE can do this but only a minority does it to J2EE can do this but is a hack through a wall and what not.

    Why don't you answer some questions about Windows/.Net. Since Windows itself is a Container for .NET, can people run/access .NET services outside of windows, i.e. other OSes without having to bypass your so called "wall" that comes with J2EE containers? And please, dont bother posting things like only serious projects use Windows.
  22. I'll second and third that opinion[ Go to top ]

    You are using RMI to break into the Weblogic container to access JTA. This does not contradict my original statement.

    "However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers, i.e., Web applications/services and EJB applications. These services are not available to other types of applications such as a standalone Java application (e.g. to be run as a cron scheduled job)."

    Client application can be
    a cron scheduled job without problems. If you believe distributed applications, components, containers and servers is a design flaw some reason then configure and maintain all services like JTA per application yourself (just download and use plain JTA implementation ).
  23. I'll second and third that opinion[ Go to top ]

    would you please point to me how to call them from a client application directly with major comercial J2EE servers? Point me to some Weblogic doco or WebSphere doco please.

    Sounds like you are changing by qualifying your argument now and taking everyone down a rathole. You will be visited by three ghosts tonight of J2EE past, present, and future. Maybe they can do some good.

    More interesting to me is Bill Burke's post in fear of light containers. I guess he is "on message. " Does JBoss see a threat from Tomcat/Springframework containers? WebLogic has embraced Spring while JBoss seems to FUD it.
  24. I'll second and third that opinion[ Go to top ]

    Even JTA, would you please point to me how to call them from a client application directly with major comercial J2EE servers? Point me to some Weblogic doco or WebSphere doco please.Why want to use JTA in a client application? Say if I want the standalone Java application to be run as a night batch job (scheduled with cron) to reconcile two different databases and I don't want to write/deploy an EJB.

    This is WebLogic documentation, I hope you can find WebSphere docs yourself.
    http://e-docs.bea.com/wls/docs70/jta/gstrx.html#1067532

    You can use this stuff from standalone application for a night batch job without problems. You can read j2ee tutorials to learn more about this stuff. I think it is a good idea to read something about technology before to write lame articles.
  25. I'll second and third that opinion[ Go to top ]

    This is WebLogic documentation, I hope you can find WebSphere docs yourself.http://e-docs.bea.com/wls/docs70/jta/gstrx.html#1067532You can use this stuff from standalone application for a night batch job without problems. You can read j2ee tutorials to learn more about this stuff. I think it is a good idea to read something about technology before to write lame articles.

    See my earlier post. App servers are not required to make the JTA interface available to user applications. That said, anyone has the ability to embed a standalone JTA implementation inside their Java main, and use it.

    App servers are required to make the javax.transaction.UserTransaction interface available to user apps, which provides the ability to begin, commit and rollback transactions in coordination with the rest of the app server. This interface can be used within a servlet (or any user objects called from said servlet), or within a bean-managed transaction EJB (or any user objects called from said EJB).
  26. Rereading my post, I realized some clarification might help.

    App servers are not required to make the javax.transaction.TransactionManager interface available to user code, per the J2EE specs. TransactionManager is the "master" API that exposes all the low-level operations of the underlying transaction service. As the Javadoc states: "The TransactionManager interface defines the methods that allow an application server to manage transaction boundaries." It is this interface that (if called from user code) has the potential to pull the rug out from under the rest of the app server.

    The javax.transaction.UserTransaction interface is a "safe" subset of the TransactionManager interface that lets user code begin, commit and rollback transactions. J2EE app servers are required to make this interface available at a standardized location in the JNDI namespace (java:comp/env/UserTransaction).

    Both interfaces are part of the JTA API set. For more details see http://java.sun.com/products/jta/jta-1_0_1B-doc/ .
  27. I'll second and third that opinion[ Go to top ]

    Javier,Thank you for the lesson. There is a long list of APIs which are mandatory for any J2EE certified servers, not just JTA. (Sorry JNDI is definitly a bad example).Even JTA, would you please point to me how to call them from a client application directly with major comercial J2EE servers? Point me to some Weblogic doco or WebSphere doco please.Why want to use JTA in a client application? Say if I want the standalone Java application to be run as a night batch job (scheduled with cron) to reconcile two different databases and I don't want to write/deploy an EJB.

    Well, after all J2EE isn't flawed huh, I think your perception of it is? Or not ?
  28. I'll second and third that opinion[ Go to top ]

    Even JTA, would you please point to me how to call them from a client application directly with major comercial J2EE servers? Point me to some Weblogic doco or WebSphere doco please.

    http://www.google.com/search?hl=en&q=jta+weblogic&btnG=Google+Search

    http://www.google.com/search?hl=en&lr=&q=websphere+jta+transaction+manager&btnG=Search
    Why want to use JTA in a client application? Say if I want the standalone Java application to be run as a night batch job (scheduled with cron) to reconcile two different databases and I don't want to write/deploy an EJB.

    Whats the problem with the EJBs? Distributed transactional processing is a very good case to use them


    Javier
  29. I'll second and third that opinion[ Go to top ]

    However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers
    This isn't really true. You can use JTA and JCA easily inside any JVM, ditto JMS, JNDI and EJB 3 persistence. I think its only true to say that EJBs are only available inside an EJB container. But given that .Net/Windows is a container anyway its a fairly meaningless distinction.JamesLogicBlaze
    the original author of the post seems a bit fogy on J2EE technology. There are plenty of people using JTA on tomcat and resin without EJB. Just google for 30 minutes and you'll see plenty of results.peter

    BTW what exactly is wrong with using a J2EE application server anyways? An app server is a dirty word nowadays with the TSS fad-following crowd. You get all these services like JTA, JMS, etc... all managable and collocated in one process, integrated, and managable with nice GUI tools. I know at least JBoss allows you to pick and choose what components you want installed. Really, all this "lightweight" talk is just silly when in reality you need at least a few Java EE services to build any real applications. Given all the improvements made in the Java EE 5 platform, alot of these self-proclaimed "lightweight" solutions start to look kinda heavy to me.

    Bill
  30. J2EE without a Container?[ Go to top ]

    However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers
    This isn't really true. You can use JTA and JCA easily inside any JVM, ditto JMS, JNDI and EJB 3 persistence. I think its only true to say that EJBs are only available inside an EJB container. But given that .Net/Windows is a container anyway its a fairly meaningless distinction.JamesLogicBlaze

    This is really the very minority in the Java world. How can they represent the J2EE platform?
  31. J2EE without a Container?[ Go to top ]

    I was talking about J2EE certified servers.
  32. J2EE without a Container?[ Go to top ]

    However, the J2EE services (such as JTA) are only available to applications running *in* the J2EE containers
    This isn't really true. You can use JTA and JCA easily inside any JVM, ditto JMS, JNDI and EJB 3 persistence. I think its only true to say that EJBs are only available inside an EJB container. But given that .Net/Windows is a container anyway its a fairly meaningless distinction.JamesLogicBlaze
    This is really the very minority in the Java world. How can they represent the J2EE platform?

    Well, now you're talking nonsense. So J2EE isn't flawed after all, since what James says is possible and people actually do that. What is flawed is how the majority of people (web monkeys) make use of what J2EE brings to the table (Remember how everybody freaking distributed every web app with 10 concurrent requests and then Rod & the Spring team showed them how you can make it work w/o it).

    I think people really forget that such things as J2EE are designed with much more in mind than what a tired mind of a studying guy can understand.
  33. Come back Floyd... please![ Go to top ]

    Does TSS not have editors any more? Can any old .NET fanboy post his uninformed, worthless theories right on the front page?
  34. J2EE without a Container?[ Go to top ]

    I think we should stop using TheServerside.com as they don't even put a filters on these articles and just allow an useless dumb ass to write anything he feel like...

    Dear TheServerSide.com, we are referring this site just becasue it contains technical stuff related to J2EE/Java. But if you continue to allow dumd ass to post any dumb article, you will harldy find anyone using this site and people start refering to other site...

    I pitty on you............
  35. J2EE without a Container?[ Go to top ]

    I think we should stop using TheServerside.com as they don't even put a filters on these articles and just allow an useless dumb ass to write anything he feel like

    Criticising the editorial policy is fair, and so is arguing robustly against the article. However, insulting the author in this was way is totally inappropriate - do we really want to sink to the level of Slashdot?
  36. J2EE without a Container?[ Go to top ]

    Criticising the editorial policy is fair, and so is arguing robustly against the article. However, insulting the author in this was way is totally inappropriate - do we really want to sink to the level of Slashdot?

    Steve - Good point. Coming up with a logical criticism against or for the original article is what we should be doing, rather than rant about the editorial policy.

    Widespread need for managing the lifecycle of components was felt, which resulted in development of containers and components managed by the container. Of course many thought that this was the right way to go including myself. After going through painful application development, reading Rod's book (J2EE Development without EJB) it makes sense that we don’t really need a container.

    Sure there are pain points associated with developing enterprise application in a container environment. But many organizations have invested millions of dollars in this form of technology. So I don’t think container centric application development is going to fade away any time soon even with availability of cool replacements like Spring. In today's context it may not be the best thing, but it really doesn’t make sense to move to a container less technology without justifying the associated costs.
  37. J2EE without a Container?[ Go to top ]

    Criticising the editorial policy is fair, and so is arguing robustly against the article. However, insulting the author in this was way is totally inappropriate - do we really want to sink to the level of Slashdot?
    Steve - Good point. Coming up with a logical criticism against or for the original article is what we should be doing, rather than rant about the editorial policy

    Well, maybe if instead of this:

    When studying for the MCAD certification, I found a fundamental architectural flaw of J2EE as a platform compared to .NET.

    it woulld have sounded like this:

    When studying for the MCAD certification, I found *WHAT I BELIEVE that is* a fundamental architectural flaw of J2EE as a platform compared to .NET.

    then, maybe those much too tired devs like me would not have been so fast on couterstrikeing.
  38. J2EE without a Container?[ Go to top ]

    it woulld have sounded like this:When studying for the MCAD certification, I found *WHAT I BELIEVE that is* a fundamental architectural flaw of J2EE as a platform compared to .NET.then, maybe those much too tired devs like me would not have been so fast on couterstrikeing.

    This is really the most important I have learnt since posted the article. Thank you!
  39. J2EE without a Container?[ Go to top ]

    it woulld have sounded like this:When studying for the MCAD certification, I found *WHAT I BELIEVE that is* a fundamental architectural flaw of J2EE as a platform compared to .NET.then, maybe those much too tired devs like me would not have been so fast on couterstrikeing.
    This is really the most important I have learnt since posted the article. Thank you!

    Thank me for what. For being rude ?
  40. J2EE without a Container?[ Go to top ]

    Widespread need for managing the lifecycle of components was felt, which resulted in development of containers and components managed by the container. Of course many thought that this was the right way to go including myself. After going through painful application development, reading Rod's book (J2EE Development without EJB) it makes sense that we don’t really need a container.

    IMO, when you're using Spring to control transactions as your components call each other, Spring is effectively acting as your container. Containers, in general, intercept the method call to your component object and do "some stuff" before your method, call your method, and then do some other stuff after your method before returning to the caller. Different containers use a wide range of techniques to accomplish the interception -- some generate proxy object wrappers, some use AOP-type techniques; there are many options available each with their own strong and weak points. As the state of the art progresses, containers are becoming better at performing this interception without getting in your way as a developer.
  41. J2EE without a Container?[ Go to top ]

    Ouch. That was a pretty dumb post. Keep studying.
  42. This is NOT helping![ Go to top ]

    Boys you got to understand that this cheap stuff is NOT helping to anyone, i mean seriously...
    You got to find more qualified editors..
  43. Really???[ Go to top ]

    Actually I cannot think which services You are refering are not available to 'pojo' applications actually? Obviusly JTA *is* available to any kind of application (plenty solutions starting with JOTM or recently JBOSS TS).

    On the other hand statement that comparable transaction or messaging services ara available to any kind of .NET applications are IMO odd. Doing messaging requires MSMQ, doesn't it? Having distributed transactions requires MSTS. Both are some kind of "containers" just like JE22 containers are. Moreover some kind of functionality which every J2EE container has by default - AFAIK are hardly available on .NET: I mean clustering, HA, load balancing, distributed security, standard ORM etc...

    So at the begining, especially if You don't know J2EE well, it might look like everything can be done on both platforms. But when it comes to details J2EE is far before when it comes to complex, business needs.

    Artur
  44. Access to JTA, etc.[ Go to top ]

    Assuming that you can find a standalone JTA implementation somewhere (I believe they exist), there is nothing to prevent anyone from writing a Java main and instantiating the JTA implementation inside it. You can then instantiate user code objects within that Java main, and have them call the JTA implementation when they feel like starting, committing, or rolling back transactions. You're in total control.
     
    Unfortunately, total control means your User objects are responsible for everything. After awhile, you might decide that having all those transaction lifecycle calls sprinkled throughout your user code is a pain. So you decide to delegate that task to something outside your user code objects, and have your user code objects focus solely on business logic. You write an "interceptor utility" into your Java main that, in between calls to your user code methods, invokes methods on the JTA implementation to start, commit, rollback, etc. the transactions at method boundaries. Your Java main has become a "managed environment." Essentially, you've just assembled your own basic-level app server.

    Of course, if the User objects decide that they still want to start, commit, or rollback transactions from their code, things can get messy real fast, since the places the User objects want to control the transaction might not be where your Java main wants to control the transaction.

    Because of this, you decide you want to enforce a good separation between the places that your app server is starting, completing and rolling back transactions, and the places where code running in your User objects starts, completes, and rolls back transactions. To enforce this, you prevent the User code from getting ahold of the JTA implementation. This is definitely a tradeoff -- it removes the "power" of your User code being able to start, commit, or rollback transactions whenever it might feel like it, but in order for your "interceptor utility" to be able to do its job without having the rug pulled out from under it, it's a reasonable tradeoff. The alternative is to go back to having the User code be responsible for managing everything. As long as the User code has the possibility of pulling the rug out from under the interceptor utility, there's no way the interceptor utility can fulfull the promises it's made to everybody's User code.

    In case you haven't guessed, the "interceptor utility" is one of the functions provided by a Container. If User code is starting, committing, or rolling back transactions anytime it feels like it, the Container is getting the rug pulled out from under it and it can't keep its promises to everybody's User code. For this reason, the EJB spec specifically states that app server vendors do not have to make the JTA implementation accessible to User code.

    It's all a question of tradeoffs. The value proposition of an app server is that it allows your User code to delegate certain types of work to the managed environment, allowing the User code to focus on application-related things like your business logic. In return for delegating those tasks to the managed environment, your User code accepts that it needs to avoid pulling the rug out from under the managed environment.

    Customers have had the ability to write their own Java app servers since circa 1997 when specs like JTA came out. (And even before then, they could do the same thing in C or C++ with specs like OTS from the OMG.) The reason there's a market for app servers, in my opinion, isn't because there's some nefarious plot on the part of infrastructure vendors to trick the world, it's because there are a lot of customers out there who don't want to write their own app server. If that doesn't describe you, by all means write your own...it's kinda fun.. :)

    Randy
    I work on WebSphere for IBM, but opinions stated here and elsewhere are my own.
  45. Access to JTA, etc.[ Go to top ]

    You can have JSF container, EJB container, Spring container and any other XYZ container on top of a de-containered J2EE server.

    But the architectural restriction that you have to break through the container wall (via web/ejb requests) to access most J2EE services will only make J2EE a limited platform for Web/EJB applications instead of a broader applications platform as .NET.
  46. Access to JTA, etc.[ Go to top ]

    ...you have to break through the container wall (via web/ejb requests) to access most J2EE services...
    Do you mean HTTP/SOAP/RMI or something else? Because you can have containers like Spring in-process. What wall are you talking about?
  47. Access to JTA, etc.[ Go to top ]

    But Spring won't give you those J2EE servercies (JTA, JNDI, J2EE connector ...) if it is running outside a J2EE container, will it?

    At the end of the day, you still need an EJB to access those J2EE services if you application is *not* a Web application.
  48. Access to JTA, etc.[ Go to top ]

    But Spring won't give you those J2EE servercies (JTA, JNDI, J2EE connector ...) if it is running outside a J2EE container, will it?At the end of the day, you still need an EJB to access those J2EE services if you application is *not* a Web application.
    This was the last nail. Case closed.
  49. Access to JTA, etc.[ Go to top ]

    But Spring won't give you those J2EE servercies (JTA, JNDI, J2EE connector ...) if it is running outside a J2EE container, will it?At the end of the day, you still need an EJB to access those J2EE services if you application is *not* a Web application.


    Uh, no, sorry. You don't need a J2EE container to access those services. You need to become more familiar with your topic before posting on a Java server forum, I should think.
  50. Re:Access to JTA, etc.[ Go to top ]

    But Spring won't give you those J2EE servercies (JTA, JNDI, J2EE connector ...) if it is running outside a J2EE container, will it?At the end of the day, you still need an EJB to access those J2EE services if you application is *not* a Web application.

    This person don't know what he is talking about. Better TSS resist from allowing this kind of posts because new or less experienced programmers may get false concepts on JEE.
  51. Access to JTA, etc.[ Go to top ]

    But Spring won't give you those J2EE servercies (JTA, JNDI, J2EE connector ...) if it is running outside a J2EE container, will it?

    Hey, have You ever written any J2EE or Spring application?
    Yes it obviusly will - it is exactly what spring is all about.
    At the end of the day, you still need an EJB to access those J2EE services if you application is *not* a Web

    Nope my frinend. RTFM at least before starting flame like this.

    Artur
  52. Access to JTA, etc.[ Go to top ]

    Not sure why you would need an EJB in order to access J2EE service? For instance, you can easily write a J2EE client application executing a transaction across a database and a queue by looking up all relevant resources – including a UserTransaction – in a JNDI tree. This is typically one way of bridging between a batch environment and an online environment.
  53. Access to JTA, etc.[ Go to top ]

    You can have JSF container, EJB container, Spring container and any other XYZ container on top of a de-containered J2EE server.

    Should be "de-containerised J2EE server".
  54. There's nothing preventing us from having a JEE container that will allow us to run stand alone applications with the full JEE stack available. We just don't have any implementation out there.Don't blame the specs after judging the implementations.

    Almost true, JBoss Embeddable EJB3 allows you to run the Java EE stack in a standalone app, junit tests, tomcat, or even in other app servers (to be tested).
  55. WHAT?!?![ Go to top ]

    Dude, the fundamental flaw in .Net is precisely the absence of a container.
  56. Waste of time[ Go to top ]

    This is an absolute waste of time... Spring Framework does it all so no point putting a '?' after "J2EE without a Container" ... hello Mr wake up!!!
  57. J2EE without a Container?[ Go to top ]

    Spring Framework has all the answers :)

    cheers !!
  58. Spring is magic...[ Go to top ]

    It does the coffee and so many things. It is said to be better than Viagra!
    Please refer to the fan syndrome :
    http://www.theserverside.com/news/thread.tss?thread_id=38129
  59. J2EE without a Container?[ Go to top ]

    Hooooooo.... another microsoft devotee. God help them and bless software industry!!!!!
  60. J2EE without a Container?[ Go to top ]

    Hmm. Must be office party night. No one at the switch at TSS.

    When <picking my nose>, I found a fundamental architectural flaw of .Net as a platform compared to J2EE.

    It appears .Net transactions require a ~1 GB GUI framework to run.
  61. J2EE without a Container?[ Go to top ]

    I have been on several large projects, all 'enterprise' level but I never used a J2EE container. My reasoning is this: I you need to scale out your application on to a multitude of machines you will need a J2EE container.
  62. Whats with all this anti .NET ![ Go to top ]

    I see so many Oh-he's-a-dot-net-fan posts ! Regardless whether the original post was uninformed or not, why do so many J2EE practitioners have this loathing for .NET ? Its not going to eat you .. lol. I bet half of these anti .NETters could not even draw out, on a piece of paper, the basic components that make up the .NET architecture. If you want to hate it, hate it for a reason, and let the reason NOT be *mob* driven.

    And yeah, calling the poster a "dumb-ass", says a LOT about you too, pal.
  63. Whats with all this anti .NET ![ Go to top ]

    Pramod,

    This is nothing to do with hating or attacking .NET - and you're right that it's silly to attack .NET if you don't know anything about it. Likewise it's silly to attack J2EE if you don't know anything about it, yet that's exactly what George Jiang did when he opened this thread.

    His arguments are based on his MCAD studies - that's Microsoft Certified Application Developer. So he's a .NET developer who decided to attack Java on the front page of one of the principle pro-Java discussion forums on the web. There's nothing wrong with a robust debate, as long as the participants stick to facts. Unfortnately what Mr Jiang said was just plain wrong.

    My guess is he's not dumb, he's just repeating what his MCAD trainer told him.
  64. Spring is a very nice and usefull framework. But, please enough of all this crap about Spring is J2EE without Container. This is just wrong information to be propagated, especially to up and coming J2EE developers. For example, isn't Servlets part of the J2EE repetoire? Show me how you can run servlets with Spring without a web container like tomcat (read CONTAINER) short of writing your own http server.

    Spring does indeed help decouple our dependency on some of the j2ee services like jta, jdbc, etc, but it is definitely not J2EE without Container.
  65. Hi,

    This page describes using JOTM in a client application using JNDI and RMI:

    http://jotm.objectweb.org/current/jotm/doc/examples/node3.html#SECTION00033100000000000000

    Question is: why do servers do not have a standalone java transactionmanager running? Performance might be the answer.

    Krgrds,

    Sanne
  66. J2EE is possible without Container[ Go to top ]

    It is possible to have functionality such as JTA, but without a container.

    Look into a new field called Aspect-oriented Programming.

    It is about modularizing concerns that crosscut other concerns. Transactions, persistance, authentication etc are typical concerns ("services") whose implementation cuts across several classes/components.

    To give you an idea... check out

    Java Aspect Components (a J2EE like product)
    http://jac.objectweb.org/

    Or check out AspectJ/Aspectwerkz

    We use J2EE Server to get a infrastructure, such as authentication, persistance, transaction management etc. With AOP you can get this but without the J2EE server.

    Further, using this thecnique you can easily replace the entire persistance implementation, or authentication implementation, as you choose.

    Interesting eh?
  67. J2EE without a Container?[ Go to top ]

    As per what I can see J2EE containers are the main reason for J2EE downfall.

    The Container providers are the main culprit for what ever adverse affects that the J2EE is facing today, If Sun had come up with proper specification to keep container dependencies to minimum or no dependency at all, then I am sure J2EE would be have been far more acceptable in the industry and still there is time for those who decide future of J2EE before J2EE fades away as a legacy Technology.
  68. J2EE without a Container?[ Go to top ]

    As per what I can see J2EE containers are the main reason for J2EE downfall.The Container providers are the main culprit for what ever adverse affects that the J2EE is facing today, If Sun had come up with proper specification to keep container dependencies to minimum or no dependency at all, then I am sure J2EE would be have been far more acceptable in the industry and still there is time for those who decide future of J2EE before J2EE fades away as a legacy Technology.

    This sort of comment reminds me of the frequent 'Java is dead' posts on forums such as Slashdot. Take a highly successful technology (such as J2EE) that has become the de-facto standard for server-side development (so much for 'more acceptable in the industry') and is still evolving and improving, and declare it dying against all the evidence:

    On dice.com there are over 13,000 j2ee jobs advertised - about 1 in every 6 jobs there. So much for 'fading away' or 'downfall'!
  69. J2EE without a Container?[ Go to top ]

    Probably there is nothing wrong with containers and there is no acceptance problems in the industry. Some startups have problems to implement j2ee specification and try to sell wrappers for mature tools as "simple" frameworks ( "J2EE without EJB" ). It looks like this aggressive marketing is very successful if it makes people to think this way. TSS and lame articles doe's a great job for this "light wieght" industry too.
  70. RE: J2EE without a Container?[ Go to top ]

    I don't agree. In .NET, if you want to make use of services such as object pooling, transaction, queuing then you have to use COM+ to host your component. And COM+ is conceptually no difference from a J2EE container. Furthermore, many APIs can be used w/o a J2EE container.

    Final notes, You should at least learn more about the COM+ stuffs if you want to pass the 70-310/320 exam to get your MCAD.
  71. RE: J2EE without a Container?[ Go to top ]

    I don't agree. In .NET, if you want to make use of services such as object pooling, transaction, queuing then you have to use COM+ to host your component. And COM+ is conceptually no difference from a J2EE container. Furthermore, many APIs can be used w/o a J2EE container.Final notes, You should at least learn more about the COM+ stuffs if you want to pass the 70-310/320 exam to get your MCAD.

    It is not just about .NET 1.1, e.g. you no longer need serviced component (ala COM+) to do distributed transaction in .NET 2.0. (FYI, I passed 70-320 in August).
  72. RE: J2EE without a Container?[ Go to top ]

    It is not just about .NET 1.1, e.g. you no longer need serviced component (ala COM+) to do distributed transaction in .NET 2.0.
    You just need Microsoft Windows. Good ole magical Microsoft Windows.
  73. RE: J2EE without a Container?[ Go to top ]

    I don't agree. In .NET, if you want to make use of services such as object pooling, transaction, queuing then you have to use COM+ to host your component. And COM+ is conceptually no difference from a J2EE container. Furthermore, many APIs can be used w/o a J2EE container.Final notes, You should at least learn more about the COM+ stuffs if you want to pass the 70-310/320 exam to get your MCAD.
    It is not just about .NET 1.1, e.g. you no longer need serviced component (ala COM+) to do distributed transaction in .NET 2.0. (FYI, I passed 70-320 in August).

    I meant "container transaction" when saying that. For the programatic transaction, you can always do JTA without the JEE container, just like .NET 2.0 can. The sum: the "design flaw" that you mentioned in the first place is a BIG flaw.

    You did passed the 70-320? Oh well, then I start to feel ashame of holding my MCSD.NET.
  74. RE: J2EE without a Container?[ Go to top ]

    I don't agree. In .NET, if you want to make use of services such as object pooling, transaction, queuing then you have to use COM+ to host your component. And COM+ is conceptually no difference from a J2EE container. Furthermore, many APIs can be used w/o a J2EE container.Final notes, You should at least learn more about the COM+ stuffs if you want to pass the 70-310/320 exam to get your MCAD.
    It is not just about .NET 1.1, e.g. you no longer need serviced component (ala COM+) to do distributed transaction in .NET 2.0. (FYI, I passed 70-320 in August).
    I meant "container transaction" when saying that. For the programatic transaction, you can always do JTA without the JEE container, just like .NET 2.0 can. The sum: the "design flaw" that you mentioned in the first place is a BIG flaw.You did passed the 70-320? Oh well, then I start to feel ashame of holding my MCSD.NET.

    George, I didn't mean to say s/t rude (so I want to recall the last statement of the previous post), but the point is that you should understand things more clearly before posting such a claim. Things like JTA, JMS etc. are just APIs, if you want to use them in your standalones then you just either buy, find, or implement them, and that has *nothing* to do with a JEE container. I think if you had made the original post a question then many people would have been more helpful to you. Good luck to your MCAD/MCSD.
  75. RE: J2EE without a Container?[ Go to top ]

    the point is that you should understand things more clearly before posting such a claim.

    I would say you should do the same yourself. You should really teach yourself first before teaching other people.

    The restriction of leading J2EE servers which I perceived as a fundamental flaw may not a big issue after all as I said in an ealier post. But they have nothing to do with your attack, even from a purely technical point of view.
  76. RE: J2EE without a Container?[ Go to top ]

    but the point is that you should understand things more clearly before posting such a claim.

    VI!
  77. Use Swing Instead[ Go to top ]

    You can get around the restriction of a container, by implementing your application using the SWING framework.
  78. JTA without container[ Go to top ]

    If you are looking for a JTA without need for a container, here is one:

    http://www.atomikos.com

    It's a funny coincidence that this thread be posted right now, since I just finished writing an article draft on this topic.

    It may be that J2EE experts know about J2EE without containers already, but most people don't. I agree that this is a pitty.

    Best,
    Guy

    http://www.atomikos.com
  79. +1[ Go to top ]

    It may be that J2EE experts know about J2EE without containers already, but most people don't. I agree that this is a pitty. Best,Guyhttp://www.atomikos.com

    +1. Thats the problem, in fact i find a lot developers fall into the boolean (Yes/No, Can/Cannot) thinking pitfall. Just because they don't know they will automatically assume it cannot be done. Cannot/never are very abosulte statements that should not be use especially in the technology space, even if we are absolutely sure something cannot be done today, some new technology/implemetation may just crop up the day after that voids the statement.
  80. J2EE without a Container?[ Go to top ]

    What about J2EE application clients and the J2EE Client container? J2EE.9
  81. OH MY GOD!!!![ Go to top ]

    Come on guys...i dont understand why you're wasting
    your time.

    George please go back to school, i can believe it
    .NET??? come on!! are you joking?

    You dont need EJB if you dont want it, you can
    use Spring like anyone else.

    I read your post, .NET has an implicit container
    called WINDOWS!!!

    And you can use JTA without a J2EE container if you
    want.

    Think before post!!!

    TSS...come on!! what's up? anybody can post anything?

    Gaston
  82. God has nothing to do with it[ Go to top ]

    First things First

    True, you can run J2EE services without a container, it's only a matter of finding the right workaround. Maybe the spec doesn't force you to use a container but, hey, aren't big corporations there to kindly helps us see how mistaken we are trying to live without their nice $10k servers?

    Regarding the MCAD thing. I am one test away from MCSD myself and all I can say is sweet jesus, be mercyful with the poor souls that actually believe the things MS writes in those manuals! I mean, you want something cheaper? buy an antipatterns book. VB people, welcome to paradise.
    I will not discuss why I decided to take this cert but, hmmm, I guess the title is soundly and stuff, "MCSD", but the contents are awful. You can get through just by reading MSDN.

    So, that's one mistake, to compare the common practice (J2EE in this case) with the flawed MS .net certs. Fortunately, MS got one thing right, .net is pretty versatile and you *can* do things the not-MS way.

    Back to the point. Windows is .net's implicit container you say? how wrong. Some people just assume that things running on top on Windows are evil, yes I am talking to you. I've been deploying in Windows machines for years (yes, Java apps too) with no problem at all and pretty good performance.

    Again, it's about finding the right workaround.

    Windows has very little to do with it. The only way to tie you with windows is to use COM/COM+ services for two phase commit transactions and such things, which is over complicated and unnecesary given the options. You can install just about any enterprise services (like Castle facilities/components/services) machine wide if you just throw the right assembly in the GAC, or just for your pleasure, if you toss it in your own application's folder. Container? what's that. I would say web server, instead.

    IIS Hater? yeah, me too!, that's why I use apache mod_cli and it works just fine, I can even debug in SharpDevelop and VS.NET

    Perhaps Mono isn't *just quite there* but it's rapidly maturing for the benefit of all.

    J2EE is great, no doubt, I love things like Webwork and Hibernate and sometimes Spring, but some of the people in the *community* seriously need to take a break (and restrain from the coffe machine). There's a world much much bigger than you think out there.
  83. well[ Go to top ]

    The only way to tie you with windows is to use COM/COM+ services for two phase commit transactions and such things,
    COM+COM+ Services for transactional handling
    IIS as webapp runner
    Abstracted Windows Interfaces into system hooks for pretty much everything under the sun...

    Windows in this case is the container, just without another layer of abstraction which would allow to run the app on AIX, Linux, BSD, Darwin etc...
  84. THIS POST IS FINE. WHY? JOSEPH IS FINE.[ Go to top ]

    This post is fine here on TSS.com. You may ask why I say this.

    I say this because I feel great when I see a lot of comments against a headline on TSS' home page.
    Once in a while, it is good to grab some George, have him/her post a trivial message here, and witness a lot of hits and comments. TechTarget, my employer, likes it that way. It's not about Joseph. Don't raise your finger. Joe is fine.

    Why do you complain, you readers? Just read and enjoy.
    Or should I make you pay for what you read today for free??
  85. Iearn a lot form this post[ Go to top ]

    Through the discuss between J2EEers and .NETers,I got a lot!
    please go on....
  86. An article with Zero ground work[ Go to top ]

    I have to wonder if TSS really edits any article that is being posted ... The article makes bold statements without any verification.

    -Jyothi.
  87. An article with Zero ground work[ Go to top ]

    I have to wonder if TSS really edits any article that is being posted ... The article makes bold statements without any verification. -Jyothi.

    Hey, jo kash,
    Read my post "THIS POST IS FINE. WHY? JOSEPH IS FINE." earlier on this thread.

    When you read, you will say it makes sense now. Okay. Go back. That is, Scroll up. Read finally. Next time, do not post before reading everything first. Realize that real estate is not free - is it? It is not. And our time?? it's too valuable... jo kash name jo kash name
  88. Container is misconception[ Go to top ]

    I think that the notion of a "container" seems to be a common misconception which introduces alot of confusion. Everything that seems to be handled by a typical "container" is cruss-cutting stuff for which we have AOP. So, in fact a container these days really is just some AOP-Framework and the meat behind it (everything else is legacy).
    From that point of view J2EE and .NET seem quite similar...
    The question is not about container or not, it is about how to implement your cross-cutting functionality!
  89. Container or not[ Go to top ]

    The question is not about container or not, it is about how to implement your cross-cutting functionality!

    Certainly true from a technical point of view, but for many java novices it is more complicated than that: I can't count the number of J2EE students I have had that think that J2EE can only use servlets, JSPs and EJBs. Most people don't know that POJOs can do just a fine.

    IMHO this is a major 'marketing' problem for Java and J2EE in general. Hopefully, this will change in the near future.

    Cheers,
    Guy
  90. Container is misconception[ Go to top ]

    I think that the notion of a "container" seems to be a common misconception which introduces alot of confusion. Everything that seems to be handled by a typical "container" is cruss-cutting stuff for which we have AOP. So, in fact a container these days really is just some AOP-Framework and the meat behind it (everything else is legacy). From that point of view J2EE and .NET seem quite similar...The question is not about container or not, it is about how to implement your cross-cutting functionality!

    And the functionality is injected, with AOP it is during compilation and with a container during the deployement and execution of the application. That's why container are heavy weight solutions compare to POJO using IoD/AOP.
  91. Container is misconception[ Go to top ]

    I think that the notion of a "container" seems to be a common misconception which introduces alot of confusion. Everything that seems to be handled by a typical "container" is cruss-cutting stuff for which we have AOP. So, in fact a container these days really is just some AOP-Framework and the meat behind it (everything else is legacy). From that point of view J2EE and .NET seem quite similar...The question is not about container or not, it is about how to implement your cross-cutting functionality!
    And the functionality is injected, with AOP it is during compilation and with a container during the deployement and execution of the application. That's why container are heavy weight solutions compare to POJO using IoD/AOP.
    And *when* ...
  92. Container is misconception[ Go to top ]

    ...with AOP it is during compilation and with a container during the deployement and execution...

    Oops, that sounds strange. What do you define AOP then? Nevertheless, this should be another topic.
  93. Container is misconception[ Go to top ]

    ...with AOP it is during compilation and with a container during the deployement and execution...
    Oops, that sounds strange. What do you define AOP then? Nevertheless, this should be another topic.

    Sorry what I said was totally wrong. I was trying to say that with AOP you configure the *injections* at design time versus a container which does it at runtime. However, the injections can both be done at runtime.

    Does it make more sense or I am still off the track?
  94. Container is misconception[ Go to top ]

    The "container" in a J2EE server (weblogic) is a object, or rather, a number of objects. One object per EJB. All communication to and from this ejb goes trough the container object.

    Container objects in turn implements the applicationservers Services, such as security, logging, transaction management, load balancing etc, and they communicate with each other.

    You could say that the container is a AOP-technique, although very rigid.

    So, a container does not "inject" any code, it is pre-made. It is more a matter of configuration. In AOP you define the points in which certain code should execute at design time. The actual code can be "injected" at compiletime, class load time, or even runtime.

    AOP, such as AspectJ or HyperJ is much more flexible than a J2EE container, but is perhaps not for mainstream programming yet... (soon though).
  95. Re: J2EE without a Container?[ Go to top ]

    When studying for the MCAD certification, I found a fundamental architectural flaw of J2EE as a platform compared to .NET.
    The word "flaw" should have been replaced with "difference" which is neutral. Some people get flamed easily with the word "flaw".
  96. Re: J2EE without a Container?[ Go to top ]

    No body in this thread has mentioned that there are other ways to get into the J2EE container in addition to HTTP or RMI, i.e. a JMS message (since J2EE 1.3) or a J2EE Connector 1.5 message (since J2EE 1.4). So you have five ways to get into a J2EE container: 1) HTTP request, typically from a Web browser (to a servlet) 2) Web service (a special kind of HTTP request) 3) RMI (EJB or in the case of Weblogic, non EJB RMI) 4) JMS message (to a message driven EJB i.e. MDB) 5) J2EE connector 1.5 message (to a MDB) After all, a J2EE server is the server in the context of client/server. EJB2.1 timer is one exception to this statement. After all, .NET is an application platform, and J2EE is SERVER application platform. period.