me too plz. this is something that we're currently looking at too. -Tim -----Original Message----- From: Robert Taylor [mailto:rtaylor@;mulework.com] Sent: Friday, October 18, 2002 1:27 PM To: Struts Users Mailing List Subject: RE: Why Use Serialized Value Objects instead of XML or SOAP? (Was .... Can V in MVC be Swing in Struts?)
If you do take this offline, please include me in the messages. I find this topic very interesting and I like your solution for minimizing endpoints. [EMAIL PROTECTED] Thanks, robert > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:Kevin.Bedell@;sunlife.com] > Sent: Friday, October 18, 2002 1:08 PM > To: Struts Users Mailing List > Subject: RE: Why Use Serialized Value Objects instead of XML or SOAP? > (Was .... Can V in MVC be Swing in Struts?) > > > > > > >>>> 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... > > > Prakesh, > > Here might be a way to minimize the number of endpoints you need. > > I've done some work implementing a 'Command' design pattern using a Web > Service. The goal is to miminize the number of Web Service 'end points'. > Here's basically how it worked: > > - I created a single 'end point' for the web service. It provided for ONLY > an XML document as the data type. > - In the XML I had an element name '<commandtype>'. > - On the Web Services server, whenever a message was received, I used a > factory method to get a 'CommandProcessor' for whichever command type > showed up. > - I then implemented 'command processors' for each type of command. > > The value in this was that it made my web service definition simpler. And > if I needed to add a command to the web service, I no longer needed to add > another web service 'end point'. > > For me, processing all the input as XML documents wasn't an issue because > of the nature of the application. You had indicated that you are using > 'ValueObjects' - well, it might be possible for you to define each value > object with a property called 'commmandType' and do something similar like > this: > > - Define a java interface called Command (or something) with a single > method pair called 'get/setCommandType()' > - Have all your value objects implement this interface. > - Create a CommandProcessor interface as well with a single method called > 'processCommand()' > - On the web services server, read in each object, cast it to a > Command and > then use a factory class to build CommandProcessors for each type of > command. Something like: > > String cmdType = ( (Command) valueObject() ).getCommandType(); > > CommandProcessor cp = > CommandProcessorFactory.buildProcessor(cmdType); > > cp.processCommand( valueObject ); > > Basically, this code casts the value object to a Command and extracts the > commandType. It then uses the commandType to get a CommandProcessor from > the CommandProcessorFactory. Finally, it passes the value object into the > command processor for processing. > > This approach may be able to significantly reduce the number of > Web Service > 'end points' you need - assuming you can use a single endpoint defined > using the Axis 'beanserializer/beandeserializer' types. If you > can define a > single endpoint that can serialize and deserialize any kind of value > object, then this will work. (I guess that's a pretty big 'if'...). If you > can't then the approach of using XML documents instead of value > objects may > be the easiest way to do this - though there may be another way around it. > > > > Let's take this discussion off-line if you have other questions - I think > we're wondering off-topic. > > > > Kevin > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > --------- > 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> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
