Kevin, Thanks for showing interest in these issues...I appreciate...we hope to answer some of the questions we have been debating. Please see comments below:
> Just to give you a little background : The application involves hundreds of > Busines Objects and complex business rules. > The number of different ways in which a client can manipulate Business > objects (POST methods or RPC calls) is quite large (ofcourse we are planning > to use Facades and BusinessDelegates to avoid too many granular actions). Couple questions/assumptions: - Am I right in assuming that a good number of these business objects need to be accessible to the Client application individually even counting the facades you create? Sounds like you could have 100 or more 'endpoints'. - And these individual 'endpoints' need to be accessible from the Swing application? >>> Probably Yes..Hiding all the business objects behind the facaded and delegates may turn out to be tough. - If so, then the creation of each individual endpoint needs to be pretty efficient. That is, it can't take hours of coding time to add a new endpoint. (I'm using the term 'endpoint' as it is a part of the WSDL spec with a particular meaning). >>> We have been considering using "reflection" to make method calls on individual business objects from a common "facade" based on the "method Name" and "Parameter List" passed. Might work for simple methods calls and primitive parameter types, but could be a problem for more complex types...still not sure how we will solve the "objectID (object reference)" problem. - Another question is how reliable is the application? If you ABSOLUTELY CANNOT lose a message, then HTTP in general may be a problem. It's not designed to provide a guarantee of 'once and only once' delivery. That being said, many times the loss of a request isn't as big a deal as it first seems. The Swing application can sense a problem and just retry. The real problem could occur if the message is delivered, but the response to the swing application isn't conclusive so it resends. >>> Yep....But I think this may not be a big issue in our application. Resending the same command may be fine. - Another question is are you tied to HTTP? If you are on an intranet and can use some other transport you may be able to get better reliability (and potentially performance). More on this below. >>> The application will be available mostly on the internet so I guess we need HTTP. > Our first stab at the design was to model all Business objects as Java > Classes (We have good reasons not to use EJBs, but that is a different > story). For some reasons, the front-end has to be a java swing application. > We will have ValueObjects that will be passed back and forth between server > and client. Non-EJB's are fine - though they have advantages if you need to manage transactions and roll-back things that fail mid-stream. Sending Value Objects seems a good decsion - they aren't tied to any particular app on either the front or back and they are easy to model in XML if desired. > The transfer of value objects data between client tier and web/app tier > could be (1) XML (2) Serialized objects. > Sending XML representation of ValueObjects would increase our 'payload' by > factor of atleast 5 (due to XML tags etc.) and also we have to write > conversion routines. Our ValueObjects hierarchy is a bit complex. (JAXB > could help here though.) > On the other hand sending Serialized Value Objects tree seems straight > forward and efficient. So we decided to give it a shot. Don't know if that > is the best way. A third option you haven't mentioned is using JMS (assuming you want to stay J2EE-based). JMS provides higher reliability than anything you would send over HTTP. Since JMS is transactional it can guarantee 'once and only once' delivery. Plus it works great for carrying objects in general. It also provides you a way to persist requests if the back-end goes down in the middle of something. But JMS messages would need to be 'pulled' by the server. What you may need to do would be have the client send a JMS message into a queue, then have another app that locks on the queue waiting for a message. This app would receive the message, invoke a request to Struts (assuming you need to use struts on the server) and then get the response and package it back up to return on the queue. Things would honestly be easier if you just had your server application locking on the queue directly and you didn't use Struts (of course, then you wouldn't be here!). >>> Didn't even think about using JMS.!! Will look in the possibility of using JMS.. thanks Another option would be to have the Swing app use Axis/SOAP, but sending the SOAP messages over JMS instead of HTTP. Interestingly, I just posted a weblog entry on this approach on O'Reilly's oreillynet.com site a couple days ago (See "SOAP over JMS - What does it mean and why should I care?" http://www.oreillynet.com/pub/wlg/2171 ). The advantage of this is that you use Web Services client and server code, and the Transport is JMS underneath - though the web service isn't significantly different. Axis has this capability, but it's pretty new. Again, this approach implies not using Struts necessarily. So getting back to using Struts and having your 'View' components actually serializing objects (or sending XML). If you need to use Servlets/JSP/HTTP for whatever your reasons are, using Struts is as good (or better) than anything else for all the reasons people like Struts to begin with. You just have to have the 'view' components be different. The differences I can see in using serialized objects versus XML would be: - XML is easier to read and debug - If you built an XML-RPC or SOAP interface in front of Struts, you'd be able to repurpose the 'server-based' services using clients on other platforms. - Using SOAP may mean writing serializers/deserializers for both ends of the communications, but not necessarily. Axis has a built-in 'BeanSerializer/BeanDeserialzer' that you could use that would likely be able to handle all that work. You could feed 'beans' into the web service and get them back out without having to create the XML yourself. That is, Axis knows how to serialize/deserialize beans with no extra code. - Using Axis for communications would require that you write a bridge between the Axis server and Struts (assuming you used Struts). This may not be as hard as it seems since they would both be webapps running on the same server (or, if you are a do-it-yourself'er you might be able to write a Struts request processor that understood SOAP requests - which again may not be that hard, I haven't looked too deeply into this). SOAP requests are after all HTTP POST's against a particular URI (which could be /whateverTheAction.do format). The only real difference is that the SOAP request devlivers its data in a SOAP envelope using XML instead of the normal name/value pairs. In the end, I think it probably comes to this: - The upside to using serialized objects is that it's not that hard and you already know how to do it. Learning curve is shorter, risk is lower. - The upside to going through the effort to create a Web Service approach is: 1. That the 'Web Services' you build will be reusable for other types of client applications if you need to write them. 2. That having the Swing client know how to access data from web services will allow you to access other web services from it (which are popping up everywhere). 3. Since most of the effort is one time learning and building, once you get up to speed you'll have a great tool to do other things with. Reliability is likely to be the same for either - HTTP is probably the 'weakest link'. >>>> Web services is definitely something we are considering...It is just that we are still in the learning stage on web services...As you mentioned before even with Web services we may end up with large number of "end points". There is also issues to be addressed when it comes to creating "stateful" web services etc... Tough call. Here's what *I'd* do <GoingOutOnALimb> If I had time I'd implement the solution using Web Services. When I say time, I mean about an extra few weeks. I just think the long-term value of what you're building and the skills you'd have would be greater. They day will come when you'll be sorry you didn't. Also, if I were going to do this using Web Services and SOAP, I'd reconsider using Struts <Gasp!>. All the taglibs (and more importantly, the way it receives and parses HTTP POSTS) are all very HTML and 'form' oriented. Now if Struts could be made to parse a SOAP Envelope as it's incoming request, then that would be different. </GoingOutOnALimb> Of course, this approach is riskier too since you've never done it before. If your management has a very low tolerance for failure, then that may be worth considering. As they say, 'Plan on throwing one version away, because you will'. (Of course the second version will go up in much less time and be much better...) I'd be interested in hearing what others on the list think of my assessment <he said as he reached for his flame retardant shorts...>. >>> WOW....Lots of heavy stuff...I guess we have lot more work to do experimenting and prototyping... Thanks once again for the input.. Kevin ---- Kevin Bedell Author, Struts Kick Start > Regarding using the SOAP, we are seriously looking at it as an option. > (Trying to get upto speed on web services is the first step...I guess : -)) --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --------------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
