Discussions

EJB programming & troubleshooting: Is it possible to deploy WL5.1 clients without installing WL?

  1. It seems that some 30+ Mb of class files are req for clients of WL5.1 EJB's. Is this really the case? Also the docs mention m3.jar which doesn't exist, is this just the result of jar ing the classes dir?

  2. Yes it's possible... I've already done it. Jar up the <root>\weblogic\classes\weblogic directory. It will create a jar file of approx. 9 MB and that is the only directory off the parent classes directory that you need.

    Greg.
  3. Opps forgot too mention... You'll also need the weblogicaux.jar and weblogic510spX.jar file out of the <root>\weblogic\lib directory. Just make sure in the client classpath that you follow this order:

    <path>weblogic510spX.jar;<path><weblogic classes>.jar;<path>weblogicaux.jar

    as the service pack should always be first followed by the weblogic main classes and then the J2EE libraries in weblogicaux.jar.

    Greg.
  4. Thanks!

    I still find it a little strange client programs are so 'heavyweight' when all they are basically doing is weblogic rmi?


  5. Yeah it is strange but the problem is that all containers including Weblogic implement the specs in different ways... Weblogic has a proprietary protocol t3 that they bind the RMI calls to at runtime but they also have a neat feature called http tunneling so that you can do an RMI call through port 80.

    We are currently testing this with a JavaBean deployed on a Netscape IPlanet webserver doing a JNDI lookup to an EJB running on a seperate Weblogic server. Both servers are behind their own firewalls for security in the production environment and we are hoping that by using http tunneling we won't have to punch another hole so to speak in the firewalls to support the t3 protocol.

    Greg.
  6. I like the tunneling options and they do mention in their docs that you can use the

    client -> servlet -> ejb

    path to allow lightweight clients but some of the benefits of j2ee would be lost here. ( They also mention its possible to psuedo-rmi by generating stubs that talk to the servlet )

    But really, t3 is just another protocol, does it really need 15+ Megs of java code to implement?
  7. But really, t3 is just another protocol, does it really need 15+ Megs of java code to implement?


    Yep! It's proprietary...

    >> client -> servlet -> ejb

    I debated that route but what I came up with was:

    client -> Netscape JSP (or servlet) -> JavaBean on Netscape -> Session EJB on Weblogic -> DAO objects on Weblogic.

    So far works well, is OO and cleaner for the JSP developers to do data access calls, and should be scalable. One of the JSP developers here actually put the calls to the JavaBean in a loop for testing it as he was getting some funny errors when making multiple calls to it. Turns out he was not calling the JavaBean properly as I took his test loop and increased the iterations from 5 to 50 to 1000 to 10000 without failure so I know it works.

    Greg.
  8. Well by my reckoning, classes+lib = 40Mb, therefore 15/40 ~= 37% OF their product is the t3 protocol? :-)

  9. Maybe... :(

    We tried to only jar up what we thought it would need but after trying unsuccessfully over ten times (each time adding more classes to the jar after a new exeception was reported) I finally gave up and jarred the whole <root>\weblogic\classes\weblogic directory. Without knowing the dependancies and not having a tool to find them all properly and cruising the Weblogic docs for some answers (there were none that I could find) I bit the bullit and did the large client install on the Netscape webserver as I figured it would be a one time thing anyways.

    I don't know if what I did was correct or not (it seems to work).

    You know... my opinion has always been that this EJB thing is so overly hyped that it's only really useful if you have the client and the server on the same machine and even then you really don't need EJB to do what real world apps need to get done. I only started using EJB here after some long research and an even longer learning curve recently anyways so it's still debatable whether we will continue on this track.

    Our main app that is used daily by our salesreps in our Advisor Zone at www.agf.com is a servlet based app calling custom data access objects to do lookups for account information. I only recently created Session EJB's to wrap the DAO that was first written back in 1999 by me and even they aren't even being used yet as there is no need to use them!

    Entity EJB's were never an option as the corporate database is too normalized and the number of records in some of the tables we have to access hits 50 million or more so this means explain plans on SQL, hints in your SQL, stored procedure calls, etc... just to get a decent performance hit. This would kill an EJB type of architecture as you would have an EJB for each table that joins to another then another then another... you get the idea. I'm pretty sure Weblogic would come to a crawl after the first five of 50 million rows!

    I thought about creating views on the database schema that would go against multiple tables to return a result set and then this could be mapped to one entity bean as a single virtual table but again creating straight DAO objects in Java that run queries through JDBC and the Weblogic JDBC connection pool was still easier and faster anyways so I dropped that idea. I might resurrect it again if it proves to be feasable.

    It would seem to me that after seeing all the posts about this issue here on TheServerSide.com that a Session EJB calling JDBC (and rolling your own queries) that returns a collection of value objects that represents the result set is the *proper* way of doing it. In fact that is exactly what our DAO objects do for Account Inquiry without the EJB overhead.

    Greg.
  10. Yes, I don't think j2ee is mature enough yet to bet the farm on. Still I can see how design wise going down this path makes sense, its up to the app servers to do the hard work and make entity access run at an acceptable speed.

    This probably means some sort of optimised binary object data store managed by the app server, a sort of RDBMS for objects.