> > - We created stateless session beans for each sub-system or major > > functionality (goods specification, filing, warehouse and sub-subsystems > > like access points to specsheets and things like that). > > > Good. But these are not mapped to client-side use-cases right? I mean, > they expose system functionality, but are not tightly bound to what the > client wants to do.
It's a compromise between exposing system functionality and client use cases. Because the client is rich we can do many things that we otherwise would have to do on server, for example lots or rule checking. Sometimes the subsystem fa�ade just doesn't provide an adequate interface that the client wants. Our solution was to add another layer of indirection: warehouse subsystem with some subsystem-specific interface, but a project/remote-client specific layer is also introduced 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 :-) > > - We wrapped these session beans under an Apache SOAP layer. It's easy, > > just create the soap deplyment file and Apache SOAP lets you call all > > remote methods or the ejbean. > > > Is it important that you use SOAP, or is any HTTP-protocol ok? Well, it is. I mean it's overkill to let fat clients talk with websphere via IIOP and it seems not to work, specially when you're outside subnet boundaries (maybe we could tackle it by installing Component Broker but it's not an easy task). So we need a way to talk with remote websphere server and SOAP comes to my mind. Actually we had a win32 Excel client, and also a Lotus Notes client and Notes has a relatively good java support and we already do gymnastics in Notes and we needed a way to integrate Excel with Notes and the server! We tried to let Excel talk with server via MS's SOAP toolkit, but anyway I'm not going into details but after all we turned to using JIntegra and let a java module talk with server and Notes, but then still some cracks we saw in our architecture. At the end we forgot about Excel and simulated it with Swing :-) So at first we needed SOAP, how could Excel talk Java with websphere? But now we don't. > > - We use dataobjects for server-client communication. Client creates a > > dataobjects, sets some values and passes it to server and vice versa. > > Note that it's also easy to marshal/demarshal dataobjects via Apache > > SOAP. In worst case you have to write some custom marshallers but the > > important thing is that server deals with pure no-ejb no-soap normal > > dataobjects and also the client. > > > If a usecase involves several of the above-mentioned subsystems, then > will the client have to do several calls? Or do you SSB's that model > these on the server? No as described above. > So, it seems that what you want really is some way to > * access the server using transfer objects > * use HTTP for firewall reasons > * hide server-implementation details from the client > > If so, then I think I have a better idea. Use WebWork: > http://sourceforge.net/project/webwork > > With the recent ClientServletDispatcher servlet addition, you can now > instantiate actions on the client, send them over to the server (in > serialized form), and have them execute on the server. When it's done, > the action is sent back, so that the client can access any result data > and display it. > > This has a number of advantages: > * optimized format, since serialization is used > * no format converters needed. Pure Java > * can go through firewalls since HTTP is used > * since execution is on server-side, actions can use fine-grained calls > to EJB's, i.e. there's no need to optimize the SSB's for remote calls. > You can even use local interfaces! > * Actions can get data-transfer objects from many entities or session > beans at a time > * regardless of how complex the use-case is, i.e. no matter how many > session beans are involved in it, only one network call is made. (VEEERY > IMPORTANT!) So you have a set of action objects that trigger SSBs locally on server and use java serialization instead of heavy XML. Cool! Do I have to write the actions or is it automatic? I also worry about evolving objects, it's sometimes tricky manage server/client object versions so serialization sometimes breaks. 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? > All in all, it's a killer solution for Java clients wanting to access > J2EE-servers easily and in an optimized manner. Seriously it seems to be. Congrats :-) I should look at WebWork quite seriously :o) Ara. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
