Re: Enterprise using WO

>>
>> We are using Hiberate now for several reasons:
>> 1) Every Java Software Factory I've been in contact with is using  
>> it, and you can get people already using the tool in several domains
>>
>
> That's a good point.  But then every Java software factory was big  
> on using plain-old JDBC a few years back as well ;-)
>

In our case our partners have always used some kind of ORM (Smalltalk  
and Java). The real issue here is the different paradigms and the  
need to understand them. In the case of EOF our developers had a very  
hard time to understand/accept the way it operates (they had previous  
experiences with Toplink) objects always live within an EC, creating  
an object requires to insert it in the EC,  the architecture flaws,  
those kind of things.


>
>> 2) The current and future EJB spec is going towards the POJO model  
>> based on Hibernate (at least Gavin King -Hibernate's father- is in  
>> the J2EE JCP). Maybe then I will use EJBs :-)
>>
>
> Yes, that's true.  Finally, and probably as a result of the threat  
> from .Net, the folks directing J2EE are making some changes.

I agree with Mark here, it has nothing to do with .net. The JCP  
finally accepted Entity Beans were wrongly designed and they are  
coming back to the old ORM concept.


>
>
>> 3) EOF is great but it has an architectural problem that I guess  
>> is based on the fact the EOF was initially conceived as a desktop  
>> 2 tier client server architecture. In particular I am talking  
>> about the way EOF handles database connections. EOF was not  
>> designed to share a pool of db connections among users. You can  
>> actually achieve that by replicating the EOF stack (one per user ,  
>> or one shared among some users) but by doing that you are  
>> replicating the EOF cache, nasty. Once you replicate EOF stacks  
>> you break optimistic locking unless you provide a change  
>> notification mechanism among stacks, nasty again. Same happens  
>> when you deploy several instances of the app (you always do that)
>>
>
> Yes, good points again.  Although I wonder why (if) you really need  
> per-user database connections.  Of course, and as you suggest  
> different instances obviously use different connections.  EOF could  
> surely use an integrated change notification system (based on one  
> or the two or three third party solutions).

We need to scale. We do not need one connection per user. We need a  
framework that can dynamically scale through adding connections. We  
currently have a pool of EOObjectStoreCoordinators but is now  
providing one OSC per user (each user is using multiple ECs...ie.  
multiple pending transactions). This is something we are tunning ("n"  
OSCs to serve "m" users), but anyway, the issue is the same. Because  
EOF was not redesigned to accommodate the needs of current  
applications you end up creating multiple EOF stacks (each one with a  
cache that gets out of sync). Even if you have two OSCs, your are  
duplicating the cache, and remember EOF is nothing but a big cache,  
it caches everything.

I am now playing around with the idea of extending EODatabase and  
override all the snapshot related methods and plug in a distributed  
cache (OSCache, etc.) Has anyone done this? Any locking/concurrency  
problems?

Change notification among instances is something you cannot escape  
from. As you say you can use EOF based ones (David Neumman's) or  
other non EOF.


>
>
>> I can get developers with Hibernate knowledge in the market right  
>> now.
>>
>
> That's true, although I would assume worthy developers would be  
> able to pick up EOF without much trouble (i.e. if they had a good  
> understanding of OO, O/R Mapping, SQL, frameworks, ...).

Back to my first point. This is exactly the issue I found. It is not  
easy for people to switch between paradigms, although it is very easy  
for them to switch between tools that apply the same paradigm.
In fact we've been through this. We are using EOF for our largest and  
most critical system. But I would not do it again, mainly because I  
do not have signals from Apple in terms of a future redesign of its  
architecture.
>
>
>>> Also, why did you choose a Web interface for a factory automation  
>>> system?  I am just curious about your application / domain.
>>>
>>>
>>
>> We wanted to be able to access the tool using a web browser from  
>> anywhere.
>>
>
> Sure, that makes sense.
>
> You seem to have chosen very suitable technologies for your needs.
>
> However, the one thing about Hibernate that concerns me when  
> compared with EOF (or Cayenne in the future) is the lack of support  
> for client-side business objects in a thick client.  As I said,  
> this is probably not a concern for your application.  I think the  
> next step for enterprise applications - when a company's staff get  
> frustrated using the same browser-based interface to their  
> enterprise Web application as their customers do - is the move to a  
> thick client (for the intranet).
>
> From my (limited) understanding of Hibernate and other Java  
> persistence technologies, most thick client business processing in  
> a three- (or n-) tier architecture is done by remoting (remote  
> method invocation).  There doesn't seem to be anything comparable  
> to EOF's client-side business objects (by way of distributed  
> editing contexts).  My concern is that remoting is ok for simple  
> processing of a few objects, but when the interaction becomes more  
> complex it would be come too slow and inappropriate.
>
> So in short, when "we" move to thick clients on the Intranet (for  
> our n-tier enterprise Web application), solutions like EOF and  
> Cayenne would be most advantageous.  Again, someone please correct  
> me if Hibernate offers a good solution for client-side business  
> object in a thick client (besides a two-tier approach).  Or if  
> there are any other technologies / products that enable client-side  
> business objects.
>

Hibernate supports detachable objects, so you can carry the object  
with you to the other JVM and reattach it again later without using  
proxies and remote calls (this I think you should do it yourself, but  
will be supported out of the box in the next version of Hibernate)

I agree with you that the web is pretty bad in terms of Human  
Computer Interaction (and it is even worst from an OSX user  
perspective :-> )
But still web apps have many advantages (WAN deployment: HTTP,  
firewalls and proxies)

Also I do believe the next big thing in enterprise software is thick  
clients but not as we know them today.
We will have a new standard soon from the WWW covering what is now  
covered by Mozilla XUL, MS XAML, GNUStep Renaissance and the Cocoa- 
based solution Apple is using to deploy the iTunes Store.

cheers,

Alejandro M. Ramallo
IT & Relationship Management Director
Nobleza Piccardo S.A.I.C.yF. (BAT Group)

_______________________________________________
WebObjects-talk mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/webobjects-talk