Ara Abrahamian wrote:

> that reduces remote calls and starts a local transaction. You really
> can't forget about client specific needs, I've once tried to abstract
> away client differences for html and wap clients and it really doesn't
> work. So I do think a client-friendly layer is needed. The important
> thing is that you should know what you're doing :-)


1) I agree, you can't ignore client-specific things. Just try to make 
sure that you have localized these things in such a way that it doesn't 
wreck the overall architecture.
2) Yes, you should know what you're doing :-)


> So at first we needed SOAP, how could Excel talk Java with websphere?
> But now we don't.


So, any Java/HTTP thingy would work :-)


> So you have a set of action objects that trigger SSBs locally on server
> and use java serialization instead of heavy XML. 


Correct.

> Cool! Do I have to
> write the actions or is it automatic? 


You write actions. How could it be automatic?? I guess you could come up 
with some meta-language that is converted into Java code, or use a 
scripting language (yes, WebWork supports JavaScript as action 
implementation), but I'm not sure if that'd buy you that much.

> I also worry about evolving
> objects, it's sometimes tricky manage server/client object versions so
> serialization sometimes breaks.


Then either serialize your stuff using SOAP (?) or write custom 
serialization that is difficult to break. For example, you could have a 
data transfer object base class with readObject/writeObject that 
utilizes the getField/putField API (very very change resilient).

> I also do not quite understand the last point. You mean the client stub
> code knows that it can conserve subsequent requests to various SSBs and
> send the request in a single call? Or you mean I can write an action
> that calls various SSBs?


Your action can call various SSB's without any additional overhead, 
since all the calls to them are local anyway.

/Rickard

-- 
Rickard �berg


_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Reply via email to