Joseph
> As a developer with roots in Smalltalk and C, I am leaning to WebObjects
> because it appears to be a next generation set of tools, but, of course,
Then you might appreciate both the Java support AND Objective-C support.
In particular the C in Objective-C is ANSI C, and the 'Objective' is the
same object model you have experienced in Smalltalk.
> I assume EJBs are not supported on WO. Can anyone describe how their
> functionality is handled in WO? Or point me to some reading that I can
> do.
If you have an EJB container, you can use WO to create the
EnterpriseBeans. Any app server that supports java can do that. You can
also access EJBs running remotely from a WOApp. Again, any app server
that supports java can do that too.
When applying EJBs to a problem domain, think OTS/CORBA or MTS/DCOM. The
EJB spec for SessionBeans is basically the CORBA model in Java. Instead
of accessing CORBA servers using CORBA client stubs and a CORBA ORB, you
use RMI to message between your EnterpriseBeans. Like CORBA objects you
cannot very easily have one EnterpriseBeans message another
EnterpriseBean and then have that EnterpriseBean message back (e.g. you
would get a deadlock in this example: A Employee messages a Dependent
for insurance eligibility and the Dependent's impl for that logic checks
its age AND then messages the Employee to see if the Employee has some
kind of family coverage). Like CORBA, each active EnterpriseBean tends
to run in a thread. Like CORBA, you cannot have two EnterpriseBeans or
EnterpriseBean clients talk directly to each other (there is an
intervening wrapper object) and inter-thread or inter-process
communication as well in most cases. In short, this isn't a lightweight
way to interact among hundreds or thousands of objects in a single
address space. Therefore like CORBA objects, EnterpriseBeans are not
ideal for fine grained objects. That is, they are not great substitutes
for hashtables fetched en masse from database as WebObjects EOF
'EnterpriseObjects' are. But all of these things that make them
unpleasant for fined grained objects make them ideal for large grained
objects (objects you don't have many of: e.g. better for 'Departments'
than 'Employees'; objects that are stateless and non-persistent; and
objects you don't have to message real often): A Tax computer, a
demographics calculation, a authentication server, a custom datasource.
Some elements of an app server like WebObjects might also make good
candidates in theory for EnterpriseBeans (such as the WOSessionStore,
WOStatisticsStore, and the app-side WOAdaptor itself). [In the case of a
demographics calculation, you might implement your EnterpriseBean by
fetching and manipulating a huge number of 'EnterpriseObjects' fetched
with EOF. An example of RMI API on such an EnterpriseBean might be:
averageNumberOfTexansBuyingProductX(Product prod) ]
Note that since the EOF in WebObjects provides an awful lot of the stuff
you need in an EJB EntityBean implementation (something not currently
required by EJB servers in the current 1.0 spec), a company wishing to
have a short time-to-market on an EJB container compliant with a FUTURE
EJB spec would be well advised to implement their solution using
WebObjects. Currently the few EJB containers currently out there don't
support EntityBeans very well, if at all.
>
> I have seen no mention whatsoever of using OODBMSs with WO. Does
> anybody do it? If so, which, how? Is it as straightforward as I think
> it would be?
Subclass EOObjectStore. See the EOObjectStore class ref for more
information. WebObjects includes a kit that implements the
EOObjectStore API on top of relational databases (e.g. the EOAccess
framework). Implementing a EOObjectStore on top of a OODBMS ought to be
a LOT easier than doing EOAccess!
What kind of OODBMS are you using now?
>
> I am inclined to program in ObjC for the back-end. Is this a bad idea?
> Will Apple be moving strongly in the Java direction at the expense of
> ObjC? How stable is Java vs. ObjC? Is there any functionality missing
> in the Java implmentation? Performance issues?
Java performance these days aint bad. WO classes are in Java as most new
people to WO prefer that and can find references available to it.
However if you want to develop in Objective-C you have a lot of company
in veteran NeXT developers as well as internal Apple ones. Objective-C
is great language to have around even if you do go Java since if you
have a legacy C API to pull in, you can use it to wrap the C API in a
subclassable Java API using Objective-C and the Java bridge. JIT Java is
getting pretty close to Objective-C but as a native C based language,
ObjC is still faster (just not many times faster like it was in the
early days of Java). The APIs available to Java and ObjC programmers are
basically the same. The differences are related to language limitations
on either side (no class name spaces in ObjC, no class posing in Java).
I have no idea about futures and I'm not going to speculate. WebObjects
4 supports Java, Objective-C, WebScript and through TipTop's kit: Tcl,
Perl, Python as native implementation languages used whole or in part to
write WebObjects apps. The language flexibility is what I'd call a
significant advantage to WebObjects over other solutions.
>
> Are there XML classes available?
WOComponent is an excellent class for generating dynamic pages
regardless of the target mark-up language. Check out the references to
WOComponent, WOGenericContainer, and WOGenericElement and you should get
a good idea of how easy it is to add support for your own XML widgets
(or even SGML for that matter).
>
> Can anyone recommend reading that I might obtain. I read the IDC paper,
> much of the archive of this list and all the Internet marketing that I
> could find.
Did you check out the summary or buy the SQLi study (200+ pages)?
d
