Hey Aral, You have some valid points, I defnitely agree with you on services that may need additional security, or services that you don't want to expose to the general net population. Also agree where projects have very large queries and the size of the SOAP overhead outweighs the actual data being sent. I also love AMFPHP, but I still get a lot of mileage out web services in Flash for a variety of uses, couple examples:
1. Quick prototypes of applications while the services are still being developed on the server side. It allows quick iterative development while both teams (server side / client side) can work separetly or in tandem with minimal communication necessary between teams. 2. Internal/private applications not exposed to the general net, that require periodic maintenance. I've found that web services are pretty easy to follow even for intermediate to novice Flash developers. 3. Closed system applications - kiosks, interactive exhibits, or other types of apps where the system is a closed loop and the environment is totally controlled. The main reason I was looking for a WSDL to AS stub was that it would have been really helpful in the initial architecture phase of several projects I was working on recently. Referring back to item 1 above - each day the server dev team makes progress/or changes on an app they simply push out their changed services and WSDL - and if I had a WSDL to AS generator I could quickly update my stubs and prototype app with a couple clicks. That would be great to test things and verify data and what everything is supposed to do all without a single email or phone call between teams. Once everything is locked down, its not difficult at all to then move things over to remoting or whatever would be best. Actually one team I was working with, they deployed all their webservices through a pretty slick .NET framework which made it really easy to choose how to talk to the server, either SOAP, REST, straight XML or name value pairs - whatever worked best/fastest for the given task. I've also found webservices in the client handy in a couple cases where a client had made a webservice interface as a proxy to a more complicated server side application and controlled access through accounts where the end user provides login/validation credentials. Anyway - just some thoughts on what I consider some still valid and useful cases. :) Regards, Rob > From: Aral Balkan <[EMAIL PROTECTED]> > Reply-To: Open Source Flash Mailing List <[email protected]> > Date: Sat, 4 Nov 2006 16:01:53 +0000 > To: Open Source Flash Mailing List <[email protected]> > Subject: Re: [osflash] WSDL to ActionScript > > Personally, I don't see the use of consuming web services on the > client. First off, you cannot have any sort of hidden information in > there so that rules out using this for commercial web services where > you have a secret key/developer key/etc. unless you want the world to > know it and use up your quotas. If you're not going to use it for > third-party services, then you're probably going to use it to talk to > your application server. In which case, why are you using a heavy > protocol like SOAP when you could be using Remoting, REST or even > good-ol' fashioned variable-encoded strings over HTTP? If you are > using third-party web services, you should really be consuming them > on the server side and implementing security, redundancy, etc. there. > > The only use I see for consuming web services directly from the > client is if you're using a completely open third-party web service. > I think there are a few stock ticker services that are usually used > to show off client-side web services in Flash that fit the bill! > > Aral > > On 3 Nov 2006, at 19:40, David Holroyd wrote: > >> Is anyone interested in making a wsdl2as tool (like the Apache AXIS >> WSDL2Java tool)? >> >> Here's a start: >> >> http://osflash.org/wsdl2as >> >> <snip> > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
