On 5/18/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> Hmm, wouldn't a remote method call on the pier object solve this
> requirement?
>
> E.g.
>
> ClientUser {
> public Object doComplexOperation() {
> return callPeer("doComplexOperation");
> }
> }
>
> ServerUser {
> public Object doComplexOperation() {
> // ... actually do it
> }
> }
>
Yes - I was looking forward to when I have lots of these and thinking
about how to manage it, which you touched on via:
- building an extendable matrix of command/operand combinations. But you
- are right - if we get too many commands, it will become unmaintainable.
and
- Also as ClientCommand does its own dispatching, it should be possible
- to implement custom ClientCommand/ClientCommandHandler pairs that use
- the same communication channel, but extend standard basic inter-tier
- "language". I guess we may even provide an explicit extension point in
- the handler ["executeUnknownCommand(ClientCommand)" or something].
Just off the top of my head, would a command context parameter be
useful for managing large sets of commands? The default (i.e. no
context parameter) could be the cayenne context, and have "context
handlers" at the server end that split the commands into more
manageable groups - just an idea, and haven't thought it through too
much :-) Hmmm, may even then be able to register a different Cayenne
context handler to do custom stuff if necessary/desireable. Then
again, maybe I should just get back to my day job :-)
BTW: I am looking at putting a little prototype together for one of my
co-workers - anything you would like me to work on to help move the 3T
stuff along (not saying I will be given the time, but just in case)?
>
> Andrus
>
>
> On May 17, 2005, at 10:01 PM, Derek Rendall wrote:
>
> > On 5/18/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> >>
> >> On May 17, 2005, at 9:33 PM, Andrus Adamchik wrote:
> >>>> What about the ability to support other server side logic (say some
> >>>> ejb's, SOA based components or just some "sensitive" stuff that
> >>>> should NEVER be passed to client to look after)?
> >>>
> >>> We are not in business of replacing web services, RMI and such,
> >>> however I am planning to add support for executing server-side
> >>> business methods from the client "peer" objects.
> >>
> >> Derek,
> >>
> >> Do you have something specific in mind here?
> >>
> >> Theoretically you can feed data from any type of data services to
> >> Cayenne client. But if such data service has no predefined query
> >> language and update mechanism, using Cayenne would probably buy you
> >> nothing compared to say web service stubs compiled from WSDL. Or am I
> >> wrong?
> >>
> >
> > Ahhh - specifics :-)
> >
> > OK. We have a couple of web based apps (one WebObjects and one
> > WebSphere). The users are complaining about standard html as an
> > interface - "rich GUIs" are becoming a requirement (they are also
> > complaining about the WO scalability/performance in some cases). So,
> > enter in Eclipse RCP - looks great. Now, we want to use an ORM for our
> > data layer, and make sure that clients DONT have direct connections to
> > the database (enter in Cayenne 3T). We also have cases where we want
> > some of our complex logix to sit on the servers and be called from the
> > clients. One reason is data set size - we dont want large sets of data
> > transported down to the client if we can get a nice big fat server to
> > process it (pass some data in from the client, and the resulting
> > action requires significant resources to complete). At the moment this
> > could be logic sitting inside a webserver session, a call through to
> > an EJB (would use the EJB thread to pass in datacontext?) or possibly
> > a webservice. I know we could call these directly from the client, but
> > I would prefer to use the datacontext that already exists on the
> > server side in thos cases where I can.
> >
> > Make sense?
> >
>
>
This archive was generated by hypermail 2.0.0 : Tue May 17 2005 - 23:23:35 EDT