Since this is becoming a more general discussion, I can no longer resist from commenting. This is a difficult discussion with many different opinions, depending on where you stand. All points made up until now are each valid, next is just my opinion and experience.
Summary: REST with JSON or simple XML as encoding over HTTP/HTTPS using standard or custom authentication/authorization is the future. Given enough high quality standards based tools/frameworks in Smalltalk doing a protocol client or server is quite easy. Most of the necessary tools/frameworks are already there. If we have to encourage something, it should be finishing or cleaning up those basic parts. Over the years I (like probably many others in their niches) have implemented, published and maintained in Common Lisp: an XML-RPC client and server, an XML parser, an HTTP client and server and SOAP with WSDL. As well as many others internally (memcached client, JSON parsers, REST frameworks, ...). Of course, even if it is fun and not that hard to implement them, not everybody has to do that, reusable code is nice to have. That is why I was happy to find that Smalltalk/Squeak/Pharo in 2010 now has all that I need and even lots more that I didn't expect (except HTTPS but there is some renewed activity there). I know that VisualWorks has a couple of very nice frameworks/libraries for some of some classic enterprise technologies. That does not yet mean that Pharo needs them (all) as well. I think what the Pharo project is doing, a clean/mean open enterprise ready Smalltalk is way more important. I started a couple of months ago on VW, tried Pharo as an alternative and was very pleasantly surprised by the overall quality: I don't want to go back! In our company we decided many years ago to stop using over complex enterprise technologies like EJB, most of J2EE, SOAP, especially WSDL, even XML (ever tried one or more namespaces, encodings, binary data ?), as long as we are in control. Sometimes you have no choice, but these parts of a project then typically become a PITA. Most SOAP+WSDL interfaces that you come across are automatically generated with 1 click from internal .net classes without any external API design, let alone cross platform testing. Even in the Java enterprise world there is a strong movement towards simpler technologies. And as others mentioned here, many internet APIs are going in the same direction (or at least offer multiple variants, I like Amazon's AWS APIs a lot for example). So, for me, the fundamentals, clean/mean image, excellent IDE tools, fast vm, good networking, basic http(s) client and server, crypto, xml and json parsing, db access, deploy options, documentation and of course community are the most important. My 2c, Sven On 01 Jul 2010, at 11:33, Janko Mivšek wrote: > Hi guys, > > Commercially speaking I see a need for a better Web Services support in > Squeak/Pharo, here I mean both SOA and REST Web Services. > > XML-RPC is closer to SOA Web Services so this project could be changed > to improve current SOAP and add the WSDL support? > > We currently have SoapOpera [1] and SoapCore [2] from Masashi Umezawa, > maybe his work can be a good starting point to extend it and make a > really good and useful SOA Web Services implementation in Smalltalk? > > I namely use SOA Web Services (SOAP+WSDL) quite frequently on my > commercial projects in VisualWorks. With good tools it is certainly the > easiest way to connect to other systems and to other > languages/technologies. > > And remember: SOAP means Simple Object Access Protocol. While that > Simple is nowadays very questionable, that Object Access is certainly > not. I mean, SOAP is a protocol to pass messages between objects in > different OO systems. Smalltak as an OO system therefore needs a good > SOA Web Services support! > > [1] http://map.squeak.org/package/d17a284e-6a2d-4fea-b4bc-65c82bc45001 > [2] http://map.squeak.org/package/dab9b621-00d2-41c3-966c-458bf62b8008 > > On 30. 06. 2010 20:53, Stéphane Ducasse wrote: >> Philippe this is good that you reacted. The point of esug is to support >> actions >> that will help people so probably XML-RCP is not a really good choice. >> Now what would be good is to have a map of current techno and their support >> for smalltalk. Then act to fill up the gaps. >> >> Stef >> >>> >>> It doesn't strike me as a forward looking investment. IMHO XML-RCP is >>> something that will only get used less in the future, not more. The >>> value you get from an XML-RCP implementation will become less and less >>> as fewer services support it. >>> >>> But then again ESUG is free to spend their money on what they seem fit. >>> If they disagree or decide the current use is big enough, I have no >>> problem at all with this. >>> >>> Cheers >>> Philippe > > > -- > Janko Mivšek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
