Re: Accessing EJB's from Objective-C?
Re: Accessing EJB's from Objective-C?
- Subject: Re: Accessing EJB's from Objective-C?
- From: Matthew Lehrian <email@hidden>
- Date: Mon, 18 Mar 2002 02:22:21 -0500
On Sunday, March 17, 2002, at 11:08 PM, Jim Roepcke wrote:
On Sunday, March 17, 2002, at 06:39 PM, Matthew Lehrian wrote:
Hi all,
I've been struggling with an application architecture in which I can
provide a JSP-based web UI and a Cocoa application. I'd like to build
a multi-tier system. Ideally, I'd be using WebObjects (if WO for ObjC
was still around :-( ). However, now my sights have set on EJB. The
web side is a no-brainer, but what's the best way to access EJB's from
Cocoa? My options include:
I really don't understand that logic. You don't want to use WO because
it doesn't have ObjC (only Java), yet you want to use EJB, which is
only Java and not ObjC.
Why EJB? Why!? (as I scream in horror down the dark alley persued by
thugs wearing Sun, BEA and IBM schwag)
To be clear, I would prefer to write entirely in ObjC. I started down
this path and have created a client-server protoype of my application.
The problem is, I want my web app to be able to access the model, which
is now built into the client application in ObjC. I could write 2
independent sets of database access logic, but that doesn't make any
sense to me. And I can't move my ObjC model layer serverside because
there's no container. I thought about writing my own ObjC serverside
container, but that seems like a lot of work (that was option #4).
So now, since there is no ObjC middleware (thanks, Apple), and I want to
build a stateful middletier, my only option is EJB. Now that I've
settled on EJB, I can use a free EJB server, like JBoss, rather than
WebObjects.
I want to use EJB because I prefer the stateful middletier programming
model. I have the luxury of designing my on database schema, so I am
planning to use CMP. Plus you get security, transaction control,
concurrency control, etc. for free (kind of :-)
Why your distaste for EJB? It really isn't that complicated and
provides a significant improvement to middletier design where you want
to use a stateful middletier (obviously, this isn't necessary in all
situations). If you stick to the spec to build your beans, they're
fairly portable.
At least I didn't say I was going to use that Java-based .NET
implementation :-)
3) Use SOAP. My concerns here are session management and programming
model. I'll probably end up writing my own remote object
infrastructure based on SOAP so the client looks like it's working
with an object and the SOAP code is hidden from the client. This
There is an XML-RPC client and server for ObjectiveC, and a number of
very good XML-RPC servers for Java. XML-RPC is simpler and has
stronger interop than SOAP.
Not that SOAP is bad.
If there's no other way, and I end up writing a stateless middletier,
I'll most certainly take this route. Has anyone out there done this
already, and if so, any tips?
Jim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.