Report: Scripting languages lag in Web services support

Discussions

News: Report: Scripting languages lag in Web services support

  1. Burton Group analyst Richard Monson-Haefel recently wrote a report examining the features of HyperText Preprocessor (PHP), Perl, and Python (The P-Languages). The report concludes that the P-Languages are well suited for web development, system administration and limited integration; however when it comes to Web services support, they are far behind more mature languages such as Java, C++ and C#.

    Do you use scripting languages to consume web services, or provide them? What have your experiences been?

    Read P-Languages power the enterprise, but weak in Web services support

    Threaded Messages (32)

  2. Perl has webservices support[ Go to top ]

    I believe SOAP:lite for perl provides webservices capabilities in perl both from client and server perspective. Don't know if anything is availble for Python and PHP.

    Bijan
  3. Perl has webservices support[ Go to top ]

    Yes, but SOAP::Lite is a SOAP implementation, doesn't include any second generation web services support, etc... I've written a few Perl XML modules for CPAN, Perl has one of the best communities out there, but I think it lacks a standard body like Java. Perl has various modules to support WSDL, XSD, etc..., but truly doesn't come close to Java's support.

    One can argue though that it has the right tools for 80% of anyone's requirements, that is probably true.

    Ilya
  4. Perl has webservices support[ Go to top ]

    One can argue though that it has the right tools for 80% of anyone's requirements, that is probably true.Ilya

    Which is exactly why a lot of users could consider ditching the requirement for SOAP and using something like XML-RPC instead, which is simple and functional, and coincidentally has quite a few implementations (in Perl, anyways).
  5. Perl has webservices support[ Go to top ]

    One can argue though that it has the right tools for 80% of anyone's requirements, that is probably true.Ilya
    Which is exactly why a lot of users could consider ditching the requirement for SOAP and using something like XML-RPC instead, which is simple and functional, and coincidentally has quite a few implementations (in Perl, anyways).

    Well, in a lot of cases, REST will also do, but I think there is a huge issue here. The biggest use of web services, is application integration. There are many aspects during EAI implementation where one would wish for some standadization (as SOAP is) and other WS integration technologies, as the 2nd gen web service specs are now providing. I don't think that XML nor Web Services per say is some ground breaking technology that everyone should adapt, what is amazing here, is the standadization around it, participation by the "Big Players", as well as it's adaptation. Standadization is the key here and is the difference between enterprise development and programming.
  6. Well, in a lot of cases, REST will also do,

    101% agreed. You don't need more to exchange XML data (ahem, excepted when you want it to be secured, with ACLs, transactional, etc. and you don't want to carry this burden...).
     but I think there is a huge issue here. The biggest use of web services, is application integration. There are many aspects during EAI implementation where one would wish for some standadization (as SOAP is) and other WS integration technologies, as the 2nd gen web service specs are now providing.

    102% !
    I don't think that XML nor Web Services per say is some ground breaking technology

    1000 % !!!!
    :-)
     that everyone should adapt,

    No no please don't !
     what is amazing here, is the standadization around it,

    Well, IMHO that's just like Canada Dry : it tastes like a standard, looks like it, but actually it's fake more or less !

    I don't see W3C as a real standardization body (remember that TBL can put his veto on anything if he decides to ? looks more like a dictature than to a consortium to me...).

    Moreover the most of what they actually do puts us in a mess instead of deserving progress !
    I don't like HTTP excepted for browsing "basic" documents (I don't ask a book to be animated and produce sound, and I have the same expectations when it comes to HTML pages... I don't open a book to buy a product or manage documents), that's the most crappy thing I've seen when it comes to dynamic interfaces, and I don't talk about using it for middleware... Nonsense : carry the whole HTTP burden when you have OO middlewares, webstart, etc...
    And now that damn XML everywhere...
    Just like we did not have enough problems !!!
    :-)
    participation by the "Big Players",

    I remember a time when companies like Borland were riding other horses... Not too far ago...

    Also, if you think about it, most "big players" have no advantages at all in standards, especially when it comes to computer science (we're the only ones that work for "free" - the OSS current).
    They earn more in imposing their stuff and locking-in clients to their proprietary stuff !
    The politics of M$ about this is clear : spread the market and put everything upside down each 2 or 3 years to get your sales up.
    Then, you're in front of a "de facto" standard that deserves nothing but... incomes !
    .doc is the best (and most popular) example I know : I'm running OSS only even for the desktop (linux, openoffice etc), and I admit I had to keep my OEM windows dual boot as well as an Office install to be able to read some of my client's and partner's word documents. Pitiful.

    Now imagine .doc is an open standard... Woaw, that would not be cool for microsoft since lots of people would not even ask themselves if they should switch to open source "clones" of MSWord !
    But that would be cool for me, the final customer...
    as well as it's adaptation.

    Stuff like HTML and VB are probably the most used "languages" on earth. They are crappy stuff that makes us work much than we should do.
    I don't see anything else in adaptation than... adaptation :-)
    It's a fact that does not "prove" anything, and it has many justifications...
    In our case, amongst them are fashion and marketing I guess...
    Standadization is the key here and is the difference between enterprise development and programming.

    I would have thought that "enterprise development" was "supported" by "programming"...
    You "implement" an "architecture" using a "technology"...

    Have fun,

    Remi - ISO compliant
  7. Perl has webservices support[ Go to top ]

    but you end up with a fine-grained api with xml-rpc which can make it slower overall...
  8. Support for What?[ Go to top ]

    <sarcasm>
    I don't see a problem. The whole point of web services/SOAP/XML-RPC was that we don't need no stinkin' ORB-like software to create or use web services. Any language can easily create an XML string, open a socket, send the message on its way, and easily parse the results. We shouldn't have to rely on the existence of a library to use WSs, since scripting languages are *far* superior to Java when it comes to manipulating strings.

    If I needed a standards-based framework to do the work for me, I would have stuck with CORBA.
    </sarcasm>

    Seriously, what a joke. Web services were sold as the "easy" CORBA, since it didn't require a client or server-side ORB, especially for scripting languages that had generally poor ORB support.

    Now they're complaining that they need exactly the features provided by an ORB, and they're not available. Sheesh.

    Mark
  9. PHP5 SOAP power![ Go to top ]

    you can see here [http://www.zend.com/php5/articles/php5-SOAP.php]the new SOAP extension that is available from PHP v.5, I found it so powerful and easy to use.
  10. PHP5 SOAP power![ Go to top ]

    Again, SOAP is not in question here. People think that SOAP is the definition of Web Services. It's one if it's standard implemenations, but SOA is so much more than a communication protocol like SOAP or XML-RPC.

    Ilya
  11. Support for What?[ Go to top ]

    No one's complaining. It's just a sponsored report paid for by Java companies to point out something they have that perl and Hypertext PreProcessor don't have. It's another sign of the nervousness over Rails, et. al, I'm guessing.
  12. SOAP has become the province of the uber-engineers, where every possible requirement from every possible Fortune-100 client must absolutely be available out of the box. That is why SOAP (actually, the WS-* standards) will fail. TCP/IP succeeded because it was simple; SNA failed because it was massively over-engineered.

    Developers don't want to have to spend years to understand what amounts to a communication protocol. Unless there is an immediately recognizable benefit, any spec which is too complex will fall by the wayside. It's really that simple. SOAP is, in itself, pretty simple. WSDL starts to cross the line into pointless verbiage, and UDDI takes that cake... But even then, the academic engineers at IBM and M$ weren't satisfied. It seems to me that every week or so, there's another WS-* standard published.

    RESTful apps, XML-RPC and Hessian/Burlap recognize that you can handle most of your need with a simple interface. If you need non-repudiability, it's pretty easy to implement using digital signatures. No need for a commitee to meet for the next three years to make sure every possible need is met. Just make sure YOUR needs are met...

    Communication protocols need to be as complex as necessary, but NO MORE. And neither IBM nor M$ have a good track record in this matter...
  13. I don't know if I agree with that. Yes, there is a new standard published very frequently, but you don't have to use any of this. For simple web services, use SOAP, you need security, use WS-Security, etc... Basically they are just standardizing all aspects of web services, which IMO is a good thing.

    I've worked for numerous large corporations, and it seems as if they are filled with a lot of developers that think they can do it better than the standard, and in some instances they definitly can accomplish the job quicker and maybe more efficiently, but development is a very small cost as compared to the maintenance and enhancement part where the standardization and supported protocols/technologies play a huge roll.
  14. Ilya,
    You make a good point, but I disagree with you since your argument seems to promote that the following of ANY standard is a good thing, but I believe that following this WS-* craze is even worse than making it on your own with some mistakes to fulfill your specific needs.

    This WS-* Fiasco is going to be garbage soon, and the cost of maintaining this garbage is going to be really costly especially if you rely on some product stack to supply you with the WS-* requirements...

    my .02c
    AT
  15. You make very good points, but...
    :-)
    Just make sure YOUR needs are met...

    The point is precisely you're not alone. Otherwise you would not even need XML btw, because you would not have anything to "exchange" with anybody else than yourself :-)

    Your example about digital sig. is revelatory : what if you use techno A for doing this, and your partner techno B ?
    You have to develop something in-between... Unfortunately you did not feel the need to be compliant with any standard at the time you designed the system...
    That's why a standardized approach is important IMHO.
    And also because re-inventing things is often not a good idea (at least don't do it again if it already works fine : then improve it even more !).
    I'm not smarter than engineers that worked before, I'm sure they already thought of my problems (in most cases it's true), and I prefer to concentrate on my business logic instead of doing IT for IT... so I learn (instead of producing a non-viable thing) and apply generic and proven principles.
    I think everybody does it that way in the other industries (non IT).
    Communication protocols need to be as complex as necessary, but NO MORE.

    That's where you may make a mistake : WS-* and CORBA are more than a communication protocol actually.
    They tend to be (I also think that one of the two, guess which one, will fail, but that's another question) transversal architectures that adresses various issues recurrent to distributed systems.

    Recurrent issues often have recurrent solutions, I'm sure you are convinced and like DPs for example.
    Well, think about CORBA as an "architecture-level design pattern" for designing distributed, OO, secure, transactional, etc. distributed systems.
    It includes a comm. protocol, which is often seen as the "basis", but to me it's a small part of it. The most beautiful thing in CORBA is precisely that it has a solution to almost all YOUR needs :-)

    Have fun,

    Remi
  16. PHP is a future SOA tool of choice[ Go to top ]

    I would urge all SOA developers to look very seriously at PHP. According to Richard Monson - Haefel Analyst from the Burton Group PHP will become the mainline tool for developing SOAs. Quoting Richard: "If Web services become as ubiquitous as people claim they will, it seems natural that PHP will become a mainline tool for developing service-oriented architectures (SOAs), at least on the implementation end."

    When will TSS stop posting rediculous articles?
  17. PHP is a future SOA tool of choice[ Go to top ]

    I would urge all SOA developers to look very seriously at PHP. According to Richard Monson - Haefel Analyst from the Burton Group PHP will become the mainline tool for developing SOAs. Quoting Richard: "If Web services become as ubiquitous as people claim they will, it seems natural that PHP will become a mainline tool for developing service-oriented architectures (SOAs), at least on the implementation end."When will TSS stop posting rediculous articles?

    There's a big difference between "the mainline tool" and "a mainline tool." Are you disagreeing with his assertion? Why?
  18. PHP is a future SOA tool of choice[ Go to top ]

    I would urge all SOA developers to look very seriously at PHP. According to Richard Monson - Haefel Analyst from the Burton Group PHP will become the mainline tool for developing SOAs. Quoting Richard: "If Web services become as ubiquitous as people claim they will, it seems natural that PHP will become a mainline tool for developing service-oriented architectures (SOAs), at least on the implementation end."When will TSS stop posting rediculous articles?
    There's a big difference between "the mainline tool" and "a mainline tool." Are you disagreeing with his assertion? Why?
    How does having every tool being "a mainline tool" help?
  19. PHP is a future SOA tool of choice[ Go to top ]

    I don't understand the question. Where did every tool become a mainline tool?
  20. PHP is a future SOA tool of choice[ Go to top ]

    "There's a big difference between "the mainline tool" and "a mainline tool."
    I don't understand the question. Where did every tool become a mainline tool?
    <disclaimer>I am ESL</disclaimer>
    Agree that there is a big difference between "the mainline tool" and "a mainline tool", however, consider the following:

    In Java News: java will become a mainline tool for developing SOA architectures.

    In PHP News: PHP will become a mainline tool for developing SOA architectures.

    In Pyton News: Python will become a mainline tool for developing SOA architectures.

    I would say that in all of the above word-combination "a mainline tool" carry a hint to be regarded as "the mainline tool".

    I am not sure why you feel that PHP will become a mainline tool for developing SOAs. Or, rather, what other languages do you see become mainline tools for developing SOAs?
  21. PHP is a future SOA tool of choice[ Go to top ]

    Well, I'm not Richard Monson-Haefel, so personally, I don't think Java "will become" a mainline tool for SOA - for me, it's THE mainline tool. Yet that doesn't speak to much more than anecdotal experience on my part.
  22. PHP is a future SOA tool of choice[ Go to top ]

    Well, I'm not Richard Monson-Haefel, so personally, I don't think Java "will become" a mainline tool for SOA - for me, it's THE mainline tool. Yet that doesn't speak to much more than anecdotal experience on my part.
    It is always nice to see some commitment to java on part of TSS ;-)
  23. The neat thing about SOA is, the architecture/pattern is language/platform agnostic. Depending on what type of developer community (PHP, Java, .Net) the enterprise/organization or small sized companies will use that language to build loosely coupled systems. SOA allows the developer communities to co-exist in a way without having to go through the motions of rip-n-replace model. Then the question is more like "what about the interoperability between these languages/systems ?"

    raghu
  24. Now I get it![ Go to top ]

    See this article.
    April Fool's: TheServerSide changing focus

    This has got to be the best 04/01 joke ever!
    Here we all thought TSS had posted an April Fools joke, but they were serious. The joke is on us.
  25. It forgot to examine the R-Language - Ruby.
  26. It forgot to examine the R-Language - Ruby.

    Ruby has full-featured libraries for SOAP and XML-RPC in its standard distribution.
  27. Burton Group analyst Richard Monson-Haefel ..

    OK, stop right there. That's enough to tell most of us everything we need to know.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  28. Burton Group analyst Richard Monson-Haefel ..
    OK, stop right there. That's enough to tell most of us everything we need to know.

    Hm... would having Richard Monson-Haefel on a JSR experts' list be a kiss of death than?

    http://www.jcp.org/en/jsr/detail?id=241
  29. 1)Build a client in Swing which conforms to XForms.
    2)Extend the Swing HTML interfaces and embed the Gecko Javascript engine to supoort existing and future so-called rich client in HTML and javascript
    3)Embed an FTP and HTTP protocol handlers with the Swing app
    4)Embed an Asynchronous listener inside the Swing client
    5)Support "work-offline" feature for the Xforms. Also support caching in the Swing app
    6)Embed a installer with the Swing app which can install-uninstall modules at runtime based on Service level agreement
    6)Deploy it in a container which can talk SOAP.
    7)Auto deploy the swing app to the client machine with Web start or something better,without the innumerable hassles of digital signing , license blah blah
    8)Have java and only java servers/ handlers in the middle tier

    Weel it was the recipe to catch up with Longhorn - Indigo

    Regards
    Surajeet
  30. wrong thread[ Go to top ]

    1)Build a client in Swing which conforms to XForms.2)Extend the Swing HTML interfaces and embed the Gecko Javascript engine to supoort existing and future so-called rich client in HTML and javascript 3)Embed an FTP and HTTP protocol handlers with the Swing app4)Embed an Asynchronous listener inside the Swing client5)Support "work-offline" feature for the Xforms. Also support caching in the Swing app6)Embed a installer with the Swing app which can install-uninstall modules at runtime based on Service level agreement 6)Deploy it in a container which can talk SOAP.7)Auto deploy the swing app to the client machine with Web start or something better,without the innumerable hassles of digital signing , license blah blah8)Have java and only java servers/ handlers in the middle tier Weel it was the recipe to catch up with
    Longhorn - Indigo
    Regards
    Surajeet

    this is not a thread to discuss what java needs to do to catch up with longhorn-Indigo you are in wrong thread
    Go to.. Oh! Sorry, i forgot there IS NO thread discussing this, as longhorn is not released , or am i missing something?
  31. Are WebServices for Real?[ Go to top ]

    In my experience with WebServices, it's no way to run a railroad! An Enterprise Service Bus is one thing but publishing an interface that people can write clients to call is a nightmare in the making.

    Personaly, I think the whole WebServices thing will prove to be better in theory than in practice. I'm sure we'll all laugh about it later in life.
  32. Are WebServices for Real?[ Go to top ]

    I'm sure we'll all laugh about it later in life.

    Given the money it costs, some may cry.

    Have fun,

    Remi
  33. Web Service != SOAP[ Go to top ]

    I'd just like to point out that a language can support web services without supporting SOAP. SOAP web services are not the only type of web services, or even the most popular type of web service.

    REST web servcies have been around as long as the web itself. Every time you load a page in a browser you are executing a REST web service. SOAP, on the other hand, did not even start to gain recognition until after the internet bust. They are the new kid on the block and in situations where programmers have a choice between using REST or SOAP, they often choose REST.

    I simply disagree that a language that doesn't directly support SOAP refects poorly on that language. It reflects poorly on SOAP. The bulk and complexity of the SOAP spec means that not only do language writers not want to deal with it, neither do everyday application programmers.

    The fact that SOAP is not supported by many popular languages, such as the P languages, that the spec itself is largely being completely refactored, and that programmers who have options other than SOAP don't use SOAP, all indicate that the SOAP itself has some serious flaws.