A webservice commonly does this: * authentication (optional) * a service/method is invoked with an optional set of arguments * the service returns a result
Why not abstract your service system to allow SOAP + REST + XML-RPC + JSON + AMF ? As long as the interface is abstracted, it doesnt matter anymore and for every problem you can pick the best tool for the job.. Evert Dustin Mercer wrote: > > Something I have done in the past is to create a hybrid solution. One > of the biggest advantages of Web Services is of course its ability to > be consumed by just about everything. That being said, Java can > consume web services! I have found creating Web Service Facades that > FDS connects to can keep both sides happy. You get the performance of > AMF to the client side, and you get to keep your services in one > central location (as long as you don’t try to recreate business logic > in java, just make it the middle man). One definite downfall is your > J2EE server will do the parsing and translation of the web services > (this can impact all users as the system scales if the server isn’t > very powerful, or the services are poorly designed), as well as the > consumption of services in java isn’t always the easiest thing. On the > flip side of that your java server can also do the exception handling > and send better exceptions to the client side. This may be a good > middle ground for those searching for the benefits of both. > > Dustin Mercer > > -- www.rooftopsolutions.nl -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
