Welcome to the MacNN Forums.

depolitic · Jun 19, 2004, 10:18 AM

Hi - I am cross posting this as it is a very cross list question.

I am building a blog for my own use, using JSP sql tags on the web end, I however believe this is not recommended as this mixes the view with the model. I currently have a good MVC system going only using JSP one page view one page model one page controller. It is simple and it works.

I however wish to move up a little and I was hoping to be more J2EE architectural as they say by using more heaver components. It is however these heaver components that I am at a loss about. J2EE is a bit of a jargon soup JDBC, Beans, Session Beans, EJB's Stateless Beans, Servlets, etc etc etc.

My question is what and how do I use as the technology for my model. Do I create a bean and get it to execute my JDBC calls and then pass the vales back to my JSP pages? Or is their a better approach?

Eventually I would like to create a ObjC / Cocoa client in conjunction to a Java web interface from which I could update my blog a kind of text editor which saves its content online. This being my final objective what do you recommend as the best approach for doings this in regards to SQL calls.

Also can I perform these calls between Cocoa and J2EE via the Cocoa-Java bridge? or is their another or better way?

I am looking at the System architecture and how it will be designed before I leap any deeper with this project of mine.

I am also currently using MySQL I however would like it to be portable across DB, I have heard of things like Hibernate which abstracts SQL calls to an DB independent way. Will I avoid porting issues if I use a bean and JDBC will they abstract the SQL for me?

I am a little lost and in need of some orientation.

Kristoff · Jun 19, 2004, 12:39 PM

Must Have: Core J2EE Patterns, by Crupi, Malks, Alur

And, I recommend JBoss 3.2.3 with Jetty as the web container.

depolitic · Jun 20, 2004, 05:56 AM

Their must be a more simple answer? Then read a book on J2EE enterprise. Any one have any other suggestions.

I am a web developer with basic programming skills I am not computer scientist. So I need a more direct path for the dummies like me.

Kristoff · Jun 20, 2004, 03:07 PM

Come on.......the book isn't a frigging novel. It's a cookbook. Buy it, and skim over the relevant sections. Or you could fumble about in the dark--if you prefer.

Arkham_c · Jun 20, 2004, 07:41 PM

If you want to integrate Cocoa later, but you don't want all the overhead of EJBs, consider something simpler. Java Beans, some sort of object persistence (Torque or Hibernate), and Velocity templates. Then use Web Services (SOAP) to talk to Cocoa.

Kristoff · Jun 20, 2004, 11:26 PM

You're saying to avoid the overhead of EJBs by marshaling and unmarshalling objects to XML??? I use SOAP all the time. It's slow as hell and unreliable. The only time to ever use it is if you are forced to.

Arkham_c · Jun 21, 2004, 08:42 AM

Originally posted by Kristoff:
You're saying to avoid the overhead of EJBs by marshaling and unmarshalling objects to XML??? I use SOAP all the time. It's slow as hell and unreliable. The only time to ever use it is if you are forced to.

Not the performance overhead, the learning overhead. Cocoa has built-in support for SOAP/Web Services. It does not have a smart stub for EJBs without using the Cocoa-Java bridge, which is flaky at best. I've found SOAP/web services to be very reliable, and for most cases the performance hit is negligible to overall performance.

One should also consider the development commitment of J2EE versus a simpler solution, and resource requirements of running a J2EE container versus something simple like pure Tomcat. Defining local and remote interfaces, learning about JNI lookups, different kinfs of session beans, etc. has a steep learning curve, and the benefits are only realized by a very few high-end applications. For most web applications, a templating language and servlets will prove to be the best solution.

cocoa_coder · Jun 22, 2004, 06:56 PM

dude this is so simple. you have three options.

1) just have your cocoa app directly update the database on the server since its only you using it.

2) a better approach is to directly invoke a servlet or jsp.
You can encode a url with all the parameters you need and send that from the cocoa app to the java side (servlet jsp whateveR). if you need data to come back such as status or whatever just have your java app shoot back xml or some comma delimited string with your information. When your cocoa app receives this then just parse it. I suggest you do a little research on how http works and perhaps utilize it for communication.

3) your third alternative is to use apache's axis which makes a java class a webservice and you can invoke a webservice from your cocoa app (actually even an applescript can do this.) if u need more info hit me up lw@cocoalabs.com

depolitic · Jun 22, 2004, 09:46 PM

cocoa_coder thank you, I will have a look at option two, because I think it make the cocoa application the view the servlet the model and both are in-depended, and then I could change or remove a component without breaking.

MadBrowser · Jun 25, 2004, 10:49 AM

My suggestion - don't use EJB.

About 2 years ago I got really into it and re-wrote a Web app to use EJB 2.0 CMP Entities and Session Beans.

The architecture has so many freaking files (each bean has 3 .java files plus entries in various XML descriptors) it is impossible to maintain.

Performance isn't terrible but nothing to write home about.

I am currently re-writing the site using WebObjects and EOF and I've fallen in love...

Since I know many folks don't want to use WO, take a look at Java persistence like Hibernate or Cayenne. Two good tools, much easier than EJB. Heck, EJB 3's design is based on Hibernate.