Opinion: SOAP is comatose, long live REST

Discussions

News: Opinion: SOAP is comatose, long live REST

  1. Opinion: SOAP is comatose, long live REST (87 messages)

    Carlos Peres started a storm in blogspace a few weeks ago when he posted a blog claiming SOAP was comatose and REST is better. Carlos has posted a second entry rebutting the naysayers and giving further points in favour of REST and pointing to Yahoo Search's choice of REST over SOAP for it's web services interfaces.
    (From Yahoo):The Yahoo! Search Web Services are all REST services. That means you can easily construct request URLs that will work in your browser, on the command line, and in your code.
    However what was telling was that everyone and his mother announced it as "Web Services". The day REST is synonymous with "Web Services" is the day SOAP is truly dead, and that day may have arrived a day too early for many.

    Read More Nails For SOAP's Coffin, and Carlos' first post SOAP is Comatose But Not Officially Dead!

    Threaded Messages (87)

  2. Valentine’s Day[ Go to top ]

    Bring the box of nails and the gift wrapping, I will bring the hammer. Hopefully, we can get it to Bill by Valentine’s Day.
  3. KISS[ Go to top ]

    REST is about KISS... People who so it is less a standard than SOAP are plain wrong. A REST Web Service is build on top of existing standard (just like SOAP).

    When you build a REST WS, you use standards that are proven and stable (HTTP, XML) there is no evolving wrapper around them. Any application can easily call a REST WS and process it's response.

    The main advantage that SOAP can provide (with WSDL and UDDI) is that one would be able to lookup a WS based on a specific interface and get an implementation back. However, for this to really work, one need to define these standard WS interface. As long as there is no standard WS interface for services in a specific domain, SOAP will be overkill.

    And when such standard WS interface exist for a particular domain, one could easily build a SOAP layer on top of the REST WS.

    It's better to build something that work now with little overhead and be able to adapt that solution tomorrow. So if you make a mistake, it's going to cost you a lot less.
  4. REST or SOAP?

    Both of course.
  5. Amazon implements both, of course.

    The catch is: new functions and bug-fixes appear in the SOAP API a long time after they appear in the REST API. If I remember correctly, in an InformationWeek interview, Jeff Barr gave the reason for this as "80% of the 10,000,000 daily requests are against the REST API".

    The story's the same at e-Bay, too.
  6. KISS[ Go to top ]

    standards that are proven and stable (HTTP, XML)

    Proven and stable, yes. But not for every purpose IMHO.

    HTTP wasn't made for supporting *all* types of distributed applications but to browse simple resources (remember ARPANET back in... woaw a loong time ago)... Most of the fellows in the SOAP area should remember this ! They are (re)inventing something on top of the simplest and most unefficient existing network protocol !

    XML wasn't supposed to serve as a basis for transporting object state or worst, to describe interfaces (WSDL *is* awful)... more and more SOAP/WSs users tend to realize that this may be a yet very poor option (hey, they even talk about binary XML now...)

    In short : WSs/SOAP has non real foundation. They're built on the most awful technologies we actually have !

    We already have everything we need for real-life, clean and efficient heterogeneous distributed computing. We don't need neither SOAP nor the WebServices.

    So I'm really pleased that some pragmatic people just got rid of all the bullshit around, and try to keep the thing simple !
    For the ones who have very simplistic requirements (performing a yahoo search is to me quite a simple interface...), well, sending XML over HTTP seems to be a good option...

    The others don't have many choices...

    Cheers

    Remi
  7. SOAP is the EJB of XML[ Go to top ]

    SOAP is the EJB of XML. Too complex for 99.9 percent of applications. SOAP actually reduces interoperability. SOAP just has such an awful thrust to weight ratio. REST is good, though for some web services you really do need XML on the input, as well as the output. The sooner SOAP is forgotten, the better.
  8. SOAP is the EJB of XML[ Go to top ]

    I think like most specs, even ejb and corba, they have their uses in some cases. Ive searched a short time on the web, but found hardly any resources on REST. This makes it not very usefull over XML RPC to use because of this lack of documentation.

    REST needs to mature to be usefull.
  9. REST is for PHP/Perl users[ Go to top ]

    Yahoo choose REST because they choose PHP few years ago, SOAP is more large, Google doesn't forget Java and .Net users and SOAP is so the best solution.
  10. REST is for PHP/Perl users[ Go to top ]

    I agree with that. I think Yahoo has choosen REST bacause is more simple to use with scripting languages like PHP.

    But if semplicity and spread support was a requirement I think it would be better to use XML RPC than REST.

    Anyway SOAP remains a key standard for interoperability.
  11. C'mon[ Go to top ]

    The purpose of Web services is interoperability.
    If you start diverting from the current standards you will spoil the whole meaning of Web services.
  12. C'mon[ Go to top ]

    The purpose of Web services is interoperability.If you start diverting from the current standards you will spoil the whole meaning of Web services.

    Well, then WebServices spoiled the whole meaning of CORBA and the OMG !!!!

    Please remember that CORBA was already an international standard far before some crazy folk even though about doing it again with XML (the SOAP/webservices/blahblah sh*t !)...

    WebService people often think they provided something new...

    Now *users* make the difference : why bothering with the whole stuff instead of directly sending XML back and forth without all the SOAP noise ??

    Users are sometimes more pragmatic than architects.

    You don't need the WSs burden to transmit XML, just like you don't need CORBA to do simple RPC...

    As simple as that.
     
    Have fun,

    Remi
  13. C'mon[ Go to top ]

    WebService people often think they provided something new...

    Now *users* make the difference : why bothering with the whole stuff instead of directly sending XML back and forth without all the SOAP noise ??

    Users are sometimes more pragmatic than architects.

    You don't need the WSs burden to transmit XML, just like you don't need CORBA to do simple RPC...

    Hehehe, I was in a 3-hour long meeting this morning, with architects and managers, to explain our new SOA standard. The chief architect's idea was to use direct XML/HTTP instead of SOAP, for the sake of simplicity. We simply do not believe that the plethora of W3C standards can give rise to reliable and really interoperable implementations of security and transaction services. Since we know we must hand-craft a solution for these issues in the applications and not in the middleware, we threw away all the SOAP stuff in favor of just plain HTTP GET/PUT of XML docs.

    SOA without SOAP seems to become the most viable solution as time passes and WS standards proliferate out of control. As foreseen elsewhere...
  14. C'mon[ Go to top ]

    Hehehe, I was in a 3-hour long meeting this morning, with architects and managers, to explain our new SOA standard.

    *your* SOA *standard* ??!! Gee...
    Are you from ISO ? OMG ?
    :-P
    The chief architect's idea was to use direct XML/HTTP instead of SOAP, for the sake of simplicity.

    Ahem..... Why not tryin' CORBA ???

    LOL :-))))
    We simply do not believe that the plethora of W3C standards can give rise to reliable and really interoperable implementations of security and transaction services.

    I don't believe you will achieve that by yourself easier...

    Once again, why not tryin' CORBA (even more CORBA components) ??? I mean, looks like there's already everything you need in there...
    Since we know we must hand-craft a solution for these issues in the applications and not in the middleware,

    OOOOOOOOOOUUUUUUUUUCH !!!!!

    Do you seriously plan to do this ??? I mean, I'd never even think about implementing this by myself !!
    Transacs and security are the two most terrific nightmares in Distributed Objects, far more complex than just remoting...

    Anyway you certainly have good reasons to do this... But I must admit I can't see even one ??!!
    we threw away all the SOAP stuff in favor of just plain HTTP GET/PUT of XML docs.SOA without SOAP seems to become the most viable solution as time passes and WS standards proliferate out of control. As foreseen elsewhere...

    ;-P

    Cheers

    Remi
  15. C'mon[ Go to top ]

    Hehehe, I was in a 3-hour long meeting this morning, with architects and managers, to explain our new SOA standard.
    *your* SOA *standard* ??!! Gee... Are you from ISO ? OMG ?:-P

    I meant *standard framework for our company*, not a W3C standard.
    I don't believe you will achieve that by yourself easier...Once again, why not tryin' CORBA (even more CORBA components) ??? I mean, looks like there's already everything you need in there...
    I know in advance it would not be accepted. It is just all folks want XML. However, I'll manage to limit XML/HTTP interactions and resort to local Java-to-java calls as often as possible. Legacy VB GUIs will have to interact in XML/HTTP, though. No way I can persuade anyone to integrate a CORBA client in their VB, not to mention writing the CORBA server - I know it's easier than hand-crafting a servlet that responds to XML calls, even using today's WS tools, but previous misuse of IIOP-based EJBs made people diffident.
    Since we know we must hand-craft a solution for these issues in the applications and not in the middleware,
    OOOOOOOOOOUUUUUUUUUCH !!!!!Do you seriously plan to do this ??? I mean, I'd never even think about implementing this by myself !!Transacs and security are the two most terrific nightmares in Distributed Objects, far more complex than just remoting...Anyway you certainly have good reasons to do this... But I must admit I can't see even one ??!!

    Who spoke about a distributed system? I'll keep all applications work in the same web container and use a microkernel, maybe HiveMind, to handle concurrency, IoC and, hopefuly, transactionality. One of the most common abuses in J2EE is distributing the system just to have more than one application running on the same machine - unnnecessary unless you need serious scalability on redundant nodes. Which I do not need with some thousand transactions per day's load. I agree with you that with a really distributed system I would probably have to throw in EJBs - i.e. IIOP. Now that would be a nightmare, to persuade the R&D bosses, given the current general mistrust in EJBs.

    As for transaction on application level, well, we just use JTA w/o EJB in Tomcat, and have faith in God when an HTTP call is in the way. Seriously: no illusion about WS transactionality. Security IS an issue, but this is why they pay me the big bucks (approx. 50% of what I used to get in 2000-2001 ;) )
  16. C'mon[ Go to top ]

    I know in advance it would not be accepted. It is just all folks want XML.

    I have no problems understanding your point. Even in the R&D world (at least in EU projects I am / I've been involved in), CORBA is not accepted. I almost always have to fight (and the word is sometimes appropriate believe me !) to make people trust in it.
    Even partners inside the consortium often don't want to go for it... not even *try* !
    Even if in some precise situations, this is obvisouly the *only* choice.

    So yes, getting managers accept it if they're not already used to it is a f*ckin' challenge !!!!

    Probably takes more time than implementing the whole damn thing using non appropriate technologies (which is of course often possible...).
    However, I'll manage to limit XML/HTTP interactions and resort to local Java-to-java calls as often as possible. Legacy VB GUIs will have to interact in XML/HTTP, though. No way I can persuade anyone to integrate a CORBA client in their VB,

    Woaw this remembers my goold ol' CORBA times, when I saw the first VB CORBA client a few years ago... souvenir souvenir :-)
    But this was dreaming I guess, I never heard about one VB app contacting a CORBA object in the real (commercial) world...
    not to mention writing the CORBA server - I know it's easier than hand-crafting a servlet that responds to XML calls, even using today's WS tools, but previous misuse of IIOP-based EJBs made people diffident.

    Yep, this is sadly true. Only some experts in very specific areas use CORBA, because they have no choice (telco, finance, embedded, etc.). But "regular" applications are not often CORBA-based, even if as you say it would be far more convenient from many points of view...

    To me, CORBA has the potential to make software *really* reusable. This is dreaming yet, of course, but IMHO in the next years MDA and CORBA should really allow our work to become more "industrial".

    Yeah, some years ago, in the first ages of computer science, so callled "analysts" used to "draw sketches on a pizzeria napkin" as a unique design, and jump with no transition into VI or emacs to hack the system...
    Now we begin to organize everything, use tools, to generate code, standardize... well, to have a methodological approach. You know, just like all industries do since centuries...
    I don't believe software engineering will follow another path. One day the customers won't accept to pay that much for what's delivered.
    That's why I'm so comfident with the future of real efficient standards (e.g. CORBA or MDA) actually.
    Who spoke about a distributed system?

    Erf, sorry. Bad "remoting" habits I guess... :-P
    I'll keep all applications work in the same web container and use a microkernel, maybe HiveMind, to handle concurrency, IoC and, hopefuly, transactionality.

    Well, once again that makes sense. I just started my own company a few months ago and I'm currently designing kind of intranets for SMEs... Guess what ? There not one IDL in there :-)

    "Don't use a hammer to kill a fly" (my brutal translation of a French proverb)...
    One of the most common abuses in J2EE is distributing the system just to have more than one application running on the same machine - unnnecessary unless you need serious scalability on redundant nodes.

    Well actually I met situations where this was required because of interop issues... Mostly legacy systems wrapping.
    This is where CORBA rules the most IMHO. Got old code that you already paid for, that's tested and working since years ? Only need a few mods finally ? Well, wrap it into clean CORBA objects, and no worries, you're done. No need for months of regression-testing and so on. You can plan your future, concentrate on business logic instead of being trendy-technology driven and follow the market like a sheep.

    There's many situations where encapsulating what's already there should be preferred to re-developping it from scratch...
    Which I do not need with some thousand transactions per day's load. I agree with you that with a really distributed system I would probably have to throw in EJBs - i.e. IIOP. Now that would be a nightmare, to persuade the R&D bosses, given the current general mistrust in EJBs.

    :-)
    I personnally don't "trust" them for something they're not.
    EJBs are not real objects, they're more "services".
    Frankly speaking I don't see real interest in entities, and I don't need sessions for remoting...
    Declarative transacs, and security, yes...
    As for transaction on application level, well, we just use JTA w/o EJB in Tomcat, and have faith in God when an HTTP call is in the way.

    LOL
    Anyway, I guess we all cross fingers when it comes to transactions in general...
    Seriously: no illusion about WS transactionality. Security IS an issue, but this is why they pay me the big bucks (approx. 50% of what I used to get in 2000-2001 ;) )

    Well, I must admit I'm not very comfident with security, there's so many things to know there it's frightning !!!!

    This must be why I don't get the "big bucks" by the way... would you recommend any book ???
    :-)))

    Have fun,

    Remi
  17. Corba, WS, it all sucks[ Go to top ]

    Corba is not the future, it's the past. How many new applications do you know being developed in Corba right now? It's way too complicated, it's not internet (firewall)-friendly and moreover it doesn't provide real interoperability.
    It's not interoperable unless both ends of the wire use the same orb from the same vendor because vendors did interpret the IIOP spec all a bit differently. 4 years ago i went to a Corba conference and the guys from the Opengoup ex^plained how they tried to make 2 orbs from different vendors talk to each other... Boy it took them sweat,blood and tears to make it work *kindof*. Morale: Corba is only interoperable on paper!

    Web services suck big time: complex, very inefficient, many competing specs (sigh) plus due to the complexity of soap I expect it to have the same interoperability issues as corba.

    For doing B2B over the internet I would use a message queue with whatever message format you want (binary, plain text, simple xml) any time of the day. It's reliable, asynchronous (I don't want to waste most of my CPU cycles just waiting for the data to arrive) and it has a much richer connection model than the point to point model of RPC. You might want to check out the excellent MantaRay framework.

    If you do want to stick with a rpc style framework then I would choose Jini over all the others. It's (relatively) simple, very elegant and light years ahead of all the rest: it has self-description,security,transactions,automatic service discovery (all the stuff WS is trying to define now) + stuff WS has never heard of: distributed events and *leases* for making the whole thing robust through self-healing. Although originally designed for LANs (like Corba) it now has been enhanced to make it internet-friendly (no multicasting, no random ports being opened (so firewall-friendly). You can use the efficient binary RMI protocol or you can choose a bunch of other protocol (also xml over http). Want to make a Cobol/C/C++/VB app talk to you Java app? No need for the multi-language complexity of Corba or WS: just write a thin wrapper in Java around your non-java app (remember the exist java VM for every possible OS by now, from mainframe to a cellphone) to expose it as a Jini service (either in-process via JNI or interprocess via pipes/sockets,...) and that's it!

    just my 2 cents,
    Steven Sagaert
  18. Corba, WS, it all sucks[ Go to top ]

    Corba is not the future, it's the past.

    Thank you for this useful clarification.
    How many new applications do you know being developed in Corba right now?

    I'm not that kind of guy that knows all figures concerning everything, I don't have a precise answer.
    But I *personnally* know a few *big* companies that use it for *mission critical* distributed applications.

    In short, your phone operator is probably running CORBA somewhere, the planes you fly with may embed CORBA software, and financial places use it as the middleware...
    It's way too complicated,

    Distributed computing *is inherently* complicated. Issues implied won't be solved by sending an XML file over the wire anywhere else than in poor articles...
    it's not internet (firewall)-friendly

    This is the only point where you are actually right, more or less :-)
    and moreover it doesn't provide real interoperability.

    Whereas XML does. Yes. Of course. How stupid am I so I could believe that !!!
    It's not interoperable unless both ends of the wire use the same orb from the same vendor because vendors did interpret the IIOP spec all a bit differently.

    Bullshit. I can prove the inverse whenever you want, I do it everyday !!! Are you ready to bet on what you say ?
    Or are you just trolling ?
    4 years ago i went to a Corba conference and the guys from the Opengoup ex^plained how they tried to make 2 orbs from different vendors talk to each other...

    OK, so your only CORBA experience is a conf 4 years ago ??? And your'e comfident enough to say things like you do ?
    Woaw. Impressive !
    Boy it took them sweat,blood and tears to make it work *kindof*.

    You'll always find people to say something doesn't work, when they actually did not succeed in get it working !!!

    Also, CORBA evolves with time and efforts people put in it (the community's not small). Of course it had (and will probably still have) interop problems in some areas, but *most* of the spec *is* implemented and does not leave place for doubt.
    Morale: Corba is only interoperable on paper!

    If CORBA's not interoperable, this is probably only in the heads of people who never took time to learn it.
    With all my respect, please try to have a look at it before you talk... you missed it completely actually :-/
    Web services suck big time: complex, very inefficient, many competing specs (sigh)

    Here I agree with you :-)
    plus due to the
    complexity of soap

    SOAP ? Complex ? Isn't that a paradox ?
    I mean, "S" in SOAP stands for Simple, remember...
    WSs bullshit is not complex either, not more than CORBA of course it tries to address the same issues more and more... It's not complex, it's only bad designed IMHO...
    The original idea in itself does not make sense to me...
    I expect it to have the same interoperability issues as corba.

    Are you an interop paranoid ??? Had bad experiences with heterogeneous software ???
    :-)
    For doing B2B over the internet I would use a message queue with whatever message format you want (binary, plain text, simple xml) any time of the day. It's reliable, asynchronous (I don't want to waste most of my CPU cycles just waiting for the data to arrive) and it has a much richer connection model than the point to point model of RPC.

    One solution for all : send binary data as email attachments.
    This is the killer application mate, go and post a pattern, write a book, this is the new concept for "interoperable efficient SOA over the Internet" !!!
    LOL

    Seriously, what you talk about is *also* standardized in CORBA since years (Events & Notification)... And it's not about passing text or blobs, but *interoperable objects*...
    You might want to check out the excellent MantaRay framework.If you do want to stick with a rpc style framework then I would choose Jini over all the others. It's (relatively) simple, very elegant and light years ahead of all the rest: it has self-description,security,transactions,automatic service discovery (all the stuff WS is trying to define now) + stuff WS has never heard of: distributed events and *leases* for making the whole thing robust through self-healing.

    ... which is once again already there in CORBA since years... and working fine :-)
    Although originally designed for LANs (like Corba) it now has been enhanced to make it internet-friendly (no multicasting, no random ports being opened (so firewall-friendly).

    ... IIOP tunnelling...
    You can use the efficient binary RMI protocol or you can choose a bunch of other protocol (also xml over http).

    ... sure, RMI's great for using C++ code...
    Want to make a Cobol/C/C++/VB app talk to you Java app? No need for the multi-language complexity of Corba or WS: just write a thin wrapper in Java around your non-java app (remember the exist java VM for every possible OS by now, from mainframe to a cellphone) to expose it as a Jini service (either in-process via JNI or interprocess via pipes/sockets,...) and that's it!

    Oh yes, develop everything in-between using Java to get a COBOL and a C++ app communicate...

    What you say is "Java should be used as the intermediate language for everything". "bind yourself to a language to achieve interop".
    Don't you think this is rather silly ??? Whereas you could make abstraction of the technology and have an OO approach of integration ???
    The Common Object Request Broker Architecture is *above* languages and technologies.
    Java and JINI *are* a language and a technology.

    *big* difference, don't you think ?

    Have fun,

    Remi
  19. distributed Remi[ Go to top ]

    C'mon Remi, what's so hard about all of this?

    If we stick to the known usecases, setup some kind of conversational context for security/ transactionality, surely we can implement a few data queries and update methods to fulfill that usecase.

    It's only when we try and invent generalized object semantics and try to automagically remote objects without having well-understood behaviour & boundaries, that the problem gets complex.

    Either REST, with its verb-space URLs and parameter tuples, or SOAP with its XML documents, are suited to pass requests with well-understood effects & transactional behaviour.

    Distributed services are fine & simple, but distributed objects are a mismatch for most architectural purposes.


    Cheers,
    Thomas
    www.powermapjdo.com
  20. distributed Remi[ Go to top ]

    Sorry for the late reply... was under heavy load for the last weeks...
    C'mon Remi, what's so hard about all of this?

    Nothing...
    If we stick to the known usecases, setup some kind of conversational context for security/ transactionality, surely we can implement a few data queries and update methods to fulfill that usecase.

    Yep RDBMS do this fine since years.
    SQL is *far* more interoperable than SOAP or REST or XML, if you forget Objects.
    But yes, you could do it many ways...
    It's only when we try and invent generalized object semantics and try to automagically remote objects without having well-understood behaviour & boundaries, that the problem gets complex.

    I don't see it that way. Complexity is bound to requirements IMHO. But there's the technological factor too.
    Just consider databases : we all used painful SQL statements for years before (working) OODBs and (efficient) ORMs... Do you still SQL ?
    Well most of the times I rely on an OO persistence layer, just because it's simpler and far more powerful !
    I mean, OO design has no comparison with procedural approaches. So no, I would not say the problem gets complex !

    Also, I never said everything should be remote (would be great if possible but unfortunately this has a performance cost no one can afford).
    CORBA has value types too, don't forget that !
    It's only a question of design, you know, Distributed Applications Architect always struggle with granularity, that's the most recurrent issue...
    So I'd say yes, you can do ugly things with CORBA... but you can't do OO things with SOAP ! And that's quite a bad thing IMHO.

    Just imagine the CORBA works perfectly with firewalls etc.
    What would you do to purchase an Amazon book (in CorbaScript for the sake of simplicity) would be more or less like (dummy example of course) :

    // get amazon from NS
    az =
    ORB.resolve_initial_references("NamingService").resolve("Amazon");
    // search books (returns value types)
    books = az.search("books", "GoF", ...);
    // buy a product
    az.buy(books[i], my account data);

    Now the REST equivalent (not the code, would be too long !) :
    1/ define an XML mapping for your objects 'cause you don't want to write XML "by hand" of course - hibernate, castor, whatever...
    2/ Open a pipe to the web server (yeaaaah, back to sockets !)
    3/ Write the HTTP request (by hand ! check out corresponding RFC for the grammar), agree on the method semantics, parameter names, etc (no compiler can help there)...
    4/ Add XML-serialized stuff to the HTTP request
    5/ Look for XML coming back
    6/ De-serialize to your prog language
    7/ Re-serialize and send again for buying (or pass an ID !!!)
    8/ Wait again for XML result...
    9/ Parse, convert, transform again and show result

    Still convinced ?
    :-)
    Either REST, with its verb-space URLs and parameter tuples,
    or SOAP with its XML documents, are suited to pass requests with well-understood effects & transactional behaviour.

    My problem is that it forces you to write additional code (translations). This costs, it is subject to bugs, maintenance is more expensive, etc.

    Now my turn to ask a question : what's your problem in using business objects instead of using intermediate formats to finally to the same thing with thousands LOC more ???
    :-)
    Distributed services are fine & simple, but distributed objects are a mismatch for most architectural purposes.

    I guess bad designers put that idea in the mind of people, it's not the first time I hear that.
    A so-called "senior consultant" even told me that "OO development represent the old way, now it's services time" !!!

    To me, nothing makes it impossible to build distributed services as Objects. I don't know why so many people can't think about OO implementations of SOAs...

    Have fun,

    Remi
  21. distributed Remi[ Go to top ]

    It's only when we try and invent generalized object semantics and try to automagically remote objects without having well-understood behaviour & boundaries, that the problem gets complex.
    I don't see it that way. Complexity is bound to requirements IMHO. But there's the technological factor too.Just consider databases : we all used painful SQL statements for years before (working) OODBs and (efficient) ORMs... Do you still SQL ? Well most of the times I rely on an OO persistence layer, just because it's simpler and far more powerful !I mean, OO design has no comparison with procedural approaches. So no, I would not say the problem gets complex !

    +1
    So I'd say yes, you can do ugly things with CORBA... but you can't do OO things with SOAP ! And that's quite a bad thing IMHO.

    Also IM(ns)HO.
    Either REST, with its verb-space URLs and parameter tuples, or SOAP with its XML documents, are suited to pass requests with well-understood effects & transactional behaviour.
    My problem is that it forces you to write additional code (translations). This costs, it is subject to bugs, maintenance is more expensive, etc.

    Remi, do not forget that tools do all the work for you now. Last month one of my juniors was rejected as a consultant because he told the interviewer that yes, he did use SOAP with PHP, but he was not skilled with XML. When I asked him how the h**l it was possible he replied to me that the tool did everything for him, so he never got to see the XML message!!!
    Distributed services are fine & simple, but distributed objects are a mismatch for most architectural purposes.
    I guess bad designers put that idea in the mind of people, it's not the first time I hear that. A so-called "senior consultant" even told me that "OO development represent the old way, now it's services time" !!!

    Hey Remi, he told most architectural purposes....

    Ant I suspect this "senior" was about as skilled as my "junior" above.
    To me, nothing makes it impossible to build distributed services as Objects. I don't know why so many people can't think about OO implementations of SOAs...Have fun,Remi

    +1

    By the way, Remi, I was browsing this thread because my chief architect has introduced more requirements in our SOA project and I pointed out that it is turning into an ORB instead. He replied: "Well, if it is necessary let's write an ORB". True, no joke! I suspect the requirements will turn the SOA into a MDA with some remote objects within the currente year, so I am going to propose a more REST-like approach: it is by far more object-oriented. There is still hope (for correctly designed architectures)...

    And do not forget to look at the new "PHP lacks support for web services" thread. It will give you a wonderful mood, I suppose.
  22. distributed Remi[ Go to top ]

    Hi Paolo, good to have time for a chat with you :-)
    Remi, do not forget that tools do all the work for you now. Last month one of my juniors was rejected as a consultant because he told the interviewer that yes, he did use SOAP with PHP, but he was not skilled with XML. When I asked him how the h**l it was possible he replied to me that the tool did everything for him, so he never got to see the XML message!!!

    Agreed. And I'm glad IDL compilers generate stubs too :-)
    But tools or not, including unnecessary code is always a bad idea to me unless you can't do it another way of course.
    The right question could be : "do I really need that ? don't I put more complexity there by doing this ?"

    A good example of "coding for nothing" : look at OpenLazslo ... I was first very excited by that stuff (I thought about "flashifying" webapps 5 years ago !) tried it with enthusiasm... and immediatly sent it to trash !
    XML-izing everything in-between the flash app and the server is huge work, and no tools can do this for you !
    Yep, they'll make it less painful (XPath is better than DOM yes), but still the pain is there ! You have to care about that precisely because your objects don't understand each other, or because you just don't have objects :-/
    So you end up writing code that's not related to business logic nor presentation, but in the middle. You actually write your own middleware more or less !

    What now if OpenLaszlo included an ORB and CorbaScript for example ???
    Then you'd define the model *once*, using *objects* implemented in your favourite prog. language (maybe even several ones if you need), and access it the same way all the time ! No more Mystuff -> XML -> Another stuff routines !
    Hey Remi, he told most architectural purposes....Ant I suspect this "senior" was about as skilled as my "junior" above.

    Right, I may look like an integrist... OK, you can accept translations and conversions in some situations. Maybe.
    But still, they are not a good thing in the concept itself. You should do this only when you have no choice IMHO. And we actually have choice since years now...
    By the way, Remi, I was browsing this thread because my chief architect has introduced more requirements in our SOA project and I pointed out that it is turning into an ORB instead. He replied: "Well, if it is necessary let's write an ORB". True, no joke!

    !
    I think that's what GNOME folks did at that time when CORBA was not working well...
    But anyway that's not the ORB they need in the SOA world but the "glue" all around I think. Brokers are OK, what we now miss is the more high level things...
    CCM's still young, but it should provide the most powerful SOA platform ever I think ! It has everything they all wait for in the SOA arena, but they can't see it ! Their vision is so biased that's incredible. Most of the so-called architects just forgot objects once SOA[P] appeared...
    I suspect the requirements will turn the SOA into a MDA with some remote objects within the currente year,

    This is quite usual... Requirements are first light enough so that you don't necessarily need to use the big stuff... But then, after 2 or 3 iterations, you realize that an integrated approach from the beginnig would have saved a lot of effort because anyway you'll finish with that :-)
     so I am going to propose a more REST-like approach: it is by far more object-oriented.

    Objects through URLs ?
    ;-P
    I must admit I'm not convinced of the Object Orientation of the REST approach. But anyway, I wrote OO code using ADA a few years ago, so I guess you'll manage to use it the right way... OO is a concept that can be implemented in many environments, I agree on that point.
     There is still hope (for correctly designed architectures)...

    Fortunately some people still have their head on their shoulders :-)
    And do not forget to look at the new "PHP lacks support for web services" thread. It will give you a wonderful mood, I suppose.

    It's dessert time, coffee and PHP stories are good for digestion... let's go there :-)

    Have fun,

    Remi
  23. Corba, WS, it all sucks[ Go to top ]

    Corba is not the future, it's the past.
    Really?
    How many new applications do you know being developed in Corba right now?
    Lets alter the question a bit: How many quality applications do you know? How many are using CORBA? - That is quite different.
    It's way too complicated,
    Complete nonsense: http://kgionline.com/articles/protocol_compare/doc/index.jsp
    it's not internet (firewall)-friendly and moreover it doesn't provide real interoperability.
    BS + FUD: Stupid network admins cause real business to suffer and bureacrasy to prosper. Please do not confuse symptoms with real cause: there are no any reasons whatsoever why IIOP port cannot be open on firewalls, but plenty of reasons to send everything through one port.
    It's not interoperable unless both ends of the wire use the same orb from the same vendor because vendors did interpret the IIOP spec all a bit differently. 4 years ago i went to a Corba conference and the guys from the Opengoup ex^plained how they tried to make 2 orbs from different vendors talk to each other... Boy it took them sweat,blood and tears to make it work *kindof*. Morale: Corba is only interoperable on paper!
    Kind of myth. There are some obscure corners of spec that might not work well but basics are quite interoperable.

    Actually this myth was born out of very early CORBA days when standard did not specify wire protocol. This was resolved many years ago.
    ..........

    Rest of the post IMO demonstrates lack of understanding of CORBA scope and abilities.
    People: CORBA complexity perfectly matches domain complexity: and dependency is linear - for simple RPC CORBA is very simple, and more complex scenarios are doable with resonable efforts.
    Saying that CORBA is complex is equal to the saying:
    Using of Ant and VC (version control) is complex and sucks big time compared to straight IDE use.
  24. Corba, WS, it all sucks[ Go to top ]

    Corba is not the future, it's the past.

    Slogan, not fact. IIOP is, and will always be, a fundamental part of the J2EE spec, along with the simpler JRMP protocol. You cannot state that TCP/IP is the past just because the raw interface is no longer exposed to programmers as it was in the first years of network programming.
    How many new applications do you know being developed in Corba right now? It's way too complicated, it's not internet (firewall)-friendly and moreover it doesn't provide real interoperability.It's not interoperable unless both ends of the wire use the same orb from the same vendor because vendors did interpret the IIOP spec all a bit differently. 4 years ago i went to a Corba conference and the guys from the Opengoup ex^plained how they tried to make 2 orbs from different vendors talk to each other... Boy it took them sweat,blood and tears to make it work *kindof*. Morale: Corba is only interoperable on paper!

    False.

    As others pointed out already, what is stated in conferences cannot be taken as evidence. One year before your conference, I had to make two ORBs interoperate, IONA's and BEA's. Both companies' executives, if you have any experience with them, would rather throw themselves on a grenade than see their customer use the other's product. Well, do you know what sort of "blood and tears" did it take to achieve IIOP interop? One week of a mid-skilled developer, just to have the BEA guys state "you have to apply the Orbix patch before it can talk to WebLogic". Patch was free, of course.

    In the meanwhile of this painful, five man/day process, I had to fight vs. other companies who tried to persuade the customer that a VisiBroker-based client could not talk to Orbix or WebLogic. Again, false, just plain false. But since their engineers were not skilled enough to handle a simple IDL mapping, they eventually managed to persuade the customer that CORBA was not interoperable and they had to resort to other solutions.
    Web services suck big time: complex, very inefficient, many competing specs (sigh) plus due to the complexity of soap I expect it to have the same interoperability issues as corba.

    I agree with you that we can have a long time before WS-* standards reach maturity, too, and that in the long time complexity will be about the same (so unskilled developers will become unable to handle SOAP as they could not handle CORBA IDL). But please note that there are no such issues with CORBA. J2EE certification process, as you can see in the reply from Bill Burke in the "Congrats for JOnAS certification" thread, requires full IIOP interoperability with other ASs. Otherwise, no certification.

    Of course, no technolgy will ever be a silver bullet. IIOP still has trouble when a firewall is in the way, despite IIOP 3.0 support for firewalling. Anm yod can still benefit from using WS in several cases. And message enqueueing will still be a correct answer in many cases.

    But believe me, the current WS hype is driven by marketing considerations, not technical ones. Just as the early overadoption of EJB was the result of excess excitement for the new technology, not careful architectural considerations. And this has done a lot of damage to customers' trust in Java and J2EE for the past years.
  25. Corba, WS, it all sucks[ Go to top ]

    Of course, no technolgy will ever be a silver bullet.
    True
    IIOP still has trouble when a firewall
    False.

    IIOP has no troubles with firewalls. It happily goes through designated port and allows FW to prevent other protocols throught the port.
    Ridiculous widespread policy that considers zoo of protocols throught one port to be 'secure' and orderly passing of predefined protocols through designated ports- 'insecure' - That is whole different matter.
  26. Of course, no technolgy will ever be a silver bullet.

    You're right, but CORBA's the closest IMHO :-)
    IIOP still has trouble when a firewall
    False.IIOP has no troubles with firewalls. It happily goes through designated port and allows FW to prevent other protocols throught the port.Ridiculous widespread policy that considers zoo of protocols throught one port to be 'secure' and orderly passing of predefined protocols through designated ports- 'insecure' - That is whole different matter.

    Well, true and false :-)
    Technically nothing should block IIOP it's only config stuff, I fully agree...
    In practise you don't control all that and get sadly stuck with HTTP tunnelling which of course *sucks* in the idea itself...

    Have fun,

    Remi - *currently* arguing with EC reviewers about the choice of CORBA for a "SOA" like architecture... they don't like it :-P
  27. Corba, WS, it all sucks[ Go to top ]

    IIOP has no troubles with firewalls.

    Um, despite having been officially edited since the prior millenium, the progress of CORBA's firewall specification is described by OMG as "Status: 1.0 finalization underway". I think I know why it would take CORBA years to specify how to tunnel. It takes a Master's degree to understand the specification. And despite repeatedly mentioning HTTP as a model, port 80 is never posed as an alternative. Even Sun's JRE can tunnel RMI over HTTP, but IIOP has no such official mechanism.
  28. Questions...[ Go to top ]

    Questions ('cause I don't know)...

    Question for Brian:

    I thought EJB used RMI over IIOP. No?

    Question for Konstantin:

    If you open IIOP on your firewall, would that not allow execution of services that you don't necessarilly want to expose?
  29. Questions...[ Go to top ]

    Questions ('cause I don't know)...Question for Brian:I thought EJB used RMI over IIOP. No?

    I don't remember if RMI/IIOP's now replacing JRMP, or if it has to be supported in addition (precisely to allow CORBA clients to connect to EJBs)... and I'm too tired to look for that :-P

    Anyway all decent ASs support RMI/IIOP. This uses "JavaIDL" (reverse-mapping of Java types to IDL types). The only problem is that everything is value-typed, and you get unnecessary types (what's the point in recoding EJBs' SessionContext in a CORBA C++ client ???)... The generated IDL is quite ugly :-/

    Try "javaIDL" on a plain Java class (even if I would recommend startring by writing the interface instead of the implementation... this makes more sense doesn't it ?).
    Question for Konstantin:If you open IIOP on your firewall, would that not allow execution of services that you don't necessarilly want to expose?

    Different considerations : a firewall is very different from Authentication and Access Control Lists...
    The first stays at the network transport layer whereas the second is a very high-level concept (allow "roles" to invoke methods on objects or not).
    You have the same issues with WSs or even REST : everything that's "published" by the SOAP toolkit it available by default over HTTP on port 80, and your firewall can't change that... It can't clearly identify a client (not *precisely*, e.g. the user is behind an Internet provider and has no static IP), and even more it can't identify the various SOAP services that run on the server's port 80...

    Firewalls are actually not an answer to distributed systems security... that's why OMG specifies the Common Secure Infrastructure. They thought about all these issues no worries :-)

    Have fun,

    Remi
  30. Questions...[ Go to top ]

    As usual, thread is turning into a "How I wish port 80 would not prevent me from using CORBA thru firewalls". Not that I disagree (I have used CORBA thru firewalls, and that is a nigntmare, not inter-vendor interoperability), but the idea in this thread was to talk about the future of SOAP-based architectures...
    Questions ('cause I don't know)...Question for Brian:I thought EJB used RMI over IIOP. No?

    Sun states it is suggested for interoperability issues. It also allows to take advantage of CORBAServices as the JNDI, JTA and Security implementation (with COSNaming, OTS and CSI respectively). In fact, the OpenSource ASs offer both RMI/JRMP and RMI/IIOP as an alternative, with JRMP preferred for the sake of simplicity/performance.
    Question for Konstantin:If you open IIOP on your firewall, would that not allow execution of services that you don't necessarilly want to expose?

    It is a matter of security, not firewalling. Any protocol that is exposed in an insecured way is a risk, even HTTP. If unauthenticated HTTP PUTs are allowed, everybody can hack your system! And with unpatched IIS, well, you know. Hacker's paradise.....
  31. Corba, WS, it all sucks[ Go to top ]

    IIOP has no troubles with firewalls.
    Um, despite having been officially edited since the prior millenium, the progress of CORBA's firewall specification is described by OMG as "Status: 1.0 finalization underway". I think I know why it would take CORBA years to specify how to tunnel. It takes a Master's degree to understand the specification. And despite repeatedly mentioning HTTP as a model, port 80 is never posed as an alternative. Even Sun's JRE can tunnel RMI over HTTP, but IIOP has no such official mechanism.

    Which maybe one reason why some former CORBA hands ganged up to create a new middleware system that, among other cool functionalities, also handles traversal through firewalls. Take a look at the entry for Glacier in this page: http://www.zeroc.com/ice.html
  32. The purpose of Web services is interoperability. If you start diverting from the current standards you will spoil the whole meaning of Web services.

    So, the SOAP (and WSDL and UDDI and maybe SSDL and whatnot) standard makes web services interoperable? Hah haaa!.. A good one!..

    Would you care to elaborate on the existence of Basic Profile X together with Attachments Profile Y, *Simple* SOAP Binding Profile Z, et cetera, et cetara?

    Transport is the least significant factor in interoperability. Semantics is still the most elusive.

    BTW, the web (all URIs and HTTP) is the most scalable and interoperable transport we've ever had. Think about that.
  33. I do not know REST, and probably not enough SOAP. But maybe:
    - REST is easier to develop by hand, but SOAP WS are easier to develop with tools. In the end, tools always win over handcraft.
    - SOAP WS is a mess of too many specs, but maybe REST has too little.

    At any rate, the fact is that there is an overwhelming stronger support in term of organizations, money, power, influence, marketing, opinions and tools in the SOAP side, than in the REST side. But as Dirty Harry said (more crudely), everyone has an opinion. Semantic Web guys have always argued that RDF and now OWL is the way to go and that everyone else should stop using anything else not being an ontology; still many more people ignore them than not. Many Linux guys can also argue that if Microsoft is not yet dead it will soon be; still, an outrageous number of people use Windows. Mozilla can argue about stinky IE; but share speaks by itself. String theory people can try to define how reality is; however, reality can have different ideas. And there is always the old VHS/Betamax fight to be remembered.

    From my part, in my project we will use SOAP.
  34. I do not know REST, and probably not enough SOAP. But maybe:- REST is easier to develop by hand, but SOAP WS are easier to develop with tools. In the end, tools always win over handcraft.- SOAP WS is a mess of too many specs, but maybe REST has too little.At any rate, the fact is that there is an overwhelming stronger support in term of organizations, money, power, influence, marketing, opinions and tools in the SOAP side, than in the REST side.

    REST IS Internet Standards! HTTP, POST, GET, Request/Response, XML. How much more standard and interoperable can you get? And SIMPLE! Yes, there are tons of tools/wizards that will create tons of classes for SOAP WS. Sure the the wizards can create it quickly, but try troubleshooting all that mess, in the end you have to support/maintain those tons of classes and thousands of lines of code. REST is SIMPLE! XML over HTTP, Yea Baby!
  35. In the end, tools always win over handcraft

    Actually the motto really should be "shorter and more expressive language always wins over code generation and toolcraft".

    Whenever you start generating code, for a language/api/technology, you can be sure that technology's time to die has come, and should be replaced with more expressive version. Think Occam's Razor. It applies even to this 'dismal science' they call software engineering.
  36. Actually the motto really should be "shorter and more expressive language

    Yeeeaaaah... "shorter and more expressive"...

    I dont see how this is possible... I would have thought that "semantic expression power" would grow linearly with complexity !
    always wins over code generation and toolcraft". Whenever you start generating code, for a language/api/technology, you can be sure that technology's time to die has come, and should be replaced with more expressive version. Think Occam's Razor. It applies even to this 'dismal science' they call software engineering.

    'dismal science' ?
    Could you tell me more about this ? I think I miss your point (maybe because of my poor english)...

    Anyway, seriously, Java Server Side technlology is *based* on code gen (JSP == code gen, EJBs == code gen, ORMs == code gen, AOP, etc.).
    UML, MDA & stuff is all about code gen...
    But still there's prehistoric fellows that don't trust code generators. I would personnally trust more generated code than code I write myself...

    Have fun,

    Remi

    Pushin' the limits on TSS, chosen pieces :
    * "CORBA is the past"
    * "generating code is nonsense"
    * "Objects are useless"
    * ...
    :-)
  37. Really![ Go to top ]

    In the end, tools always win over handcraft
    Actually the motto really should be "shorter and more expressive language always wins over code generation and toolcraft". Whenever you start generating code, for a language/api/technology, you can be sure that technology's time to die has come, and should be replaced with more expressive version. Think Occam's Razor. It applies even to this 'dismal science' they call software engineering.

    XML is a very useful technology for representing heirachical polymorphic data in a human _and_ machine readable format, it is not pointless, yes there are other formats but none are as arbitrarily readable by human _and_ machine as XML.

    Code generation is critical for ANY language when you need to rapidly make lots of precise maintanable binding code for a technology or data format, what do you think compilers are for? Microprocessor, machine code, microcode, risc code still exist and are coded for, so I say you are dead wrong! We work at many more layers now, because sometimes a higher or lower level is better, expressiveness is often not the answer to this issue, layering often is.

    Oh dear, you cut yourself on Occam Razor :-P
  38. Really![ Go to top ]

    XML is a very useful technology for representing heirachical polymorphic data [...] there are other formats but none are as arbitrarily readable by human _and_ machine as XML.

    Well, I'm not convinced... Real world production XML documents are not that "human readable" to me !
    Editing complex XSDs "by hand" is something you have forgotten since a while...

    Also, the orientation of XML towards binary stuff will probably make it completely unreadable.

    Last but not least, real models may have millions instances and we all know XML files are quickly expensive...

    When it comes to "representing polymorphic data" (hierarchical or not), take a look at ISO STEP for example.
    They have everything XML runs after : modelling language with EXPRESS (kind of UML/XSD stuff), standard data representation and exchange with SPF (optimized text files that are as readable as XML when it comes to complex models IMHO) and standard data access with the SDAI.
    This exist since years. Bullet-proof tested in satellites, boats, aeronotics, thermal analysis, structural analysis, cars, construction, manufacturing, etc (ISO even standardizes "specialized" STEP schemas)...
    Code generation is critical for ANY language

    You should like it : STEP's SDAI has early and late bindings (generates classes for your model in your language)...

    International open standard, of course.

    Have fun,

    Remi
  39. Different strokes...[ Go to top ]

    Blanket statements like "SOAP is comatose, long live REST" ignore the fact that for a lot of problems SOAP is a good way of providing interoperability.

    Our application, Vamosa, uses SOAP web services to enable our .NET GUI to communicate to our JBoss appserver. The appserver is running a Spring Framework based webapp with SOAP webservices. The amount of development we had to do get this up and running and keep running, was and is minimal. SOAP just sits in the background. I don't think I've ever really had to look at the XML being generated. Granted its big & bloaty, but it works for many corporate IT shops.

    I think high profile websites, such as Yahoo & flickr, that use and provide REST-based services don't paint a complete picture of the problem space that web services are being used to solve.

    Cheers,
    Ijonas.

    P.S. I love flickr so much, I've got my own account and so should you! ;-)
  40. XML-RPC[ Go to top ]

    I've started using xml-rpc recently and I can't believe how simple it is to get things working quickly. How would/could I benefit from using REST instead?

    For anyone new to the WS arena I'd definitely recomment xml-rpc over SOAP. It is more limited because it does not serialize all objects, but it has a reasonable set of values available and the exception reporting is very good. For people who *have* to send custom objects, I have used XStream to serialize objects to xml strings which works (filthy hack, I know :$) but it impacts the interoperability of the application, but we're all using java aren't we ;)
  41. Screw XML, long live ASN.1 and BER!

    Seriously, why not fall back to Sun's Fast Web Services? Or do we need the computational complexity of SOAP to make Moore's Law economically viable? (How will we pay for more advanced chip fabs if we don't continue to create less efficient ways to do the same thing?)

    But really, if you step back and lok at it, protocol interoperability has always been easy (for as long as I've been alive, in fact). Ethernet. TCP/IP. ASN.1. CORBA. SOAP.

    It is semantic interoperability that has eluded computers in all but the tightest application verticals. No silver bullet.
  42. It's always good having more than one technology to use, and I think SOAP and REST have both their pros and cons.

    SOAP is a major specification and has wide support, although many different SOAP implementations, at the moment, are not fully interoperable.
    REST is good for its semplicity and "universality".

    Talking about REST, I prefer it over SOAP when dealing with a "resource oriented" view of my services and their business domain, and when I want to make my services accessible from any type of client, also a web browser, without the SOAP overhead.

    It's not a matter of language, REST is good for PHP, Perl as well as Java or .Net.

    For those interested in REST Web Services, here are some good sources:
    www.xml.com
    www.prescod.net
    http://www.xfront.com/REST-Web-Services.html
    http://www-128.ibm.com/developerworks/webservices/library/ws-restvsoap/index.html

    Regards,

    Sergio Bossa
    Author and Developer of:
    Montag, Web Services System for XML Database Interaction
  43. REST vs SOAP[ Go to top ]

    http://www-128.ibm.com/developerworks/webservices/library/ws-restvsoap/index.html

    Amin.
  44. REST?...[ Go to top ]

    Wow, browsing is a methodology. And spidering has an acronym. Or pull/poll. Hmm. Pull/poll with scraping.

    This is REST? Still nice to have a good sounding name for something. I guess this means that reading a flat file from another system is a RESTful design. I've heard others often call this a CRAP design (named after toilets no less).

    I'm neutral. Actually I'm not. Go for the GRID. I'm looking at huge tech infrastractures for loads of bucks, which will be used as yet another point to point RPC.

    Generalisms are always right!

    Jonathan
  45. makes so much sense[ Go to top ]

    Common sense strikes at last! We've got a perfectly good method to send structured actions/ parameters and receive result documents.

    Why build something far more complicated than http URLs, to get no extra value?

    Of course if you need to send huge structured parameters, have ultra-high security or shield what the request is, you can pick a solution to do that. For the remaining 98%...

    No-one's suggesting scraping or any toy suggestions, any more than using steel to build a skyscraper is more of a toy than placing tesselating aluminum bric-brackets on top of a perfectly good steel structure.

    Guess what, in the building trade they just use the steel. Use the solid machinery you have, where it will do the job, and damn straight HTTP is a proven, solid and simple technology.

    Would you trust a construction workers wearing a tutu? :-)

    > I guess this means that reading a flat file from another
    > system is a RESTful design.

    If the data comes from a file, it is. If the data comes from a DBMS you'd read from that.

    Would you send your params straight to the DB, or do you have mark them up & down unnecessarily thru XML a few times for it to be a real app?

    > I'm neutral. Actually I'm not. Go for the GRID.

    Well, what does this actually mean, if anything.

    If you want to implement huge distributed applications you'd probably start by putting your effort into the application and KISS to the most simple & proven infrastructure which will work.

    Maybe your requirements do require SOAP, if they do then use it.

    > Generalisms are always right!

    And request URLs and parameters are about the simplest there is, and thus most correct for the largest number of requirements... And this is logically provable. :-)

    - simpler facts are more general.

    Logical proof based on the order and degrees of freedom of a factual statement.


    Cheers,
    Thomas
    http://www.powermapjdo.com
  46. If you are not using REST, why would you use SOAP instead? Surely there are better alternatives. Why not CORBA...or something like ICE? It's already clear that SOAP is not going to be any easier, more interoperable or more secure than CORBA. Why use binary transport for web services...why bother to fix a symptom when you can fix the disease.
  47. It's already clear that SOAP is not going to be any easier, more interoperable or more secure than CORBA.

    I wish it was clear... Apparently marketing fellows successed in turning manager's heads upside down...
    I recently hear somebody here on TSS declare that SOAP and binary XML could be a "CORBA killer"...

    "XML over HTTP is the answer to distributed interop"...

    Feck, OMG fellows must be pissed off when reading this kind of statements... All this work to get to this point... Pretty ridiculous isn't it ?
    :-)
    Why use binary transport for web services...why bother to fix a symptom when you can fix the disease.

    "fixing the symptom" apparently makes more money than "fixing the disease"...

    Have fun,

    Remi
  48. Surely there are better alternatives. Why not CORBA...or something like ICE? It's already clear that SOAP is not going to be any easier, more interoperable or more secure than CORBA. Why use binary transport for web services...why bother to fix a symptom when you can fix the disease.
    +1

    http://www.zeroc.com/iceVsCorba.html
  49. http://www.zeroc.com/iceVsCorba.html

    Looks like ICE is to CORBA what REST is to SOAP !

    I don't know anything about that one... Thanks for the pointer btw, yet concise and clear material (a bit biaised on some comments, e.g. compariing CORBA security to plain SSL - almost all decent ORBs implement that now, even if the whole CSi thing is not really fully implemented and/or even used !).
    I have to look closer to this... looks very interesting !!!

    The only thing is that they still seem to think OMG fellows are slow and provide too much noise in their stuff. Well, yes, this may be true... but IMHO that's the price for real and efficient standardization... ICE seems to be promoted only by a bunch of private bodies, which once again cannot be compared to OMG's work.

    Remember, SOAP fellows started with the same idea a few years ago (make it simpler)... ;-P

    Have fun,

    Remi
  50. Remember, SOAP fellows started with the same idea a few years ago (make it simpler)... ;-PHave fun,Remi

    Well, SOAP claims always look stupid for me while ICE guys talking sense.
    Anyway CORBA is well designed system and I am pretty happy with it as is. Personally I do not care much if ICE will be mainstream. I just was pretty happy to see people who develop upon past achievements. That is really impressive! Especially when compared with SOAP nonsense.
  51. The Argument in Code[ Go to top ]

    http://www.manageability.org/blog/stuff/rest-explained-in-code/view

    Carlos
  52. The Argument in Code[ Go to top ]

    I'm inclinded to agree for other reasons as well. SOAP tends to imply the Distributed Objects anti-pattern and sure, you can design fat objects to distribute but why use that approach when the prescription is to work around it?
  53. The Argument in Code[ Go to top ]

    I'm inclinded to agree for other reasons as well. SOAP tends to imply the Distributed Objects anti-pattern and sure, you can design fat objects to distribute but why use that approach when the prescription is to work around it?

    "distributed objects anti pattern" ??? Never heard about this one... The last in that style was the "object anti pattern", (which was lots of fun to read through btw :-)) !!!

    Could you explain please ? Is it just about not remoting strings ???
    :-D

    Also "prescription is to work around it" ???
    Which prescription ????
    Who's your doctor ??? (don't answer W3C please :-))) )

    Have fun,

    Remi
  54. The Argument in Code[ Go to top ]

    "distributed objects anti pattern" ??? Never heard about this one...

    It's obliquely mentioned in Sun's J2EE Blueprints and JAX-RPC tutorial. It inspired the value object pattern.
  55. The Argument in Code[ Go to top ]

    "distributed objects anti pattern" ??? Never heard about this one...
    It's obliquely mentioned in Sun's J2EE Blueprints and JAX-RPC tutorial. It inspired the value object pattern.

    OK that was what I thought it was... Maybe the oldest concept in distributed architectures, we talk about this as "granularity" since years before J2EE btw...
    (I even remember infamous "getDescription()" methods that returned structs in every CORBA object, at the time OBVs were only a dream :-) )

    Once again, new words for describing old things...

    Anyway, thanks for enlighting me !

    Have fun,

    Remi
  56. The Argument in Code[ Go to top ]

    Pretty common, looks like you're getting stale there:

    http://www.sdmagazine.com/documents/s=7897/sdm0304a/sdm0304a.htm?temp=src8Ub4XpT
  57. The Argument in Code[ Go to top ]

    Pretty common, looks like you're getting stale there:http://www.sdmagazine.com/documents/s=7897/sdm0304a/sdm0304a.htm?temp=src8Ub4XpT

    Getting stale ?? Sorry I don't get your point...

    Anyway, looks like this article makes sense (sorry I had no time to read it all... I have an application to implement), I'm happy with it ! :-)

    But there is no single answer to this : granularity has to be evaluated for *each* system depending on different criterias of use.

    That's the designer's/architect's work actually...

    Have fun,

    Remi
  58. The Yahoo! Search Web Services are all REST services. That means you can easily construct request URLs that will work in your browser, on the command line, and in your code.

    Apache Axis accepts URL encoded SOAP requests. Type it into IE's address bar and the response is then loaded into IE's folding XML viewer.
    The day REST is synonymous with "Web Services" is the day SOAP is truly dead...

    Of course we all want REST to kill SOAP. But SOAP is already years ahead with the WS-* stack regarding internationally standardized specifications for features such as interface description, discovery and replication, security, transactions, orchestration, etc. REST is just a little baby, lacking any standardization beyond the HTTP specifications.

    It's FUD to say that SOAP is dying or comatose. WS-* is very alive. Most grids use it. Is there even an experimental REST grid?

    But REST is better. It's more intuitive and natural for networking. It could eventually match SOAP, but that would be at least five years away. Most of us, including me, have no authority to reject SOAP. Our managers and architects know that SOAP works, and for now that seals it.
  59. Of course we all want REST to kill SOAP. But SOAP is already years ahead with the WS-* stack regarding internationally standardized specifications for features such as interface description, discovery and replication, security, transactions, orchestration, etc. REST is just a little baby, lacking any standardization beyond the HTTP specifications.It's FUD to say that SOAP is dying or comatose.

    The point is that REST does not have to catch up. It is already there. REST is not a standard or protocol, but an architectural style of doing web services. If you want to communicate the document formats, use XML schemas or DTD. That's all you need. Just keep it simple and it will be adopted.
  60. Ahm, which grids?
    Or, could you elaborate a little bit what do you mean when saying "grid"?
    In my universe, grids are used when you need top-speed distributed computing, for some computation-intense task (i.e. numerical analysis). WS based "grid" would be really pitiful one. ;-)
  61. WS based "grid" would be really pitiful one. ;-)

    The Global Grid Forum's Open Grid Service Architecture is based on WSDL. The leading implementation, Globus, uses Apache Axis, so it's easy to port an existing web service to The Grid. A computational grid needs some core services (eg, addressing, discovery, transactions, security), and the WS-* stack mostly covers them.
  62. Ahm, which grids?Or, could you elaborate a little bit what do you mean when saying "grid"?In my universe, grids are used when you need top-speed distributed computing, for some computation-intense task (i.e. numerical analysis). WS based "grid" would be really pitiful one. ;-)

    I think he's talking stuff like globus. WS are not used for computing, but for other aspects of running grids...

    http://www.globus.org/

    There is also a lot of neat work being done on things like WSDM http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm

    And things like notification and resource that deal with using web services interfaces to manage and collect data from sensors...you could see a wsdm interface to a temperature sensor in a grid server, for example...

    MC
  63. I think he's talking stuff like globus. WS are not used for computing, but for other aspects of running grids...

    WSDL is essential to Globus. Globus job submission uses WSDL. Globus console IO delivery is configured with WSDL. Globus replication and discovery uses WSDL. Custom and Globus core services use WSDL. Globus influenced WSDL 2.
  64. Brian-

    There seems to be a lot of confusion on this forum as to what REST is.

    Comments like "REST is a little baby" seem extremely unfounded.

    "REST" is a termed coined by Roy Fielding to describe the architecture of the web as it was intended, -he was one of the figures crafting the specifications that allow the web to exist in the form we know it today.

    This is not a new thing. This is what the web runs on today. It's the major principle that the web was built on.

    (If you're not familiar Roy Fielding, he is the major architect of the HTTP protocol, was instrumental in crafting the URI specification and went on to be a co-founder of a little known web server called "apache". A good starting point is his PhD thesis where he explains why the HTTP protocol as designed the way it was and introduces the principles of REST)

    So REST goes back at least as far as 1995/1996 when the HTTP1.1 protocol was being written.

    Without the architectural principles of REST the web would not be able to exist as it does today.

    REST is a set of architectural principles for distributed interactions that are designed to work in a "chaotically managed" network. (I.e. the internet)

    RPC style interactions such as SOAP (but equally applies to CORBA/DCOM etc.) do not scale very well in such a network since the semantics of the operations are "hidden" in an application specific way. This prevents things like internet caches being able to cache the results.

    Without caching, in a very large read-mostly system like the internet it would grind to a halt. Since every interaction would require point-to-point communication because the infrastructre (e.g. caches) could not make intelligent decisions because the semantcis are application defined.

    REST is an already proven technology that without which the web could not function.

    SOAP RPC is just the latest in a long line of other RPC mechanisms (CORBA/DCOM/XML-RPC) that all suffer from the same problems.

    Just because you're write your object oriented applications in this way (i.e. sending messages to objects) does not mean it will work on a large unmanaged network like the internet.

    RPC is fine as long as you "own" the network. With the internet that is not the case.
  65. RPC style interactions such as SOAP (but equally applies to CORBA/DCOM etc.) do not scale very well in such a network since the semantics of the operations are "hidden" in an application specific way.

    Well, I may have missed something, but talking about "semantics" when it comes to the web is quite vague to me, and I personnally see far more semantics in Objects than text documents identified by URLs.

    Because yes, you are right : the web is made of RESTful principles. But actually the web is NOT internet...
    The Web was originally about Hyper Text, came from a microfilm box invented by American scientists... well there was no mention about using it as the only existing protocol in every situation, e.g. what you call "RPC" (I personnally prefer "RMI" btw, I'm an OO junkie sorry) ??!!!

    What you seem to say is that REST is the foundation of the Web. OK, but the web's not the foundation for serious distributed computing. Which is not true for "Internet" : IIOP = Internet Inter ORB Protocol. And yes, it *is* a standard, just like HTTP is...

    Last but not least, many applications work over the Internet but do not use HTTP... SQL servers, P2P, email, I-don't-know-what...
    This prevents things like internet caches being able to cache the results.

    I don't get your point.
    But anyway caching is not necessarily bound to HTTP once again... I think there's a few guys in here who could talk for hours about method-based caching, DB resultsets caching, etc...
    Since every interaction would require point-to-point communication because the infrastructre (e.g. caches) could not make intelligent decisions because the semantcis are application defined.

    Well, I don't see a lot of web sites that do not require "point-to-point" communication. HTTP (TCP/IP) is precisely all about "point-to-point" communication...
    Also, I can't see no real "intelligence" in a web cache...
    REST is an already proven technology that without which the web could not function.SOAP RPC is just the latest in a long line of other RPC mechanisms (CORBA/DCOM/XML-RPC) that all suffer from the same problems.

    That's terrible.
    CORBA IS PROVEN TECHNOLOGY TOO ! IT IS A STANDARD SINCE THE NINETIES !
    :-)

    Also, they do not address the same issues. Therefore they cannot suffer from the same "problems".

    You are actually comparing plain text data exchange (btw : why not using plain TCP/IP ? you don't even seem to need HTTP actually...) to distributed objects (at least in the case of CORBA). This can't make sense.
    Just because you're write your object oriented applications in this way (i.e. sending messages to objects) does not mean it will work on a large unmanaged network like the internet.RPC is fine as long as you "own" the network. With the internet that is not the case.

    Well, many people is working on that topic since years, and obviously now it's possible. It's only a question of "goodwilling" I guess.
    Remote objects are reality.
    Nothing, today, makes it technically impossible to build world-sized CORBA applications than run over the Internet.
    The main "technical" problem is that damn port 80 and HTTP junkies that are not able to configure a firewall !
    :-)

    Have fun,

    Remi
  66. <blockquoteBut SOAP is already years ahead with the WS-* stack regarding internationally standardized specifications for features such as interface description, discovery and replication, security, transactions, orchestration, etc. REST is just a little baby, lacking any standardization beyond the HTTP specifications.It's FUD to say that SOAP is dying or comatose. WS-* is very alive.

    I just got back from IBM SHARE last week, and got an earful about WS-* from the folks who are on a lot of these OASIS committees. So I'd have to give the general reaction that this stuff is definately very much alive.

    Even the IBM engineers will tell you that SOAP is a 'least common denominator' approach, and much like EJB, it's a matter of judicious use. I would not necessarily build an app based on web services for the pure hell of it! Rather, web services should be a very thin layer, with very course-grained interfaces, and the real chatter should happen underneath. SOAP is for integration between platforms (e.g. J2EE/.Net), or for linking services that need to be widely available...where the speed tradeoff is compensated for by ubiquity.

    If you look at IBM's architecture, for example, they really see the 'ESB' moving the data around. And to IBM, the ESB appears to be MQ-based, synchronous, point-to-point queues.

    What I've always heard people say is that SOAP is in a bit of a pause state, but when reliability and security start seeing real implementations, that will consititute a critical mass for enterprise use. I know BEA was really trying to say that at the last JavaOne.

    I wouldn't diss REST. I've talked to shops that stopped doing SOAP for some critical interfaces, and dropped to just sending XML over HTTP because of the envelope/payload ratios they found using SOAP. Even the IBM types were saying IIOP blew SOAP away for performance. To contrast, I saw some banks at SHARE that traded programmer/development time for SOAP processing time, and consider it a net benefit, so there ya go...let common sense prevail on a per-case basis!

    Cheers,
    MC
  67. I just got back from IBM SHARE last week, and got an earful about WS-* from the folks who are on a lot of these OASIS committees. So I'd have to give the general reaction that this stuff is definately very much alive.

    Too much, yes. They make so much noise it's getting even hard to think in here !!! LOL :-))))
    Even the IBM engineers will tell you that SOAP is a 'least common denominator' approach, and much like EJB, it's a matter of judicious use.

    IBM fellows won't say something that does not deserve IBM's interests.
    IBM's interested in making money.
    SOAP ans the WSs seem to be a good horse for that yet. Far beter than CORBA, that's obvious !

    But this never means it's a good thing... Look at the windows shit, spreaded everywhere in the world at a price that's really a shame...
    Do you think windows is a decent OS ?
    :-)
    Is macdonald's real good cooking and affordable ???
    :-)))

    It's only a question marketing I guess...
    I would not necessarily build an app based on web services for the pure hell of it! Rather, web services should be a very thin layer, with very course-grained interfaces, and the real chatter should happen underneath.

    It can't be another way with SOAP. This is precisely where CORBA is far more powerful...
    I don't say every object should be remote (that must be what they call "distrib. objects anti pattern", I guess... the recurrend granularity issue). I just say you should be able to *choose*.
    What I've always heard people say is that SOAP is in a bit of a pause state, but when reliability and security start seeing real implementations, that will consititute a critical mass for enterprise use. I know BEA was really trying to say that at the last JavaOne.

    If they (standard services implementations) appear some days and reveal efficient. Which is not guaranteed to happen.
    so there ya go...let common sense prevail on a per-case basis!

    True. And if you think about it, there's no left space for WSs !!!
    Simple Use Cases ? Limited interactions ? XML/HTTP should be enough (btw, SOAP is all about this, what sucks is the WSs actually)...
    Real distributed system requirements (load balancing, fault tolerance, performance, complex object models, need for distributed transactions, security, etc.) ? Then don't bother with XML and the damn whole WSs bullshit and use an appropriate technology (yes, CORBA's the only one).

    Have fun,

    Remi
  68. Rather, web services should be a very thin layer, with very course-grained interfaces, and the real chatter should happen underneath.
    It can't be another way with SOAP. This is precisely where CORBA is far more powerful.

    The distributed objects anti-pattern regards latency. SOAP and IIOP have similar latency, so CORBA has no advantage here. The latest brainstorming on pipelined rendezvous to combat latency is happening with HTTP, not IIOP. So while the two protocols may be tied now, in the future RPC over HTTP may have the advantage.
  69. SOAP and IIOP have similar latency, so CORBA has no advantage here.

    !
    HTTP = "transient connections" (open a socket each time)
    IIOP = "persistent" (re-use comm channel)

    If you ever tried CORBA some day, you'd have noticed that the only "painful" call's the first one (that's TCP/IP). After that, it's never comparable to sending an HTTP request.
    Just like RMI.
    Would you compare RMI's latency to HTTP's ???

    When it comes to SOAP, the (de)serialization process comes as part of the... latency (he yes, that's the time you need to send your stuff over the wire) !

    Still convinced ?
    :-)

    Anyway : no protocol is worse than HTTP when it comes to really distributing systems, this looks obvious to me. It was not targeted to that, so forget it directly. Just like building a house with matches... Will take you 100* times more, if you manage to do it at the end, and it won't be as solid and usable as one made of stone !!

    Also, last but not least, you seem to focus on performance. But then go back to assembler and proprietary binary formats, and forget SOAP and the WSs please !

    Of course a CORBA remote call is expensive (less than a SOAP or REST one btw). Remoting *is* expensive. J2EE *is* expensive.

    But they allow to develop faster, don't they ? Isn't it the reason for you to use it ???
    The latest brainstorming on pipelined rendezvous to combat latency is happening with HTTP, not IIOP. So while the two protocols may be tied now, in the future RPC over HTTP may have the advantage.

    HTTP and IIOP won't ever be 'tied', this can't happen : they are inherently different in their deep nature comparing them is useless...

    Have fun,

    Remi
  70. Give it a REST, Remi[ Go to top ]

    no protocol is worse than HTTP when it comes to really distributing systems, this looks obvious to me.

    Looking at the massive failure of the Internet, I guess you are the genius here ;-P

    This thread WAS about SOAP vs. REST, not how frickin' great CORBA is. Your points are well taken, but I find your hijacking of this thread a waste of space.
  71. Give it a REST[ Go to top ]

    Looking at the massive failure of the Internet, I guess you are the genius here ;-P

    LOL :-)

    Seriously : where have you seen a real distibuted system in the web (please stop this confusion between HTTP and internet btw...) ?
    This thread WAS about SOAP vs. REST, not how frickin' great CORBA is.

    Allright, keep cool, you know how it is... a discussion always evolves (I've seen a thread lately that was about "IBM backing PhP" where people ended debating the C++ language's safety :-P)
    Your points are well taken, but I find your hijacking of this thread a waste of space.

    "waste of space"...
    Well, that's (always) quite frustrating to hear this (even if you're not the targeted guy), especially in the land of freedom that the web should be...
    Is this really *annoying* for you ? A real nightmare at each of my posts ?
    It's a discussion forum, you know, we're here to talk. And a talk is something that you cannot predict : it derives to other subjects, whether you like it or not !
    If *you* don't like the way the discussion turns, no prob, just quit it ! I don't understand your need to tell me to shut it up when you can switch me off whenever you want :-)

    Will you tell everybody that's not fully in the scope of the original post, and moreover talking with others in the thread, that he's "wasting space" (and this is the case for 90% of the threads everywhere btw) ????

    Then *your* posts may be real "wasted space" IMHO :-)

    Have fun,

    Remi
  72. Support from tools[ Go to top ]

    SOAP/Webservices is supported by tools like MS webservice tool kit, which fits in nicely to be able to access webservices from within Excel,Word etc., When that coems to REST, I would consider it. Anything that needs to be support all the complexities of distributed objects/interoperability would end up being complex, how much ever you try. SOAP was simple(r) compared to CORBA when it came along, but as you go along now everyone says it is complex, and bulky. When REST builds in all the features supported by CORBA, I bet it will turn out to be just as complicated.
  73. WSDL for Yahoo[ Go to top ]

    Interestingly, WSDL is flexible enough to support Yahoo's service:

    http://www.pacificspirit.com/blog/2005/03/02/yahoo_search_web_service_in_wsdl_20

    In combination with WSDL, REST might actually be something you could use when stringent requirements need to be expressed to the clients.
  74. WSDL for Yahoo[ Go to top ]

    Using WSDL is great for accelerating the adoption of REST style web services. Being able to describe your web service as a schema would be very similar to the view source command in a web browser that allows you to view a web page as html codes. My 2 cents regarding REST vs SOAP is that if you own the network then any RPC like transport should be used as you have complete control over your own network resources. But for communicating over the WWW to other orginizations, asynchronous messaging has to be the lowest common denominator as no company would want someone from another org controlling a potential long running process on your server. When communicating org to org, REST (+KISS) principles should be adhered to with XML messages sent over HTTP as currently the broadest, cheapest and simplest way to distibuted processing. SOAP then becomes what it was originally intended for...an xml message format for orthoganal objects
  75. Binary ... not String[ Go to top ]

    JavaLobby uses Hessian AFAIK, Spring uses Hessian.. and I use Hessian.
    It has C, C#, PHP ports.
    .V
  76. Ja Mon[ Go to top ]

    Thank you sir. Here is my restatement of you eloquent message...

    ...The over-simplistic idea that simplifying computer science is a good thing, just is not panning out. There are problems that can be simplified, and there are problems that can not be simplified. I am just glad that Open Source is sinlge handedly fixing this by de-powering non-technical sales/marketing forces and empowering technical realities.
  77. REST Clients[ Go to top ]

    I looked into the REST infomation on the web, and read Fieldings dissertation, and find it a really good concept for a Data/Resource Access Layer, given the 1:1 translation of the HTTP Methods to SQL Methods (GET=SELECT, POST=INSERT, PUT=UPDATE, DELETE=DELETE) (see http://www.w3.org/Protocols/HTTP/Methods.html)

    Then I thought how nice it would be to build a little Web Application that used the HTTP Method to steer the actions of the user. REST says to use URLS as nouns without parameters (no URLs like /deletePartner?id=123, rather /partner/123 sent with a HTTP DELETE).

    Trying to get this Web Application to run under a Browser proved to be a challenge, as IE and Firefox take the liberty to translate the PUT and DELETE to GET! It seems one has to build a client that supports something other than GET or POST.

    The examples are real slick at focussing on GET and POST methods, and skipping over the PUT and DELETE methods (arghhhh!).

    I guess the WebDAV clients handle this OK (along with other HTTP method extensions), but to do a Web Service based on REST, one would have to code the HTTP Client from hand, making it all but impractical for a HTML Application.
  78. REST Clients[ Go to top ]

    I looked into the REST infomation on the web, and read Fieldings dissertation, and find it a really good concept for a Data/Resource Access Layer, given the 1:1 translation of the HTTP Methods to SQL Methods (GET=SELECT, POST=INSERT, PUT=UPDATE, DELETE=DELETE)Then I thought how nice it would be to build a little Web Application that used the HTTP Method to steer the actions of the user. REST says to use URLS as nouns without parameters (no URLs like /deletePartner?id=123, rather /partner/123 sent with a HTTP DELETE).Trying to get this Web Application to run under a Browser proved to be a challenge, as IE and Firefox take the liberty to translate the PUT and DELETE to GET! It seems one has to build a client that supports something other than GET or POST.The examples are real slick at focussing on GET and POST methods, and skipping over the PUT and DELETE methods (arghhhh!).

    Hmmm, it is a fact that, although HTTP has the PUT and DELETE methods, very few Web Servers allow them for obvious security reasons. The obvious consequence is that browsers feel free to ignore them! Face it, HTTP alone is not fit for application integration: the only semantics that it can handle efficiently is URL resolving and [verbose] data encoding.

    Last and not least, CRUD semantics alone is not enough to write an application. You need to define more specialized services.

    Still, I can see a point in the adoption of REST if we diverge from the simple HTTP-method-to-CRUD-semantics mapping. Given that the semantics

    updateOrder?order_id="34243"&customer_id="344930"

    is not clear and advisable, although adopted by 99% of applications, we might choose a slightly different approach, like:

    cutomer/344930/order/34243/update

    with a simple XML payload sent via a simple PUT (granted it is supported by the browser) that contains the update details.

    Note that this approach, although not totally RESTful (you have an action verb in the URL), is much more self-explanatory, and, besides, it is rather Object Oriented. The URL accesses a (simple) class hiierarchy and invokes a method (update) on a clearly identified instance. The XML format of data handles, in a simple but powerful way, encapsulation, inheritance and polymorphism.

    Note that SOAP semantics does not allow this: the location and method information for the object to be accessed is coupled with the data that is being sent, since the protocol pretends to be OO but is not: it is service oriented and handles endpoints, not instances.

    Last note: as you can guess, I am not convinced that Distributed Objects are an antipattern, too. Abuse of DOs is bad, not DOs in themselves. If you model your objects as coarse-grained service providers, all is OK, and much better than non-OO architectures.
  79. REST Clients[ Go to top ]

    Given that the semantics
    updateOrder?order_id="34243"&amp;customer_id="344930" is not clear and advisable,

    Why ?
    we might choose a slightly different approach, like:cutomer/344930/order/34243/update
    with a simple XML payload sent via a simple PUT (granted it is supported by the browser) that contains the update details.

    Why ?
    (previous "URL style" passes data as POST/GET params ?)
    Note that this approach, [...] is much more self-explanatory,

    I find it equivalent... I think I miss smth :-/
    and, besides, it is rather Object Oriented. The URL accesses a (simple) class hiierarchy and invokes a method (update) on a clearly identified instance.

    Well, where's the need for that url "refactoring" ?
    I mean, what does the class hierarchy has to do withthe url ?
    I see it only as another way to write it actually...
    The XML format of data handles, in a simple but powerful way, encapsulation, inheritance and polymorphism.

    From the client point of view, it's not obvious...
    I'm still sending an URL (OK, it hasn't got the same taste than previous one but ingredients are similar)...
    I can't see no object reference (only IDs)...
    I can't see no way to make e.g. polymorphic customers...
    Note that SOAP semantics does not allow this: the location and method information for the object to be accessed is coupled with the data that is being sent, since the protocol pretends to be OO but is not: it is service oriented and handles endpoints, not instances.

    SOAP and HTTP is bullshit !
    Last note: as you can guess, I am not convinced that Distributed Objects are an antipattern, too. Abuse of DOs is bad, not DOs in themselves. If you model your objects as coarse-grained service providers, all is OK, and much better than non-OO architectures.

    Yeah ! CORBA ruuuuuulez !!!

    Cheers

    Remi - OK I'm out :-)))))
  80. One Simple POST Would Do[ Go to top ]

    SOAP and HTTP is bullshit !

    CORBA ruuuuuulez !!!

    The waste of space is everything else you've said (again and again and again :-)
  81. One Simple POST Would Do[ Go to top ]

    I can't believe you jumped on this one !!!

    LOL !!!

    Cheers

    Remi - and *this* is wasted space for instance :-P
  82. REST Clients[ Go to top ]

    The XML format of data handles, in a simple but powerful way, encapsulation, inheritance and polymorphism.
    From the client point of view, it's not obvious... I'm still sending an URL (OK, it hasn't got the same taste than previous one but ingredients are similar)...

    If you think of the fact that it is the taste of XML expressiveness that persuaded so many (way too many) managers (and developers) that XML everywhere is the silver bullet solution, you might consider that a more "attractive" URL could make the difference...
    I can't see no object reference (only IDs)...

    You gotcha! You should not use object references across a non-reliable network like the Internet. So using object IDs and a stateless semantics is the correct way. Of course the implementing objects does keep track of its internal state, but by not providing the object reference it does not allow clients to enter conversational state across a non-reliable network. Object references are for very fast LANs and for real-time monitoring of remote devices, not for B2B across firewalls.

    Note that you could still use a CORBA object that only uses stateless calls, frex a stateless Session EJB. But again, on the Internet using a URL yelds more performance than using a IOR.
    I can't see no way to make e.g. polymorphic customers...

    You can extend an XML schema, so you can extend the customer data if the need arises. What you cannot do with simple XML is polymorphic behavior of objects, not polymorphic data structures.
    SOAP and HTTP is bullshit !

    TSS is for mature readers, but please keep it polite.
  83. REST Clients[ Go to top ]

    If you think of the fact that it is the taste of XML expressiveness that persuaded so many (way too many) managers (and developers) that XML everywhere is the silver bullet solution, you might consider that a more "attractive" URL could make the difference...

    :-)
    You gotcha! You should not use object references across a non-reliable network like the Internet.

    Well, I got nothing then !

    I mean, SOAP and all the REST is also running over the Inernet aren't they ?
    So if you can't reach let's say a TCP/IP server, you can't reach a SOAP/REST service either ??
    So how can you even expect running *business* (B2B) then ???

    That's just like writing letters (sending bills, orders, etc) but the mailman is on strike... obviously whatever you put in your stuff, the recipient won't ever be able to read it !

    Moreover, you know like me (probably even better) that some servers (e.g. CORBA Objects - I chose it random I swear ;-) ) can handle "fault tolerance" which precisely allows
    to perform specific tasks in case of network unavailabilty for example... which would result in a dirty 404 over HTTP and would require error handling anyway !
    So using object IDs and a stateless semantics is the correct way.

    To me, this has nothing to do (stateful/stateless) with the middleware but more with the system itself...
    Requirements should drive design more than technology IMHO.
    As you said earier, some systems *need* state...

    Maybe B2B is so simple that simple plain text exchange (sorry, "polymorphic data expressed in XML Schemas", which is better I agree) in a disconnected request/response mode is enough, I have no knowledge at all in this area, but... I don't think so !
    Man, at least I know they use MOMs sometimes ;)
    it does not allow clients to enter conversational state across a non-reliable network.

    Which is *designed* to allow it (TCP/IP once again - look at eMule for instance : thousands of users find it actually pretty reliable !)... looks nonsense to me sorry I still don't get the point I think :-/
    When did TCP/IP became unreliable ???? I missed this step !!!
    How can even "regular" internet business work then ? I mean, eCommerce's not a dream !
    Object references are for very fast LANs and for real-time monitoring of remote devices, not for B2B across firewalls.

    Here I agree with you... But that's another question (firewall vs reliablility).
    Note that you could still use a CORBA object that only uses stateless calls

    What a trick... Instead of doing it the right way directly...
    on the Internet using a URL yelds more performance than using a IOR.

    More performance through URLs ???
    URLs are bound to HTTP AFAIK... Internet's about IPs and ports remember ?
    I think I'm totally lost ! :-/
    XML [...] polymorphic data structures.

    That makes sense. At least I understood that :-)
    TSS is for mature readers, but please keep it polite.

    Ooooh did you jump too ????

    OK, apparently it was taken very serious, so all apologies for my bad words (and my apparently pitiful sense of humour) !!! I won't do it again sir !
    :-P

    Have fun,

    Remi
  84. REST Clients[ Go to top ]

    on the Internet using a URL yelds more performance than using a IOR.
    More performance through URLs ???URLs are bound to HTTP AFAIK... Internet's about IPs and ports remember ?I think I'm totally lost ! :-/

    Remi, what's your take on corbaloc :-} ?
  85. REST CRUD[ Go to top ]

    In my context, I saw REST as a Data/Resource Access Layer, dealing with just the CRUD stuff.

    I would put some Service or Business Domain Layer over it to make it actually useful to clients interested in a higher abstraction, but in the end it all comes down to CRUD on the database, doesn't it?

    In this context, my little webapp was a failure, since the browsers aren't supporting the defined REST functions, but a fuller-blown implementation using a coded HTTP client would be quite possible, as long as I wrapped this client in something my UI could deal with.
    cutomer/344930/order/34243/update

    KISS (can't you derive customer from the order?)

    HTTP PUT /order/34243

    <xmlPayload...>

    The VERB is the HTTP Method - use REST for CRUD like it was meant to be, but of course CORBA is way better.
  86. REST CRUD[ Go to top ]

    In my context, I saw REST as a Data/Resource Access Layer, dealing with just the CRUD stuff.I would put some Service or Business Domain Layer over it to make it actually useful to clients interested in a higher abstraction, but in the end it all comes down to CRUD on the database, doesn't it?

    Definitely not. At least as far as software engineering does not come down to the assignment/simple if/initial condition cycle instructions. There is a theorem, IIRC, that demonstrates that any algorithm can be coded by using just these three statements, but this does not mean that we can oversimplify everything as a superseto of these.

    One more layer above REST? Hmmm, I always assume that a service that uses HTTP as the transport protocol is always the top level one. In a good architecture the underlying layer uses local calls, or at most SQL or RMI or ya-know-what-protocol (but I am not gonna mention it or Remi gets overexcited ;) ).
    cutomer/344930/order/34243/update
    KISS (can't you derive customer from the order?)HTTP PUT /order/34243<xmlPayload...>The VERB is the HTTP Method - use REST for CRUD like it was meant to be, but of course [snippet] is way better.

    Of course the customer is redundant, that was just an example. However there are cases when the double reference need can arise. Nothing should be complicated without reason, but not everything can be simple just because we wish it was.
  87. Best of both world: XINS[ Go to top ]

    I would recommend XINS as an alternative: http://xins.sourceforge.net

    XINS is similar to REST except for the following points:
     - A framework provided for writing/publishing the specification and also for writing/testing the implementation.
     - No HTTP PUT, DELETE. Everything is done with POST or GET.
     - No virtual URLs, parameters are passed in URL parameters (?name=value&name2=value2)
  88. RE: Best of both world: XINS[ Go to top ]

    In fact, XINS may be an actual REST implementation. Especially considering the fact that you can define your own calling conventions in the upcoming XINS 1.2. So you can have an XML-RPC- next to a SOAP- and REST-calling convention.

    -- Ernst de Haan