The Five Stages of Dealing with Web Services

Discussions

News: The Five Stages of Dealing with Web Services

  1. Richard Monson-Hafael posted an email containing the "Dave Podnar's Five Stages of Dealing with Web Services," a close analogue to the stages of dealing with grief. It's quite appropriate, even if you disagree with the negative tone referring to the formal W3C web services stack.

    The five stages are:
    1. Denial - It's Simple Object Access Protocol, right?

    2. Over Involvement - OK, I'll read the SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ, JAX-P... specs. next, I'll check the Wiki and finally follow an example showing service and client sides.

    3. Anger - I can't believe those #$%&*@s made it so difficult!

    4. Guilt - Everyone is using Web Services, it must be me, I must be missing something.

    5. Acceptance - It is what it is, Web Services aren't simple or easy.
    Apart from the humour implicit in the posting, what are your thoughts about the "five stages?" It seems to Your Humble Editor that an ideal API wouldn't involve all of this - either in XML or in web services, for example. Is there a better way, or a silver bullet API out there?

    Threaded Messages (43)

  2. 6. Astonishment - Why am I using it anyway...

    www.enterpriseware.eu
  3. And on the 6th day...[ Go to top ]

    ...He RESTed!

    ;-)
  4. 7) Certified (SCDJWS): To those that belive in the Hereafter...

    Rgs,
    Rafael.
  5. i am still in denial, long road ahead for me
  6. "REST" helps !!
  7. all about perspective[ Go to top ]

    Well, if you buy into the BS that SOAP and WSDL are the only way to do web services, then yes, you are going to wind up denying the difficulting of developing your web services. After several failed interoperability experiments you might be ready to accept the reality that you probably didn't need SOAP/WSDL to begin with. What you really needed was the web service, and the SOAP/WSDL is just cruft.

    Only when you accept the fact that SOAP/WSDL is a disease, can you find the cure, which is plain ole XML schema on top of http. moment of clarity, as the drunk calls it.
  8. all about perspective[ Go to top ]

    Only when you accept the fact that SOAP/WSDL is a disease, can you find the cure, which is plain ole XML schema on top of http.

    There are also other options to access remote objects: Corba, Message oriented Middleware, remote EJB calls (j2ee only). They all have one huge advantage - TRANSACTIONS.

    WebServices have their own advantages of course but they don't seem to be mature enough yet.

    http://www.enterpriseware.eu
  9. all about perspective[ Go to top ]

    WebServices have their own advantages of course but they don't seem to be mature enough yet.
    Please, one example. Just one it is enough.
    Please.

    Guido
  10. all about perspective[ Go to top ]

    Only when you accept the fact that SOAP/WSDL is a disease, can you find the cure, which is plain ole XML schema on top of http.
    There are also other options to access remote objects: Corba, Message oriented Middleware, remote EJB calls (j2ee only). They all have one huge advantage - TRANSACTIONS.WebServices have their own advantages of course but they don't seem to be mature enough yet. http://www.enterpriseware.eu
    Distributed computing has always been holy grail of software engineering. We all know the advantages of inprocess vs. out of process calls.
    We also know that distributed computing is something ideally should be avoided. but in reality cannot be avoided completely. There is no silver bullet either.
    so different situation demands different technologies and
    solutions.
    Given a choice I will still use Webservices - instead of EJBs or CORBA. Man the complexitiy you have to deal with EJB and CORBA - forget about it.
    But in a real time heavy transactional system etc we webservices may not stand a chance.
    So the answer is DEPENDS ...
  11. all about perspective[ Go to top ]

    Only when you accept the fact that SOAP/WSDL is a disease, can you find the cure, which is plain ole XML schema on top of http.
    There are also other options to access remote objects: Corba, Message oriented Middleware, remote EJB calls (j2ee only). They all have one huge advantage - TRANSACTIONS.WebServices have their own advantages of course but they don't seem to be mature enough yet. http://www.enterpriseware.eu

    Actually Web Services have had transactions since 2000/2001, with OASIS BTP first, then OASIS WS-CAF and now OASIS WS-TX. The latter is probably going to become the standard, but certainly the other implementations allowed you to construct transactional Web Services. HP released the world's first Web Services Transaction product back in 2001 which was based on BTP at that time. Arjuna Technologies (and not JBoss), IBM, Microsoft and IONA all have Web Services transactions capabilities based on traditional ACID transaction semantics and/or forward compensation based transactions.

    Mark.
  12. all about perspective[ Go to top ]

    Only when you accept the fact that SOAP/WSDL is a disease, can you find the cure, which is plain ole XML schema on top of http.
    There are also other options to access remote objects: Corba, Message oriented Middleware, remote EJB calls (j2ee only). They all have one huge advantage - TRANSACTIONS.WebServices have their own advantages of course but they don't seem to be mature enough yet. http://www.enterpriseware.eu
    Actually Web Services have had transactions since 2000/2001, with OASIS BTP first, then OASIS WS-CAF and now OASIS WS-TX. The latter is probably going to become the standard, but certainly the other implementations allowed you to construct transactional Web Services. HP released the world's first Web Services Transaction product back in 2001 which was based on BTP at that time. Arjuna Technologies (and not JBoss), IBM, Microsoft and IONA all have Web Services transactions capabilities based on traditional ACID transaction semantics and/or forward compensation based transactions.Mark.

    "Arjuna Technologies (and not JBoss)" should actually read "Arjuna Technologies (and now JBoss)" ;-)

    Mark.
  13. WSDL does not require SOAP[ Go to top ]

    SOAP is just plain bad but WSDL can be useful. Do not lump the two together.
  14. SOAP is just plain bad but WSDL can be useful. Do not lump the two together.
    Oh please! http://www.theserverside.com/news/thread.tss?thread_id=37238

    Check also this very useful WSDL for ISBN
    http://www.xfront.com/isbn.xsd
    and then reply back
  15. all about perspective[ Go to top ]

    Well, if you buy into the BS that SOAP and WSDL are the only way to do web services, then yes, you are going to wind up denying the difficulting of developing your web services. After several failed interoperability experiments you might be ready to accept the reality that you probably didn't need SOAP/WSDL to begin with. What you really needed was the web service, and the SOAP/WSDL is just cruft.Only when you accept the fact that SOAP/WSDL is a disease, can you find the cure, which is plain ole XML schema on top of http. moment of clarity, as the drunk calls it.


    Well I dont like Soap too much either, but it is not too shabby as remoting solution once you get rid of the glue overhead codewise.
    A simple @WebMethod can go a long way compared to the WSDL mess. (Same goes for Corba btw. Corba is neat once you are rid of the IDL, precompile skeleton, stub maintenance junk)

    If you want raw easy to use remoting probably xmlhttp where soap was derived from (and unfortunately never really inherted its excellence) simply is one of the easiest.
    Soap is overkill for most things, but if you want to glue things together it can work out quite well.
  16. More to digest on webservices[ Go to top ]

    Agree with this 5 phases.
    Just pondering on this. Dont know what the rest think on this.

    I dont want to see webservices as a panacea or the so called HOT!! technology. For me, its how I can cut short my development time. As in the first place thats what was promised by webservices. Building products and services on the fly. And we are not there yet. This is because according to me, technology is superseding business. We are making it more obscure and hence making it more interesting for the nerds instead of selling it as a simple, effective, stable, secure and most importantly in capital letters PRODUCTIVE way to develop next generation s/w.

    I have used webservices on a testbed in my earlier company on WSAD for some EAI projects. I learnt painfully.. The project was scrapped because of shortage of resources, improper vison on how this going to be implemented and no idea as 'whats in for the business'? So just want to get thoughts on this forum.

    I totally agree with the 5 phases. Its kind of robotic way to implement webservices. It was so 3-4 years back, its still the same except we have become bit more sophisticated by adding WS-I basic profile or whatever you call it, XML encryption and what not.

    Pardon me but I want to mention that these things gotta be easier to use , make it productive, make it transparent..otherwise we are gonna see another EJB kind of technology.

    Fancy and nerdy but lack of success will kill this ultimately.
  17. I agree with your point and I would like to add that not everybody needs webservices.

    Web services were (are, I presume) thought for addressing those interoperability issues that arose with CORBA and IIOP. This interoperability is much needed in complex environments where systems have to interact with each other.

    The same concept applies to ESB, BPEL and all of their neighbours: not everybody needs an ESB, as not everybody needs a BPEL-digesting workflow engine to implement a 2-steps process.

    Implementing webservices requires a clear vision of the direction that the (customer|own) IT landscape must take. Without it, it makes no sense.

    But just a question (it is by no mean a flame): if one finds a PRODUCTIVE way to develop software, to address interoperability issues and process governance, what would happen to the software industry in general? You see, after all we would have the definitive software architecture and infrastructure!
  18. Web services were (are, I presume) thought for addressing those interoperability issues that arose with CORBA and IIOP.
    Which one ? Just for curiosity.
    I have read many criticism of CORBA in favour of WS on various topics. None of them appropriate at all!!!
    This is rather new, so I am quite interested !
    I have recently discovered an article on WS-Addressing pointing out an interesting side-effect of this spec concerning the possibility to have WS operations returning
    "references" to other WS.
    More, the structure of the reference could be so "smart" that a certain part could be managed by the container to select the proper target, while the remaining part could be analyzed by the target itself to select a specific element on which operate.
    Fantastic !! Now Douglas Schmidt will help to write WS_POA :)

    Someone should tell them that reinventing the wheel is not
    exactly a synonim of evolution.

    Guido
  19. --------------
    Web services were (are, I presume) thought for addressing those interoperability issues that arose with CORBA and IIOP
    --------------

    There are no significant interoperability problems with CORBA. I see CORBAs weakness as being that it doesnt support the notion of logical identity of a "client" being seperate from a network endpoint (IOR) which makes it very hard to implement certain useful enterprise messaging patterns (as anyone who has used the notification service will be well aware).

    However I see SOAP as being much like Entity EJBs - its a missguided attempt to avoid the "unecessary complexity" of a distributed object broker in much the same way as entity beans were a missguided attempt to avoid the "unnecessary complexity" of an OODBMS.

    Paul C.
  20. More to digest on webservices[ Go to top ]

    --------------Web services were (are, I presume) thought for addressing those interoperability issues that arose with CORBA and IIOP--------------There are no significant interoperability problems with CORBA. I see CORBAs weakness as being that it doesnt support the notion of logical identity of a "client" being seperate from a network endpoint (IOR) which makes it very hard to implement certain useful enterprise messaging patterns (as anyone who has used the notification service will be well aware).However I see SOAP as being much like Entity EJBs - its a missguided attempt to avoid the "unecessary complexity" of a distributed object broker in much the same way as entity beans were a missguided attempt to avoid the "unnecessary complexity" of an OODBMS.Paul C.

    The main failur of Corba was that it tried to reduce the complexity of Corba and the result was a thing which was way more complicated in its handling than Corba ever was.
    Add to that that it does not do much more than a simple xmlrpc where it was derived from but in 10 times more complex ways and you can see why Soap in itself starting from the original idea was and is an utter failure.
    I do not see it as a failure for bridging platforms, but I would never ever rely and application infrastructure on top of it.
  21. More to digest on webservices[ Go to top ]

    --------------Web services were (are, I presume) thought for addressing those interoperability issues that arose with CORBA and IIOP--------------There are no significant interoperability problems with CORBA. I see CORBAs weakness as being that it doesnt support the notion of logical identity of a "client" being seperate from a network endpoint (IOR) which makes it very hard to implement certain useful enterprise messaging patterns (as anyone who has used the notification service will be well aware).However I see SOAP as being much like Entity EJBs - its a missguided attempt to avoid the "unecessary complexity" of a distributed object broker in much the same way as entity beans were a missguided attempt to avoid the "unnecessary complexity" of an OODBMS.Paul C.

    Ignoring the REST-versus-WS* debate, which is a lot more complicated than I've got time to go into now.

    I've said this many times over the years and still stand by it: the two main advantages of Web Services are HTTP/XML (*everyone* has an HTTP endpoint of one kind or another) and mass adoption (by virtue of HTTP). No other distributed system infrastructure (with the exception of the World Wide Web) has ever come as close to universal adoption as Web Services (and by this I mean SOAP-over-HTTP). We tried with DCE and failed. We tried with OMG and failed - at least MSFT got involved with DCE, but their determination to go their own way instead of joining the OMG dealt it a blow from the start.

    So far I haven't heard anyone try the: "Web Services are better at SOA than anything else", which is good because they're not - people have been doing SOA for years with technologies like DCE and CORBA. The WS-* stack is complex, but then so is any distributed system that needs to do real work: just take a look at the history of distributed systems (Emerald, Argus, Arjuna, DCE, CORBA, DCOM, ...) There really is no such thing as a free lunch!

    Web Services fill a very important role that no other attempt has been able to: interoperability between heterogeneous environments. They are as much about that as they are about loose-coupling/internet-scale applications. In the last 2 years we've seen companies such as MSFT, IBM, Oracle, JBoss, IONA, Sonic, WSO2 etc. work together to make sure the specifications/standards (and associated products) interoperate out-of-the-box. We've never seen that kind of concerted effort before.

    Even in the OMG! I've been working in the OMG since 1992 and it took 10 years to get things interoperable enough. Unfortunately in that time customers were believing the "already interoperable" hype of vendors and getting tied into implementations that didn't do it. That also hurt the CORBA effort a lot. So of course there's the argument (at least as far as interoperability goes) that if these vendors had worked as hard to get specifications in CORBA, J2EE, DCE etc. to interoperate from the get-go then perhaps we wouldn't need Web Services. But try as we might, we can't change history. Live with it.
  22. I Web services were (are, I presume) thought for addressing those interoperability issues that arose with CORBA and IIOP.

    WS mythology and brainwashing at work, check the facts: CORBA version 1 implementations were could not talk to each other because vendors insisted on that as a way to lock in customers. Since version 2 CORBA has standartized on IIOP protocol and implementations became interoperable.
  23. More to digest on webservices[ Go to top ]

    I Web services were (are, I presume) thought for addressing those interoperability issues that arose with CORBA and IIOP.
    WS mythology and brainwashing at work, check the facts: CORBA version 1 implementations were could not talk to each other because vendors insisted on that as a way to lock in customers. Since version 2 CORBA has standartized on IIOP protocol and implementations became interoperable.

    Version 2 of CORBA sorted out transport interoperability but there were still issues around interoperability of higher-level services. Even version 3 didn't fully sort that out. In an earlier life, I was involved in a CORBA.net interoperability demo. It showed off basic interoperability amongst all the main CORBA players. We wanted to extend the demo to highlight interoperable security, transactions, events etc. but never managed to achieve anything worth showing in the timeframes we had available.

    WS-* is attempting to tackle some of the areas which CORBA never managed to pull off in terms of mainstream use. The dynamics are a bit different now - it will take Microsoft a long time to change direction now - so the basic WS plumbing will be with us for some time - hence the window of opportunity the WS-* community has available to it to get things right is much larger.

    Having said that, I doubt they will fare *that* much better than CORBA for all of these areas - simply because the number of people that need to do the really tricky stuff is small. The market for solving the really tricky cases will always be smaller than some other emerging niche area.
  24. Think about data integrity. Then think about saving your successors maintenance time.
  25. Stage 6) Assimilation - go .Net remoting!

    OK, just kidding. With a little primer on WS-I and Axis java2wsdl why is this so hard? WS-* rightly sucks but the tools and specs are making things better and easier.
  26. Stage 6) Assimilation - go .Net remoting!OK, just kidding. With a little primer on WS-I and Axis java2wsdl why is this so hard? WS-* rightly sucks but the tools and specs are making things better and easier.

    Right.

    If you use the tools, such as Axis (and many others), SOAP is not incredibly difficult (even actual interoperability - not just Axis to Axis). You can turn plain Java into a service (with a few simple guidelines for types and so on) and you can generate client stubs as plain Java from a WSDL. Use the tools. The original implementation of SOAP stuff in the Java world was not great, true, but the new JAX-WS stuff is very nice. A few annotations and you have a web service, and supports SOAP OR REST - https://jax-ws.dev.java.net/.

    Though all this talk of REST sort of misses the point. REST and SOAP are not analogous. At various times one or the other may be the right tool for the job (for security, transactions, types, different operations, tool integration, etc, SOAP - for non transactional simple types and direct XML manipulation sans tools, REST).
  27. How about an efficient data interchange that can be bound cross platform? ASN.1 (fast webservices), JSON, YaML, whatever. I completely agree with the general tone as well. If I have a service you need to invoke, pls read/code to it, and vice versa. I'm not so convinced that the vision of dynamically binding to existing services on demand has really materialized. Most of what we touch are known ahead of time in one way or another, and beyond the simple things, it gets harder and harder when using a full blown ws-* stack.
  28. Tools and understanding[ Go to top ]

    Stage 6) Assimilation - go .Net remoting!

    Yeah great, hide all the complexity. I have seen this with both Java and .Net developers, although the Java part seems to have a slightly better understanding. The problem seems to be that when the tools go in, the developers don't bother to understand the technologies. It's simple point-and-click, and if/when problems such as protocol errors or performance problems enters the scene they are absolutely lost.
    Don't get my wrong on tooling either. The right tool makes my job a whole lot easier. I work mostly with WebSphere/Rational tools and yes, I actually do enjoy that quite a lot and prefer them over most other tools I've tried (disclaimer, works for big-blue, don't talk for them).
  29. web services in java lack a clear, consistent, and simple model for development and deployment.

    although it currently lacks transactions and strong security, java doesn't hold a candle to the simplicity of .net web services. simple annotate your service classes, and deploy.
    generating a client within VS.NET is as easy.

    looking forward to Indigo or WCF, we see a significant investment by Microsoft in web service infrastructure,
    similar in terms of simplicity, but with support for security, exception, transactions, etc.
    Indigo is the result of about 6 years of concentrated design and development, and we still have about 1 year to go before it is complete.

    needless to say, full fledge, useable web services require a framework that is well though out, comprehensive and simple to use.
    Indigo fills this role very well in the Microsoft world.

    however, i do not see an equivalent of this in the Java world. that is, a large scale, multi-year, large team project. no one seems to be taking it seriously.

    so, for doing any real work besides examples, i find the java frameworks lacking in ease of use, compatibility, interoperability and functionality.

    will IBM or BEA take up the reigns and start working on a full fledged JAVA 1.5 implementation of an Indigo equivalent?
    so far, the answer has been no, and anyone who would try is nearly 5 years behind.
  30. SCA/SDO[ Go to top ]

    Service Component Architecture & Service Data Objects are IBM, BEA, IONA, and others answer to 1. WCF/Indigo 2. An end around on the JCP 3. (Perhaps) wrestle control of Java away from Sun.

    And just like WCF/Indigo, SOAP isn't required.

    There is hope ...

    I posted some more on this a couple weeks ago. I linked to some good analysis on it as well.
    http://fuzzypanic.blogspot.com/2006/04/sca-pretty-bold.html

    Should be interesting to watch ...
  31. Enough is enough[ Go to top ]

    I'm really fed up with people saying that SOAP and WS-* is crap. Have you ever tried to use them ? I have, extensively, and I achieved interop with a service coded in C# with WSE 2.0 and clients coded in Java AND C++ (with Axis Java, Axis C++ and JWSDP) with almost nothing hand-coded on the client side (only the specific login/password handler, which is impossible not to code since it's application dependant).

    I even implemented interoperable WS-Eventing (you subscribe to a set of events using a classical request/response service, giving the service an address to send events to you), using HTTP and TCP as transport layers (Microsoft has an out of the box TCP transport layer, I had to make one in Java, but since it's open your socket -> push your message -> read it with JAXB, it's no big deal). Sorry, but WS-Addressing is just fine to do this ; XML over HTTP don't cut it. For example, when a big set of events is to be launched, you can only have two HTTP connections between the service and the client (this is an HTTP limitation), thus the version using HTTP as a transport layer gets messages reaaaaaaaally sloooooooowly. Why would anybody just dismiss the fact that messages could be sent using various protocols ? Everything cannot be done with XML over HTTP. Transport must be pluggable. This is the goal of WS-Addressing and a key feature of Microsoft's Indigo and WSE.

    Conclusions I drew from these projects :
    - SOAP based web services are easily interoperable (.NET, Java, C++, as far as I know)
    - WS-* are probably too chatty, but they are well thought specs if you just take the time to read AND implement them on a REAL project.
    - WS-Addressing / transport pluggability is a great feature.
    - Web Services / SOA / whatever you want to call it isn't just about the simple request/response model based on some form of remote object access ; it's about standard messages (XML Schema) sent between messages endpoint (WS-Addressing), securized in different fashions (WS-Security)

    Web Services with SOAP and WS-* are not a silver bullet, nothing is, but don't dismiss them without trying.
  32. Enough is enough[ Go to top ]

    Yes, I have tried to use them ;-), everything, almost the whole stack at one point or another, from soap4j to apache soap to axis 1, over http/s, jms, java, c++, c#. I agree that the interop is nice when it works, but how much was the tooling to do what you had to do? My main beef is that for non-trivial things, the complexity curve increases sharply and the cost of development (both in time, debugging, tools to debug, tools to develop, etc) grow larger and larger. Often times, I see ws implementations going A2A intra-organization when something simpler would suffice. There's nothing intrinsically wrong with using whatever remoting is available in the platform/language. Even when we have done exchange type of applications, it all boils down to what we know, what you know, and making systems understand each other. Sometimes, ws-* stacks are like using an expensive cuisinart with complicated instructions where a simple pairing knife would suffice.

    My counter point to the SCA specs, and I guess my general frustration, is that we have had this general pattern for several years now (more than a couple, more than a few), and one would think that by now the industry would make things simpler and cheaper, instead of more complex and more expensive. It defies common sense sometimes, although it has done wonders for infusing new capital into the software market ;-)
  33. Enough is enough[ Go to top ]

    forgot to mention that I am in stage 5, acceptance, which is a similar approach I have to my in-laws ;-), dealing with it when I have to (business need) while manically searching for ways to avoid them (alternatives).
  34. Enough is enough[ Go to top ]

    Yes, I have tried to use them ;-), everything, almost the whole stack at one point or another, from soap4j to apache soap to axis 1, over http/s, jms, java, c++, c#. I agree that the interop is nice when it works, but how much was the tooling to do what you had to do? My main beef is that for non-trivial things, the complexity curve increases sharply and the cost of development (both in time, debugging, tools to debug, tools to develop, etc) grow larger and larger. Often times, I see ws implementations going A2A intra-organization when something simpler would suffice. There's nothing intrinsically wrong with using whatever remoting is available in the platform/language. Even when we have done exchange type of applications, it all boils down to what we know, what you know, and making systems understand each other. Sometimes, ws-* stacks are like using an expensive cuisinart with complicated instructions where a simple pairing knife would suffice. My counter point to the SCA specs, and I guess my general frustration, is that we have had this general pattern for several years now (more than a couple, more than a few), and one would think that by now the industry would make things simpler and cheaper, instead of more complex and more expensive. It defies common sense sometimes, although it has done wonders for infusing new capital into the software market ;-)


    Actually that is quite a phenomenon with Software at all. Things start out simple with good ideas and over the time complexity is added to a degree to make one insane, then suddenly the next clear cut comes things, become simple again, and a few years later 90% of the time is spent again with dealing with complexity, instead of designing every extension upfront after the keep it simple stupid principle.
    Examples: Java, which drowns nowadays in frameowork layers started as a cleanup of C++ and the language mess it was into.
    Struts, started out simple and nowadays is configuration hell par excellence. Soap started as a small extension to the absolutely simple xml-rpc and it drowns in glue code nowadays.
    I still think webservices are a good idea, but lets get rid of 90% of the configuration and glue!
  35. Enough is enough[ Go to top ]

    one would think that by now the industry would make things simpler and cheaper

    I still think webservices are a good idea, but lets get rid of 90% of the configuration and glue!


    Use Hessian. :-)

    The motiviation of creating Hessian was a proof-of-concept example that the protocol (and glue) really didn't need to be as complicated as SOAP has become to be useful. It wasn't originally intended to really be a competitor (although it's been gaining users recently), but more like a "gotos considered harmful" statement.
  36. Enough is enough[ Go to top ]

    Things start out simple with good ideas and over the time complexity is added to a degree to make one insane,

    The reason is that IT systems nowadays have very complex requirements (both functional and nonfunctional: scalability, integrity/transactions, distribution, security, interop etc).

    So there are 2 ways:

    1. Use simple technologies to create complex systems (and handmade solutions to scalability, integrity/transactions, distribution, security, interop) that become overwhelming after some time.

    2. Use complex technologies that require a lot of up-front work or education but reduce(hide) complexity of the final solution in the long term.
    then suddenly the next clear cut comes things, become simple again, and a few years later 90% of the time is spent again with dealing with complexity, instead of designing every extension upfront after the keep it simple stupid principle.
    There is no way to avoid dealing with complexity because IT REALLY EXISTS.
    Unless someone chooses to live in denial...

    http://www.enterpriseware.eu
  37. Enough is enough[ Go to top ]

    Ups.. trying to reformat
    Things start out simple with good ideas and over the time complexity is added to a degree to make one insane,

    The reason is that IT systems nowadays have very complex requirements (both functional and nonfunctional: scalability, integrity/transactions, distribution, security, interop etc).

    So there are 2 ways:
    1. Use simple technologies to create complex systems (and handmade solutions to scalability, integrity/transactions, distribution, security, interop) that become overwhelming after some time.
    2. Use complex technologies that require a lot of up-front work or education but reduce(hide) complexity of the final solution in the long term.
    then suddenly the next clear cut comes things, become simple again, and a few years later 90% of the time is spent again with dealing with complexity, instead of designing every extension upfront after the keep it simple stupid principle.

    There is no way to avoid dealing with complexity because IT REALLY EXISTS.
    Unless someone chooses to live in denial...

    http://www.enterpriseware.eu
  38. Enough is enough[ Go to top ]

    Ups.. trying to reformat
    Things start out simple with good ideas and over the time complexity is added to a degree to make one insane,
    The reason is that IT systems nowadays have very complex requirements (both functional and nonfunctional: scalability, integrity/transactions, distribution, security, interop etc).So there are 2 ways:1. Use simple technologies to create complex systems (and handmade solutions to scalability, integrity/transactions, distribution, security, interop) that become overwhelming after some time.2. Use complex technologies that require a lot of up-front work or education but reduce(hide) complexity of the final solution in the long term.
    then suddenly the next clear cut comes things, become simple again, and a few years later 90% of the time is spent again with dealing with complexity, instead of designing every extension upfront after the keep it simple stupid principle.
    There is no way to avoid dealing with complexity because IT REALLY EXISTS.Unless someone chooses to live in denial...http://www.enterpriseware.eu


    Actually what you talk about is only one aspect, the main problem is often things get out of hand and complexity is added which is totally unnecessary.
    Someone already mentioned Hessian, which is a leaner and more clear approach to the whole xml over http paradigm, so is simple and lean xmlrpc.
    Often things are speced out of the scope of being able to be handled in a saneful manner, just to cover the rare 0.000001% of all usecases the same way the rest is handled.

    I will give you examples over this:
    Com compared to Cocoa or the KDE Component framework. The first one has complexities which already drove projects from Microsoft into the ground (Everyone remember Microsofts Cairo which was supposed to be a NextStep clone based on Com)
    the other two have lean and mean clear cut object models.

    The reason for the first one being overly complex, was the omittance of real inheritance in the first incarnations, the archaic hungarian notation based interfaces and generally design patterns straight out of hell.
    While the others try to offer a clean oo approach with well defined interfaces down into functional languages if needed (an approach which never was really necessary because most languages have oo one way or the other anyway)

    The same goes for remoting interfaces. Either fight with complex glue code, interface descriptors from hell and whatever is specced in there, and then years a few people driven into asylum later cover that to some degree with tools. Or come up with something simple with a predefined set of overridable configurations overing 99% of all usecases with clear cut extension points and keep it simple and for the 1% of cases add those thing via extension points.

    There were leaner approaches to the whole remoting paradigm before SOAP, and SOAP started out as a lean approach before things got out of hand.
    And there are leaner approaches doing basically the same as SOAP after SOAP.
  39. History always repeats itself[ Go to top ]

    Fred Brooks explained complexity in his seminal paper, No Silver Bullets (often mentioned but rarely read). The trick is to minimize the accidental complexity - tools, libraries, configuration, etc. that have nothing to do with the business problem at hand. From what I can tell, the problem with a lot of these technologies is that they promise a cookie-cutter approach to development that invariably breaks down once you have to break out of its preconceived use. (unless you're a consultant and never see the code again) This rework leads to a much larger increase in the accidental complexity (since now you have to deal with coming up with solutions to work around the technology at the expense of solving the business problem). There is no reason why a competent developer can't use simple technologies to create complex yet manageable systems, and there is every possibility that using complex technologies will lead to creating complex and unmanageable systems. Two points that you fail to mention.
  40. My whole point is that SOAP based web services are not that complicated. On the contrary, the WS-* specs are made to be modular and combinable ; you can start with no security at all, then plug username tokens, then plug certificates, then plug a third party trust entity. You can sign messages and not crypt them if you don't need it, crypt them and not sign them. You can use addressing to route messages between endpoints or forgetting it altogether because you work in a local network, and then turn it on because your service boundaries extend beyond what you first thougt.

    I think the perceived complexity of the WS-* specs come from multiple sources :

    - many programmers were told that "remoting was made easy". This is not true. Remoting is NEVER easy. You don't program remoting interfaces like you would local ones (chatty vs chunky), that's just a matter of fact.

    - the specs include huge bunches of namespaces, square brackets everywhere, and SOAP messages seem unreadable. But you don't have to read them, tools do it for you, pretty well from my experience.

    - security and addressing aspects are inherently complicated : using a trust entity and client certificates is difficult, routing messages from the internet to a local network using NAT is difficult. It's not the fault of the specs.

    - Microsoft's tools for web services (WSE 2.0 and forth) are remarkably well well thought and carry on the modularity of the specs into the implementation. Things are more blurry in the Java toolkits I tried.

    I guess when all toolkits (Java and .NET) will have the same maturity as the future Indigo in terms of modularity and layer separation, everything will be fine. I hope so at least :)
  41. Mistrust[ Go to top ]

    I mistrust technologies that require complicated tools and believe that code generation is usually evil (tends to hide overly complex things - think XDoclet).

    WCF/Indigo and SCA/SDO are admirable for trying to simplify an overly complex WS-*. I just think that the core technology should be simpler. I think that at least some of the people working on these products/impls agree as both WCF/Indigo and SCA/SDO support (or plan to support) POX and perhaps even RESTful alternatives. In the blogosphere, I have noticed a definite trend towards concluding that WS-* is fundamentally flawed and overly complex. But maybe I am just reading the blogs that support my opinion.

    Regardless of where this goes, if you are trying to do sophisticated integration TODAY, WS-* alone is just not going to get it done. Sure, there are is WS-ReliableMessaging, WS-Eventing/WS-Notification (which is being reworked and doesn’t yet support pub/sub – event driven architecture), but are they ready for primetime? Do you really want all that cruft zipping around your network? Using this technology for third party integration and perhaps bridging messaging platforms is one thing, but just seems like a lot of senseless complexity to use it everywhere. And SCA/SDO is just getting started – it is years away from getting its user acceptance fisking.

    IMHO, you are better off hedging your bets and waiting things out, and focusing on using (relatively) simple technologies that are here today and work like HTTP/POX, REST, and POX over JMS.
  42. Mistrust[ Go to top ]

    I mistrust technologies that require complicated tools and believe that code generation is usually evil (tends to hide overly complex things

    So I should just write everything in machine language and insure there is no code generated or tools used?
  43. I'm sure there are good uses for Web Services, but I think they're way too expensive for most common problems. Especially if you need transactions.

    I went to a BOF at SDWest2004 and spoke out to a panel of WS experts that I didn't see a lot of production-use WS development where I was at and that the whole workspace seemed overly complex. (I've since worked with a few and have decided WS makes maintenance hard, too.) People looked at me like I had three heads or something. I'm glad to see some of these thoughts validated.

    Rick
  44. Well, in a few more years at least we'll be able to say I told you so. The most probable outcome is that both SOAP and WSDL go the way of the EJB (finally consigned to the niche they belong in, ultimately fading into the obscurity of "bad idea").

    I've heard a lot on this thread about how SOAP and WS-I are easy to use. That's not the point! They have no obvious advantage over more flexible systems (such as pure XML-over-http with an unrestricted XML schema). And they have many clear disadvantages. WS-I is simply an attempt to make a system that I don't need, workable. Look, taking a trip to the south pole may now be easy and affordable by many metrics, but I'd just rather not go there.