Discussions

News: SOA? CORBA? The Acronym Changed, Situation Remains

  1. SOA (Service-Oriented Architecture) seems to be the buzzword everywhere!!! SOA will solve all the problems, everyone wants SOA -- or so I hear. Anyway, I remember similar claims when CORBA was coming to town. It was supposed to change the way IT does business. To me SOA is XML/SOAP based CORBA with evolving standards around it... I might be wrong. Yet here we are and very little has changed. Well, maybe not, one thing is for sure -- IT complexity is growing at an alarming rate and I am wondering -- how much complexity can we a take until we loose control. IT shops take this concern seriously and spend big bucks trying to manage this complexity. I have a question --- Will introduction of SOA help IT better manage complexity and reduce cost or will it fail just like its predecessor? So far I see lots of traction in the field, but also a lot of skepticism. What I do know for sure, is that organizations have to find new ways of leveraging technology and turn it into a competitive advantage. Managing thi new growing complex environment is going to be challenging. In my view introduction of SOA will push IT complexity beyond a point that can be effectively managed by todays management infrastructure. Why do I say that? Several reasons: --SOA based applications will require management tools that will need to adapt to changing requirements much faster then can be accomplished using todays management tools --SOA based applications would be able to connect a vast array of disintegrated processes together creating a level of of interconnectedness that can no longer be handled by event based health monitors. --The number of tools and technologies required just to manage and a SOA environment in itself creates a management and complexity overhead. Complexity simply will grow exponentially if not managed properly or methodically reduced and simplified. So SOA infrastructure has a potential of bringing a complex environment that is out of control and much more difficult to manage then typical 3 tier, client/server or monolithic applications. So how do we deal with the benefits on one end and growing complexity on the other? Well I believe there is only 1 way to do this -- investment in SOA governance tools and practices. This means not only technologies, but also skills, processes and practices. There are several methods that look very attractive: *Virtualization -- one way to deal with complexity is try to simplify the environment -- do more with less -- less hardware, less network, less software. Less is more very often. *Create and Maintain Capability Matrix -- rather then tools matrix and map tools you have to capabilities. Obviously you need to have all critical capabilities fulfilled by at least one technology or tool. Duplicates can be eliminated. Think in terms of technology capabilities rather then tools and technologies. Use this matrix to simplify your environment. *Use KISS approach -- I like this approach since my college years. Keep It Stupid and Simple. Apply it in every possible aspect. Complicated setup are hard to maintain and manage. If left unchecked the benefits of SOA (and there are many) will be eroded by increased maintenance, degradation of quality of service , loss of revenue and customer loyalty. So implementing a successful SOA environment is about well balanced growth -- focusing not just on adding capabilities but also looking into how to reduce the complexity. Albert Amashev is a seasoned technology professional, and has worked in many large enterprise integration exercises. His professional interest lies in IT integration, performance tuning, and service-oriented architecture (SOA).

    Threaded Messages (169)

  2. Completely agree. SOA is another hype. It offers absolutely NOTHING new that CORBA did not already have. Even the process of generating the "stub" and "proxy" is the same.
  3. SOA is not HTTP WS[ Go to top ]

    It's pretty disappointing to see that the author does know nothing of what SOA really is. SOA is not HTTP web services. I repeat SOA is not HTTP web services. A service is a stateless asynchronous unit of work exposed on a messaging infrastructure. SOAP is the standardized message envelope. A service is based on document exchange, not on parameters based signatures. Loose coupling is the key here. CORBA is is a synchronous tight coupling technology. Really a different beast from an SOA infrastructure. And moreover SOA infrastructure allows for mediation services (such as routing, transforming, ...). CORBA doesn't allow mediation. So don't swallow marketing hype and see that soa is not a miracle product but a better architecture for system integration.
  4. Re: SOA is not HTTP WS[ Go to top ]

    Well it is interesting to see that some of you focused on HTTP and SOA. I was not trying to say that SOA is HTTP web services. My point is too fold, CORBA was a similar technology but fell short of the its hyped expections. Second, the point of the post is complexity and how it should be managed. SOA and HTTP comparison was a deliberate simplification to evoke some discussion. I hope that clears it up.
  5. Re: SOA is not HTTP WS[ Go to top ]

    It's pretty disappointing to see that the author does know nothing of what SOA really is.
    SOA is not HTTP web services. I repeat SOA is not HTTP web services.
    A service is a stateless asynchronous unit of work exposed on a messaging infrastructure. SOAP is the standardized message envelope. A service is based on document exchange, not on parameters based signatures.
    Loose coupling is the key here. CORBA is is a synchronous tight coupling technology.
    CORBA is a synchronous tight coupling ???? Oh my God !!! The truth is the you can use CORBA object as you want. Answering to some other post regarding equivalence of SOA (read here web services) and CORBA because of proxy generation etc, I would say that it is absolutely false. There is a huge gap between the two's because of portable layer for both client and server available with CORBA. Guido
  6. Re: SOA is not HTTP WS[ Go to top ]

    It's pretty disappointing to see that the author does know nothing of what SOA really is. SOA is not HTTP web services. I repeat SOA is not HTTP web services. A service is a stateless asynchronous unit of work exposed on a messaging infrastructure. SOAP is the standardized message envelope. A service is based on document exchange, not on parameters based signatures. Loose coupling is the key here. CORBA is is a synchronous tight coupling technology. Really a different beast from an SOA infrastructure. And moreover SOA infrastructure allows for mediation services (such as routing, transforming, ...). CORBA doesn't allow mediation. So don't swallow marketing hype and see that soa is not a miracle product but a better architecture for system integration.
    Exactly, particularly the "better architecture for system integration" part. It's a blind alley when folks start looking at SOA as a coding initiative instead of an architectural one. The programming preferences inside a loosely coupled, integration first SOA will change, but the loose coupling and integration first mindset won't. As you noted, SOA is specifically NOT object-oriented. It's not easy to achieve (what in IT is easy to achieve?), but it's important to remember that widely distributed services and highly integrated systems are here. This isn't science fiction. Thousands of IT shops are doing it today.
  7. Completely agree. SOA is another hype. It offers absolutely NOTHING new that CORBA did not already have. Even the process of generating the "stub" and "proxy" is the same.
    Are you sure you know what you are agreeing with or even talking about? Are you sure you aren't mixing up web services with SOA? If not, can you explain to me how to generate a stub and proxy on an architecture?
  8. I really get a good laugh at how people try to use punchlines in IT as if they are politicians. Whenever they explain what SOA is, a flood of terms like "enterprise", "management", "services" immediately pours out, as if SOA is the new thing that gave us distributed enterprise software. Okay, has anyone seen a SOA project that does not use web services? The reason so many of us equate SOA with web services is because in practice they always go together, and because people are always tell us what SOA is not but can't seem to tell us what is new about it. Sorry to be the one that says the emperor has no clothes.
  9. I really get a good laugh at how people try to use punchlines in IT as if they are politicians. Whenever they explain what SOA is, a flood of terms like "enterprise", "management", "services" immediately pours out, as if SOA is the new thing that gave us distributed enterprise software.

    Okay, has anyone seen a SOA project that does not use web services?
    yes.
    The reason so many of us equate SOA with web services is because...
    You are confused?
    in practice they always go together, and because people are always tell us what SOA is not but can't seem to tell us what is new about it.
    I'll tell you what is new about it: Basically nothing. That's why it's a good thing. It's derived from proven strategies and not the brainchild of some 'genius' sitting around trying to come up with the new thing.
  10. I'll tell you what is new about it: Basically nothing. That's why it's a good thing. It's derived from proven strategies and not the brainchild of some 'genius' sitting around trying to come up with the new thing.
    +1 Thanks. I was trying to make that point with CORBA too but probably failed. Good ideas build off of what has come before but try to solve the dead ends (real or conceptual) that limited their predecessors. To judge SOA because it is similar to earlier strategies is pointless. It may be more interesting to argue if SOA has correctly solved the limitations of the earlier attempts.
  11. Okay, has anyone seen a SOA project that does not use web services?
    Yes, here's one. Mind you, I'm reading your use of "Web services" as Web services using SOAP, WSDL, etc. The world literally abounds with projects like the one I've hyperlinked to.
  12. Okay, has anyone seen a SOA project that does not use web services?


    Yes, here's one. Mind you, I'm reading your use of "Web services" as Web services using SOAP, WSDL, etc. The world literally abounds with projects like the one I've hyperlinked to.
    I glanced through the article and did not see what technology it is using for the communication between the presentation layer(JSP & Struts) and the business layer(WebSphere). It might be web services(SOAP-based). If you are counting a web-base UI interface as SOA, then what isn't SOA. If so, Amazon.com, with its ability to take order, process payment, and search products online, was SOA since 1996, long before the term even existed. Again, somebody please tell me what is SOA and why is it a unique concept?
  13. Okay, has anyone seen a SOA project that does not use web services?


    Yes, here's one. Mind you, I'm reading your use of "Web services" as Web services using SOAP, WSDL, etc. The world literally abounds with projects like the one I've hyperlinked to.


    I glanced through the article and did not see what technology it is using for the communication between the presentation layer(JSP & Struts) and the business layer(WebSphere). It might be web services(SOAP-based).

    If you are counting a web-base UI interface as SOA, then what isn't SOA. If so, Amazon.com, with its ability to take order, process payment, and search products online, was SOA since 1996, long before the term even existed.

    Again, somebody please tell me what is SOA and why is it a unique concept?
    If you read the article, the author states explicitly he isn't using SOAP or a message bus. Two of the main things in the project were separating the business logic from the implementation and the creation of a data abstraction layer. I don't want to rewrite the article, the author does an excellent job of explaining himself. Most app dev shops don't work per the "lessons learned" section in the piece. Frankly, that's the unique concept. It's as much cultural/behavioral as anything else. The way you've done things isn't going to be the way you do things in the future. Huge numbers have already adapted. If you're looking for a definition, here's a slew of them. None of them are groundbreaking (or new, seeing that they were written in 2004). Getting back to a point made above, SOA isn't an attempt to sell this new slick thing. It's more akin to Copernicus noting that the sun, and not the earth, is the center of our solar system. The sun wasn't new, nor was the earth and the rest of the planets. Heck, the notion that the sun was the center of the solar system wasn't even anything new. Yet it caused an uncomfortable reorientation for a lot of folks. SOA requires people who've probably been quite comfortable to get a new set of bearings.
  14. SOA isn't an attempt to sell this new slick thing. It's more akin to Copernicus noting that the sun, and not the earth, is the center of our solar system. The sun wasn't new, nor was the earth and the rest of the planets.
    Okay, I think I'm getting warmer. SOA is like the discovery that the sun is the center, not the earth. So we have been using SOA from day one but we just didn't know it. That's why we should re-engineer all our software systems to do exactly what we've been doing before now that we know what it is called. Got it...
  15. Okay, I think I'm getting warmer. SOA is like the discovery that the sun is the center, not the earth. So we have been using SOA from day one but we just didn't know it. That's why we should re-engineer all our software systems to do exactly what we've been doing before now that we know what it is called. Got it...
    I sincerely doubt you've been doing it all along. I mean, congratulations if you have, but I'm guessing that like most you've been building monolithic apps with business logic tied to the implementation. The point is the way you're using the stuff you've got on hand probably needs a severe change. You wouldn't build a car the way you build an app. Prior to Henry Ford people did exactly that, but better engineering principles won out.
  16. SOA isn't an attempt to sell this new slick thing. It's more akin to Copernicus noting that the sun, and not the earth, is the center of our solar system. The sun wasn't new, nor was the earth and the rest of the planets.


    Okay, I think I'm getting warmer. SOA is like the discovery that the sun is the center, not the earth. So we have been using SOA from day one but we just didn't know it.
    Non-sequitur. The sun always was the center of the solar system but all systems used to predict it's path across the sky did not assume this. The knowledge simplified and improved these systems and made the old ways of doing things obsolete. There is a lot that is done that is not SOA. Your insistence that SOA is meaningless prevents you from understanding that.
  17. Your insistence that SOA is meaningless prevents you from understanding that.
    I am insisting that SOA is nothing new, which many seem to agree, and therefore does not deserve all the hype. If the IT industry is about innovation, and we are hyping SOA knowing that it is nothing new, then we are in a pretty sad state of affair.
  18. Your insistence that SOA is meaningless prevents you from understanding that.


    I am insisting that SOA is nothing new, which many seem to agree, and therefore does not deserve all the hype.
    Hype is inherently undeserved.
    If the IT industry is about innovation, and we are hyping SOA knowing that it is nothing new, then we are in a pretty sad state of affair.
    I'm going to assume you are familiar with Design Patterns. You realize that all the patterns in the GoF book were 'nothing new', right? Yet, when this book came out, it completely changed the way we talk about Object Oriented design. The patterns were nothing new. It was the terminology that was new. SOA merely gives us a common language around a set of design principles that have proven to be better than other well known principles. The fact of the matter is that most shops are not SOA, regardless of what they claim and many people are unaware of the bad choices they are making on a daily basis. I have to try to integrate with products that do not provide services. This is a nightmare. We have to do all kinds of crazy stuff like screen-scraping to try to get things to work together. It's time consuming and costly. You think that having services to tie into is no big deal? I don't get your viewpoint at all.
  19. I'm going to assume you are familiar with Design Patterns. You realize that all the patterns in the GoF book were 'nothing new', right? Yet, when this book came out, it completely changed the way we talk about Object Oriented design. The patterns were nothing new. It was the terminology that was new. SOA merely gives us a common language around a set of design principles that have proven to be better than other well known principles. The fact of the matter is that most shops are not SOA, regardless of what they claim and many people are unaware of the bad choices they are making on a daily basis.

    I have to try to integrate with products that do not provide services. This is a nightmare. We have to do all kinds of crazy stuff like screen-scraping to try to get things to work together. It's time consuming and costly. You think that having services to tie into is no big deal? I don't get your viewpoint at all.
    I can accept SOA as a set of design principles, but that is certainly not how they are spinning it out there. The "SOA is everything and nothing at the same time" definition is a disgusting marketing deploy.
  20. I can accept SOA as a set of design principles, but that is certainly not how they are spinning it out there. The "SOA is everything and nothing at the same time" definition is a disgusting marketing deploy.
    Who cares about how marketing is spinning things? Why is that relevant on a technical site such as this? Are you saying we should reject a perfectly good idea because some vampires in marketing got their fangs into it? OO was hyped up in much the same way not that long ago. I'm sure there were a lot of people claiming that it was just some nonsensical thing that would go away once the hype was over. The hype is over and people are still using OO. Just because there is hype around something doesn't mean it's not real.
  21. I can accept SOA as a set of design principles, but that is certainly not how they are spinning it out there. The "SOA is everything and nothing at the same time" definition is a disgusting marketing deploy.


    Who cares about how marketing is spinning things? Why is that relevant on a technical site such as this? Are you saying we should reject a perfectly good idea because some vampires in marketing got their fangs into it?

    OO was hyped up in much the same way not that long ago.
    I think most people in here just are somehwat lets say it mildly angry, that the same thing has been hyped over and over again the last 10 years under different names. Now the same things are dug up again under a different name, and the hype is even more, while the normal developmet process just does what has to be done (SOA, non SOA whatever)...
  22. I can accept SOA as a set of design principles, but that is certainly not how they are spinning it out there. The "SOA is everything and nothing at the same time" definition is a disgusting marketing deploy.


    Who cares about how marketing is spinning things? Why is that relevant on a technical site such as this? Are you saying we should reject a perfectly good idea because some vampires in marketing got their fangs into it?

    OO was hyped up in much the same way not that long ago.


    I think most people in here just are somehwat lets say it mildly angry, that the same thing has been hyped over and over again the last 10 years under different names. Now the same things are dug up again under a different name, and the hype is even more, while the normal developmet process just does what has to be done (SOA, non SOA whatever)...
    What has been hyped up in the last 10 years that you believe to be equivalent to SOA?
  23. I can accept SOA as a set of design principles, but that is certainly not how they are spinning it out there. The "SOA is everything and nothing at the same time" definition is a disgusting marketing deploy.


    Who cares about how marketing is spinning things? Why is that relevant on a technical site such as this? Are you saying we should reject a perfectly good idea because some vampires in marketing got their fangs into it?

    OO was hyped up in much the same way not that long ago.


    I think most people in here just are somehwat lets say it mildly angry, that the same thing has been hyped over and over again the last 10 years under different names. Now the same things are dug up again under a different name, and the hype is even more, while the normal developmet process just does what has to be done (SOA, non SOA whatever)...


    What has been hyped up in the last 10 years that you believe to be equivalent to SOA?
    Corba, EJB Remote Session Beans, Soap... Ok different buzzwords, but face it the architecture designes using this stuff are plain SOA, by the definition, if a definition of SOA at all exists behind the hype. As someone else said, once the hype has ceased it will be interesting to review which technologies out of this hype are there to stay. As for adoption, the adoption rate of all this stuff is slow, because it is there already in many places where it is needed, but it just is not called SOA, because there still is not clear definition of soa, except that you expose a service over remote protocols for others and the architecture itself is loosely connected over those services (does that sound familiar? Exactly, those architectures were done in the past as well, and most of them failed because they applied a way to fine binding granularity) As I said, SOA is the latest marketing hype to sell old stuff, as for every hype where money is in some interesting stuff is developed while the hype and money is there, after everything has calmed down to a sane level it is time to check which technologies are persistent enough to survive the hype, and which projects have been gone down in flames and which survived. I can remember the last hype AOP two years ago, I have yet to see a fully AOPed design, but I have seen many systems where AOP is introduced as supporting layer where it made sense. From all the AOP tools only two basically in the java world have survived and lots of these things were there before it was called AOP, always the same, only with SOA it is even worse because it is rebranded stuff, the third time rebranded!
  24. What has been hyped up in the last 10 years that you believe to be equivalent to SOA?


    Corba, EJB Remote Session Beans, Soap...

    Ok different buzzwords, but face it the architecture designes using this stuff are plain SOA, by the definition, if a definition of SOA at all exists behind the hype. SOAP is a transfer protocol. It has no similarity to SOA. EJB Session beans are a very specific technology. Not similar to SOA. CORBA is also a communications protocol and is not really comparable to SOA. SOAP and the old versions of EJB are crap (it remains to be seen with the new version of EJB IMO.) EJB has been rebuilt from the ground up and SOAP is becoming less important every day. Part of the problem with these kinds of technologies is that people didn't know how to use them effectively. SOA is a strategy. It's not a protocol and it's not a technology. That you believe that SOAP is like these things demonstrates that you really don't know what it is at all. I think you should try to understand what something is before dismissing it. Having said that, it's hard to find out what SOA actually is because there are so many people explaining it incorrectly or poorly and then bunch of people screaming about how it's nothing (e.g. you). If you want a basic introduction, here's something that will get you started. I'm not going to swear by everything he says but it's definitely along the right lines: http://webservices.sys-con.com/read/136190.htm
  25. I read the article, and I've never read that much bullshit about SOA. Really the author does not have a clue about what SOA is about. But I was relieved to read James Watson's post, that tried to clarify that SOA is not about tecnology to integrate applications. Instead, it is about how to manage the integration in a way to ease manageability and increase flexibility. So, if your "SOA" usage is increasing complexity, then you're applying the wrong concepts. Anyway, SOA is not a "silver bullet", as nothing is. People tend to apply the same solutions to all problems. SOA will probably agregate no value to 80% of the systems.
  26. I read the article, and I've never read that much bullshit about SOA. Really the author does not have a clue about what SOA is about.
    Can you explain what is incorrect? Just one specific example.
  27. James,
    I read the article, and I've never read that much bullshit about SOA. Really the author does not have a clue about what SOA is about.


    Can you explain what is incorrect? Just one specific example.
    To me SOA is XML/SOAP based CORBA with evolving standards around it
    SOA is not technology.
    SOA will push IT complexity beyond a point that can be effectively managed
    If you really use SOA, it will push the point that can be managed beyond the complexity.
    SOA based applications will require management tools that will need to adapt to changing requirements
    Non-SOA based applications also require tools that will need to adapt to changing requirements. SOA based applications will allow the faster adaptation to changing requirements.
    SOA based applications would be able to connect a vast array of disintegrated processes together creating a level of of interconnectedness that can no longer be handled by event based health monitors.
    There shall be no interconnection between services in SOA, except for choreography, which is not interconnection.
    SOA infrastructure has a potential of bringing a complex environment that is out of control and much more difficult to manage then typical 3 tier, client/server or monolithic applications
    Only if you think SOA means to tie sofware in pairs of client-servers using Web Services. I have to admit that, at the first time, I stopped reading at that sentence. But, after I came back to the article, I saw:
    investment in SOA governance tools and practices. This means not only technologies, but also skills, processes and practices
    I agree with this one. Actually, it's not SOA if there are no process and tools to handle governance. Anyway, James, I thought your post disagreed with every sentence I quoted from the article. Specially the first one. Was I wrong?
  28. Anyway, James, I thought your post disagreed with every sentence I quoted from the article. Specially the first one. Was I wrong?
    Sorry for the confusion. I posted a link to another article and you replied shortly thereafter. I thought you meant the article I posted a link to. And yes you understood me correctly. I apologize for being a little too terse in my question. There have been a lot of people making claims about BS without backing them up with any specifics. But we are on the same page, definitely.
  29. I read the article, and I've never read that much bullshit about SOA. Really the author does not have a clue about what SOA is about.

    But I was relieved to read James Watson's post, that tried to clarify that SOA is not about tecnology to integrate applications. Instead, it is about how to manage the integration in a way to ease manageability and increase flexibility. So, if your "SOA" usage is increasing complexity, then you're applying the wrong concepts.

    Anyway, SOA is not a "silver bullet", as nothing is. People tend to apply the same solutions to all problems. SOA will probably agregate no value to 80% of the systems.
    I think complexity of going with loosely couple apps is largely underestimated. You see, lets say your clients of the SAO based application experiencing performance degradation, how do you determine the root cause? With loosely coupled apps it is a much more challenging effort. When I wrote about complexity of SAO I meant not "Development" or "integration", I meant production level support of loosely coupled entities. In my experience companies spend counteless hours chasing problems with "teams" of people trying to figure out where the problem is. It is strange that most people here picked on SOA/CORBA statement, while I am really trying to say is the complexity that will arize as a result of ease of integration, orchestration and collaboration that would create an interconnection mesh that would have to be managed carefully.
  30. Rodrigo. I'll jump in this line since I feel is the most sane in the whole discussion. Yep, I read the article too, and although the guy has very good lines in it, it starts by falling into the same error a bunch on writers here falls too. Just in reading the part of the vendor-oriented service-orientation, Thomas mentions something like "core expectation of SOA is its ability to harmonize and streamline diverse technical environments". Probably it may be a sell point for IT, but in fact that is a side effect (not often achieved). The core expectation in an SOA is to model an application in the problem space using a business service metaphor. In another line, Thomas says "Like traditional multitiered architectures, SOA is based on a model wherein solution logic is distributed". That is a trap. Services should be thought as complete business functionality offered no by methods or classes, but by services. Distribution leads to segmentation of code and business logic, and it is a technical strategy. SOA is about definition of business functionality as a whole (which may be internally implemented as a distributed thing). That is a bad approach, SOA is not to distribute, it is not DCOM over HTTP. I Agree with Watson too. Although, he is still thinking in SOA as a technology issue pain reliever. SOA is about managing not technology but business. And the complexity is not about the concepts or technologies used, is about the impedance mismatch obtained by mixing them. Agree, again, SOA is not a silver bullet. Jump into the buzz word bandwagon antipattern. William Martinez Pomares
  31. Rodrigo.
    I'll jump in this line since I feel is the most sane in the whole discussion.

    Yep, I read the article too, and although the guy has very good lines in it, it starts by falling into the same error a bunch on writers here falls too. Just in reading the part of the vendor-oriented service-orientation, Thomas mentions something like "core expectation of SOA is its ability to harmonize and streamline diverse technical environments". Probably it may be a sell point for IT, but in fact that is a side effect (not often achieved). The core expectation in an SOA is to model an application in the problem space using a business service metaphor.
    One of the things to realize about this article is that it's essentially a study of what the general understanding of SOA is in IT. I agree with you but I think Erl's point is correct. This is one of the expectations of SOA.
    In another line, Thomas says "Like traditional multitiered architectures, SOA is based on a model wherein solution logic is distributed". That is a trap. Services should be thought as complete business functionality offered no by methods or classes, but by services. Distribution leads to segmentation of code and business logic, and it is a technical strategy. SOA is about definition of business functionality as a whole (which may be internally implemented as a distributed thing). That is a bad approach, SOA is not to distribute, it is not DCOM over HTTP.

    I Agree with Watson too. Although, he is still thinking in SOA as a technology issue pain reliever. SOA is about managing not technology but business. And the complexity is not about the concepts or technologies used, is about the impedance mismatch obtained by mixing them.

    Agree, again, SOA is not a silver bullet.
    I think your point is valid although I'm still not sure you are disagreeing with Erl as much as making qualifications. Not that I think Erl is the bible or anything. I've just found him to be a good start to get away from the vendor "me too" definitions. I think once one gets the basic idea people can formulate their own ideas about how to get it done. In any event, thanks for contributing your comments to the discussion. They have been very well worth reading. Do you have any online articles or other resources I could look at?
  32. You know, I think you are right. The article shows Earl's vision of actual SOA as it is seen in general. That doesn't mean that he is setting the expectations, still he is not saying that is incorrect. Probably I am. I have not really valuable links. I still find some fun ones, like a blog I remember where the author was very happy of finally understanding REST. That makes me thing there are lots of people our there embracing a buzz word without understanding that it really means. In here I found an interesting way of seeing SOA, using a regular method of quadrants of two variables. Big SOA and little SOA are just a way of seeing what people think and what they actually do. I don't completely agree with the values of the variables at each quadrant, but I think the explanation is clear. William Martinez.
  33. You know, I think you are right. The article shows Earl's vision of actual SOA as it is seen in general. That doesn't mean that he is setting the expectations, still he is not saying that is incorrect. Probably I am.

    I have not really valuable links.
    I actually meant: have you written anything yourself? You seem to have a firm grasp on this and are able to explain it.
  34. I see. It seems I keep misunderstanding things. No, sorry, nothing directly related. I'm in the way to start a blog, but nothing else. I did some work with Frank Cohen (still working with him). Did a technical revision of his latest book, FastSOA, and helped a little bit with a couple of articles. Did some research for white papers but my name is not on them. Wrote a book on It Project Planning and Evaluation (in spanish), used in the local university (Costa Rica). Apart from that, I keep away from publishers. This is the site I write more whenever there is a philosophical discussion. They are fun. William Martinez Pomares.
  35. I think most people in here just are somehwat lets say it mildly angry, that the same thing has been hyped over and over again the last 10 years under different names. Now the same things are dug up again under a different name, and the hype is even more, while the normal developmet process just does what has to be done (SOA, non SOA whatever)...
    And if you believe this to be true, why is it that I currently lack services to call from our vendors? Why is it that hardly anyone understands the basic concepts of SOA? If this were really just what everyone has been doing, why is there so much work needed to be done to get to a service-oriented architecture everywhere I look? Why are there so many impenetrable silos? Why do vendors continue to trap their business logic in user interfaces?
  36. The root of the problem...[ Go to top ]

    If this were really just what everyone has been doing, why is there so much work needed to be done to get to a service-oriented architecture everywhere I look? Why are there so many impenetrable silos? Why do vendors continue to trap their business logic in user interfaces?
    Judging by this, you're missing the one common denominator in every IT shop in the entire world. It's also the most prevalent problem among vendors. Indeed, this one common fact causes about 99% of all the problems in the IT industry as we know them. And the golden nugget of truth is...
    The vast majority of people in our industry are stark raving idiots.
    ... or revised for vendors ...
    The vast majority of vendors in our industry are stark raving (and voraciously greedy) idiots.
    There you have it. The source of virtually all the problems. Laugh all you want, or accuse me of not contributing anything substantive to the discussion, but the truth of the matter is that there are lots of stupid / greedy people out there. Until we start recognizing and referring to them as exactly what they are... stupid and greedy, the problem isn't going to go away. Case in point... every organization I've worked in or with over the past 2 years has claimed, "we do services already". And yes, they stated it exactly like that... they "do" services... like services are a cheap street walker or something. What they mean by that is they have fine grained functions exposed as web services (or worse). Yup, you guessed it, things like, getMemberFirstname, getMemberLastName, getMemberAddress (debatable). And yet they all "do services". Their services are "aimed" at implementation details, more often than not data access logic, rather than at business processes where they should have been. And as a result, they had massive governance and maintenance issues, and never fully realized the benefits of the architecture. But that's not what makes them stupid, oh no. What makes them stupid is that when they're confronted with the fact that they've screwed up the architecture, they vehemently defend it as "SOA enough". In all cases, it's taken long periods of time, and repeated instruction from people outside the organization (read: overpaid, yet highly trusted consultants) to convince them they hosed it up. But here's the kicker. It never would have been fixed if not for somebody repeatedly and sometimes brazenly pointing out how screwed up and wrong it was. The organization as a whole was more than happy to languish in mediocrity and touchy feely niceties by telling the architects that it was "ok" and "good enough". Crap. Fix it. You broke it, now go fix it dummy. I feel your pain. Trust me. But the fact is that until people start looking at the vast majority of vendors (or fill in your choice of hype perpetuator) and calling them blatant liars, people will continue listening to them and the waters will become even more murky. That same thing goes for the Gartners and other "authorities" who advise CIO's on what the next hot thing is. If something is screwed up, it's up to us to call it out. And just because SOA is over hyped (which I totally agree with by the way) doesn't make it any less valuable of a paradigm shift. The fact is that you're right, the vast majority of people really don't get it. But they sure could benefit from it if they learned the right things about it and not what some vendor sold them during a 90 second sales call. Back to the original point of the article (not CORBA vs. SOA debate), I see the move to SOA as being more of a unifying and simplifying force rather than the complexity-engine the author is describing. What about an SOA architecture, aside from versioning which most of us have to deal with in some form anyway, is significantly harder to manage than what most of us are currently doing? And what overwhelming benefit is a proprietary tool stack going to give me that will outweigh the agility and adaptability of a well thought out, common sense based approach to governance? Oh and in case anyone was wondering, the other 1% of problems are caused by an equal division of end users and printers. This job would be great if it weren't for those two things. ;)
  37. I can accept SOA as a set of design principles, but that is certainly not how they are spinning it out there. The "SOA is everything and nothing at the same time" definition is a disgusting marketing deploy.


    Who cares about how marketing is spinning things? Why is that relevant on a technical site such as this? Are you saying we should reject a perfectly good idea because some vampires in marketing got their fangs into it?

    OO was hyped up in much the same way not that long ago. I'm sure there were a lot of people claiming that it was just some nonsensical thing that would go away once the hype was over. The hype is over and people are still using OO. Just because there is hype around something doesn't mean it's not real.
    I think the real question is how to unlock the value SOA enabled infrastructure, what tools to invest in, what best practices to use and refine, what skillsets and processes need to put in place. Migrating to a SOA enabled infrastructure seems like and evolutionary progression, going from A to B to Z in a methodical fashion. Hype is created by vendors trying to cash in on trends that are already in place. At the same time, hype allows inflow of capital and investment that contributes to the growth of any technology area including SOA. So hype is not necessarily bad. Also how to you sell the idea to CEO or CIO, you need a "word", a slogan and a great promise. The promise sometimes too far fecthed and far away from reality.
  38. Hi Albert. Hard to keep on reading all the messages (jumped late to the discussion). But I think I have a couple of interesting points I want to highlight. 1. Goosh. The debate between WS people and Corba people is always the same. I do teach Web Services course at university, and I see the same ideas back and forth in my students. WS IS NOT distributed components. CORBA is about a broker pattern for distributed components, and WS is about business service metaphors and how to communicate with them using messages. Apples and Oranges. 2. SOA refers not to a technology, as many pointed out, but to a supra design in the problem space. Yep, nothing related to the implementation, but to the business level. Services are aimed to architecturally designing the business processes using the Service metaphor as the building blocks. The problem here is designers are not architects nor business people, but plain developers that, by the way, worship OO and RPC. 3. Getting to your point, I understand CORBA suffered from complexity in implementation, and lack of governance tools. But Orchestration (different from governance and even choreography) probably was not needed (there was the broker in the center). Services are other things. The messaging system is the one that requires orchestration, choreography and governance. Services need to be designed, as business entities, with lax interfaces that are business oriented. No RPC. And so, you need also governance of business processes. Since the actual market sells tools to OO developers, they are oriented to the RPC governance and emphasizing the call flow and not the messaging manipulation. By this I mean that the tools should have two levels, the one for developers, that should be in the cubicles implementing the utility classes for the service implementation, and master designers with business background designing the services per se. And then, IT support controlling the messaging system pitfalls, and business people controlling the business flows. If you want to compare CORBA and SOA complexity in governance and orchestration, then I would say they are different. And I would say lots of people don't really know what are they calling SOA anyway, which makes it even harder. William Martinez Pomares.
  39. SOA isn't an attempt to sell this new slick thing. It's more akin to Copernicus noting that the sun, and not the earth, is the center of our solar system. The sun wasn't new, nor was the earth and the rest of the planets. Heck, the notion that the sun was the center of the solar system wasn't even anything new.

    Yet it caused an uncomfortable reorientation for a lot of folks. SOA requires people who've probably been quite comfortable to get a new set of bearings.
    Ahem after having seen Corba, EJB, Soap, etc... I have the feeling, that SOA is the guy 300 years after copernicus claiming that he found out that the Earth is not the Center of the solar system, but the Sun is, and the reason for his claim is that he thinks he can produce massive hype and cash in... Thats what I feel about SOA ;-)
  40. Ahem after having seen Corba, EJB, Soap, etc...
    I have the feeling, that SOA is the guy 300 years after copernicus claiming that he found out that the Earth is not the Center of the solar system, but the Sun is, and the reason for his claim is that he thinks he can produce massive hype and cash in...
    Thats what I feel about SOA ;-)
    Warnings about conflating SOA with specific technologies aside, there we plenty of of folks noting the sun was the center of the solar system for 16 centuries before Copernicus. The point being, it's not the discovery, but the adoption. The concept was nothing new, the change was that finally the illustrators were willing to redraw the maps. Are some folks going to cash in on SOA? Sure. Some folks always do. Doesn't make monolithic apps any better of an idea though.
  41. Okay, has anyone seen a SOA project that does not use web services?


    Yes, here's one. Mind you, I'm reading your use of "Web services" as Web services using SOAP, WSDL, etc. The world literally abounds with projects like the one I've hyperlinked to.
    It does say it's not using web services. It looks like everybody wants to slap the SOA bumper sticker on their project. So how is this "SOA" project different from other "non-SOA" web-app projects? Is it the three-tier separation or the functionality?
  42. It does say it's not using web services. It looks like everybody wants to slap the SOA bumper sticker on their project.

    So how is this "SOA" project different from other "non-SOA" web-app projects? Is it the three-tier separation or the functionality?
    I think part of your problem is that you've not understood the service-orientation part. Once you understand that, then SOA is fairly easy to understand. Service-Orientation is a design approach much like OO is a design approach for developing software. This is why you are not going to get a succinct answer to your question. SOA and 3-tier are orthogonal concepts. SOA doesn't define any specific functionality. And yes, everybody does want to slap the SOA bumper sticker on their project and a lot of them understand it no better than you do. You are actually way ahead of a lot of these people because they think they understand it. What does it mean to you when we talk of a 'service'? Does it mean anything special to you?

  43. Service-Orientation is a design approach much like OO is a design approach for developing software. This is why you are not going to get a succinct answer to your question.

    SOA and 3-tier are orthogonal concepts. SOA doesn't define any specific functionality.

    And yes, everybody does want to slap the SOA bumper sticker on their project and a lot of them understand it no better than you do. You are actually way ahead of a lot of these people because they think they understand it.

    What does it mean to you when we talk of a 'service'? Does it mean anything special to you? I understand OO because it is there are features like polymorphism and inheritance that are not found in procedural languages. But I have yet seen or heard one thing that is unique about SOA or services. My point is that these concepts are as old as the history of network programming itself.
  44. I understand OO because it is there are features like polymorphism and inheritance that are not found in procedural languages. But I have yet seen or heard one thing that is unique about SOA or services. My point is that these concepts are as old as the history of network programming itself.
    The core concept of OO is the Object. This is why it's called Object-Oriented and not polymorphism-oriented or inheritance-oriented. Not to mention that if we are talking about poorly defined terms, polymorphism means a lot of different things to a lot of different people. Perhaps you understand OO less than you believe. I will assume that your refusal to answer the question means that you do not in fact understand what a 'service' is.
  45. I understand OO because it is there are features like polymorphism and inheritance that are not found in procedural languages. But I have yet seen or heard one thing that is unique about SOA or services. My point is that these concepts are as old as the history of network programming itself.


    The core concept of OO is the Object. This is why it's called Object-Oriented and not polymorphism-oriented or inheritance-oriented. Not to mention that if we are talking about poorly defined terms, polymorphism means a lot of different things to a lot of different people. Perhaps you understand OO less than you believe.

    I will assume that your refusal to answer the question means that you do not in fact understand what a 'service' is.
    Go look up polymorphism and inheritance in 5 programming books and see if you get 5 different definitions. Object is not a new concept introduced by OO. It had always been around to refer to a logical group of organized data in memory. Polymorphism and inheritance are. You are right. I don't know what you are talking about by 'service' in SOA. What is this 'service' you speak of?
  46. Go look up polymorphism and inheritance in 5 programming books and see if you get 5 different definitions.
    You can find a number of definitions in one place: http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
    Object is not a new concept introduced by OO. It had always been around to refer to a logical group of organized data in memory.
    That's actually not what an Object is in OO. The core idea behind OO is that an Object joins data and the operations associated with it.
    Polymorphism and inheritance are.
    Inheritance is very much over-emphasized by people without a firm grasp on OO. And by your own logic, Object Oriented programming is therefore 'nothing new'.
    You are right. I don't know what you are talking about by 'service' in SOA. What is this 'service' you speak of?
    A service is an abstraction to high-level unit of work. For example, 'Place Order' would be a service. 'Enroll Member' could be a service. A service is a well-defined, stand-alone abstraction to a business function that is accessible from many different contexts. Not all 'web-services' meet this criteria. For example, I work with some web-services that basically act as thin veneers over a database. They are not stable and provide no business logic. They force me to manage relationships and format data (things they have already implemented in their interfaces.)
  47. Inheritance is very much over-emphasized by people without a firm grasp on OO.

    And by your own logic, Object Oriented programming is therefore 'nothing new'.
    I don't want to get into OO debate here. But inheritance and polymorphism combined is a powerful new weapon that OO languages offer. You can treat an object instance as a generic type and get different behaviors/responses with the same call. This is very very new from what was available before.
  48. Inheritance is very much over-emphasized by people without a firm grasp on OO.

    And by your own logic, Object Oriented programming is therefore 'nothing new'.


    I don't want to get into OO debate here. But inheritance and polymorphism combined is a powerful new weapon that OO languages offer.
    Actually the language Simula that pioneered this concept existed before the term OO which was coined by Alan Kay, the creator of SmallTalk. Talk to an SmallTalk fan about OO and you'll get an earful about how OO as implemented in C++ in Java is not real OO.
    You can treat an object instance as a generic type and get different behaviors/responses with the same call. This is very very new from what was available before.
    Inheritance is not required for this. Classes in Java do not inherit from their interfaces. They implement them. Objects in languages like Python and Ruby do not have to have any sort of common ancestry to make use of polymorphism (the kind you mean.)
  49. Inheritance is not required for this. Classes in Java do not inherit from their interfaces. They implement them.
    It's sad that you are playing with words here. In C++ there is no interface. You want to implement an interface, make a pure virtual class and inherit from it. I was not talking about a narrow Java inheritance but the OO concept of inheritance. Call it "implement" or not, it's still inheritance. Contrary to belief, object was an old concept in computer science. The OO languages gave object new characteristics by adding mainly encapsulation of data and methods, polymorphism, and inheritance. So these features are what make an OO object different from previous definitions. You don't use all the features to name a new concept. Therefore, a name like "polymorphism,inheritance,encapsulation-oriented design" would be quite stupid. I hope you do get a concrete definition for these OO concept cus you do need them for your interviews. Telling you interviewers that different people have different definitions for basic OO concepts like these wouldn't land you a job.
  50. Inheritance is not required for this. Classes in Java do not inherit from their interfaces. They implement them.


    It's sad that you are playing with words here.
    What's sad is that you seem unable to grasp what I am writing.
    In C++ there is no interface. You want to implement an interface, make a pure virtual class and inherit from it. I was not talking about a narrow Java inheritance but the OO concept of inheritance. Call it "implement" or not, it's still inheritance.
    It's inheritance of specification. It is not inheritance of implementation. These are very different things and it's widely understood that they should not be lumped under one term. It unfortunate that you are unaware of this.
    Contrary to belief, object was an old concept in computer science. The OO languages gave object new characteristics by adding mainly encapsulation of data and methods, polymorphism, and inheritance. So these features are what make an OO object different from previous definitions.
    Do you really think this is something that everyone doesn't know? I so amusing when people talk about the most basic CS101 concepts as if they are gurus.
    You don't use all the features to name a new concept. Therefore, a name like "polymorphism,inheritance,encapsulation-oriented design" would be quite stupid.
    This conversation is stupid. You don't have the slightest clue about this. Alan Kay created the term and this is what he says about it: "- My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful. The term "polymorphism" was imposed much later (I think by Peter Wegner) and it isn't quite valid, since it really comes from the nomenclature of functions, and I wanted quite a bit more than functions. I made up a term "genericity" for dealing with generic behaviors in a quasi-algebraic form." http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht14Ht/doc_kay_oop_en Your understanding lacks depth and I find you to be a rather unpleasant person. There is nothing to be gained by conversing with you. You are unwilling to accept reality, preferring to believe that you are correct. This will be my last response to you.
  51. Your understanding lacks depth and I find you to be a rather unpleasant person. There is nothing to be gained by conversing with you. You are unwilling to accept reality, preferring to believe that you are correct. This will be my last response to you.
    Please calm down with the attacks. You have all the deep knowledge and understand about OO. Happy? At least we agree on one thing. SOA is nothing new.
  52. I really get a good laugh at how people try to use punchlines in IT as if they are politicians. Whenever they explain what SOA is, a flood of terms like "enterprise", "management", "services" immediately pours out, as if SOA is the new thing that gave us distributed enterprise software.

    Okay, has anyone seen a SOA project that does not use web services? The reason so many of us equate SOA with web services is because in practice they always go together, and because people are always tell us what SOA is not but can't seem to tell us what is new about it.

    Sorry to be the one that says the emperor has no clothes.
    I think the point is that you don't seem able to identify the emperor correctly and therefore aren't a reliable source for reporting the state of his nudity.
  53. I really get a good laugh at how people try to use punchlines in IT as if they are politicians. Whenever they explain what SOA is, a flood of terms like "enterprise", "management", "services" immediately pours out, as if SOA is the new thing that gave us distributed enterprise software.

    Okay, has anyone seen a SOA project that does not use web services? The reason so many of us equate SOA with web services is because in practice they always go together, and because people are always tell us what SOA is not but can't seem to tell us what is new about it.

    Sorry to be the one that says the emperor has no clothes.


    I think the point is that you don't seem able to identify the emperor correctly and therefore aren't a reliable source for reporting the state of his nudity.
    It's funny that no one could tell me what color is the Emperor's beautiful new rope. They just keep telling me it's not skin color. :-D
  54. Are you sure you know what you are agreeing with or even talking about? Are you sure you aren't mixing up web services with SOA?

    If not, can you explain to me how to generate a stub and proxy on an architecture?
    So let me ask you this question then. Is an design that uses CORBA an SOA? If yes, then what about EJB, RMI, or DCOM, are they SOA too? If not, then why not? what makes SOA different?
  55. Are you sure you know what you are agreeing with or even talking about? Are you sure you aren't mixing up web services with SOA?

    If not, can you explain to me how to generate a stub and proxy on an architecture?


    So let me ask you this question then. Is an design that uses CORBA an SOA? If yes, then what about EJB, RMI, or DCOM, are they SOA too? If not, then why not? what makes SOA different?
    Different than what? How is a cat different than an animal?
  56. Different than what? How is a cat different than an animal?
    Different than say client-server design?
  57. Different than what? How is a cat different than an animal?


    Different than say client-server design?
    It depends on who you talk to but SOA is decentralized for one. A service may be hosted on a mainframe or an app-server or a database. In most approaches, the client doesn't connect directly to any of these. In a client-server architecture, the client is bound to one or more servers (or cluster of servers).
  58. It depends on who you talk to but SOA is decentralized for one. A service may be hosted on a mainframe or an app-server or a database. In most approaches, the client doesn't connect directly to any of these. In a client-server architecture, the client is bound to one or more servers (or cluster of servers).
    A client-server architeture does not mean they are one-to-one and bound to each other. In companies like AOL for instance, there are numerous legacy systems written in the early 90s that talk to multiple servers directly or indirectly to get or process information. So a service hosted on a mainframe or an app-server or a database is considered SOA?
  59. Would have been an interesting post 2002...maybe...
  60. Not that SOA or CORBA are bad, but people abuse it way too much. The problem is SOA was designed to create distributed APIs, which change very slowly by nature so they provide a consistent interface, just like the JDK library and Windows API. We all hate those "moving target" APIs that change often. Yet in 90% of the projects that are not developing an API, people decided to go SOA just for the buzz word effect, thus making their systems very inflexible.
  61. What's stated in the article is sound advice for a SOA. CORBA was a step on the path to achieving scalable and distributed architectures but did not take into consideration the complexities of interoperability across ownership boundaries. The US government, for one, is spending a lot of money trying to solve the ownership boundary issues for more effective communications between government and non-government organizations. One publicly available SOA architecture initiative is currently being done for the US Department of Justice. There is also an effort currently underway within OASIS to create a SOA Reference Architecture (RA) which extends the OASIS SOA Reference Model. The OASIS SOA RA takes the approach of "technology capabilities rather then tools and technologies." In the OASIS SOA RA, governance and management are part of a view that has been defined as "Owning a SOA". Two other views are "Realizing a SOA" and "Business Via Services". IT professionals who think SOA is hype or just additions to defining an interface have yet to deal with the complexities of policy guided delivery of distributed capabilities across ownership boundaries. This is one of the monsters that SOA is trying to tame. At the time of CORBA, the IT industry was not advanced enough to consider tackling many of the problems SOA is taking on now. Danny http://www.soamodeling.org
  62. SOA (Service-Oriented Architecture) seems to be the buzzword everywhere!!! SOA will solve all the problems, everyone wants SOA -- or so I hear. Anyway, I remember similar claims when CORBA was coming to town. It was supposed to change the way IT does business. To me SOA is XML/SOAP based CORBA with evolving standards around it.
    I see CORBA as more akin to web services, a technology not an architecture. Sure there are architectural implications of using CORBA as with choosing any technology but it seems like the difference between the blueprints and the choice of construction materials. (Sigh, anybody else tired of comparing software to real-world construction?) But "architecture" is the 'A' in CORBA! True, but I'm still not sure I'd equate the two. SOA is trying to address enterprise-wide architectural and business process concerns. CORBA is simply trying to address code integration concerns. Maybe it would be more fair to equate an ESB/Web Services architecture with CORBA. But ESB/Web Services, while they can be used within an SOA, aren't SOA.
    ... I might be wrong
    indeed
    Yet here we are and very little has changed.
    Well, maybe the introduction of Java/.NET, the Internet, thin clients, mobile phones, PDAs, etc.
    Well, maybe not, one thing is for sure -- IT complexity is growing at an alarming rate and I am wondering -- how much complexity can we a take until we loose control.
    Too late I'm afraid in most of the shops I visit. I think the movement toward SOA is an attempt to regain some control.
    IT shops take this concern seriously and spend big bucks trying to manage this complexity. I have a question --- Will introduction of SOA help IT better manage complexity and reduce cost or will it fail just like its predecessor?
    Why do people always assert that technologies like CORBA failed? CORBA was invented to solve the perceived IT pain points at a certain time in history. I'm sure it did "change the world" for the companies that invested the time and resources to do a good implementation. It probably did help legacy systems integrate better. No technology, especially in software, can be expected to live forever. Has a study ever been done asking those companies that bought into CORBA whether or not the ROI was worth it?
    So far I see lots of traction in the field, but also a lot of skepticism.
    Maybe it comes from fuzzy posts that compare SOA to a technology? I don't mean to totally rag on your posting. The 2nd half starts to have some meat on it but only as bullet points. It would be great to have some SOA discussion and how it relates to J2EE development on this board. I think the issue is that we need to have smaller bite-sized postings. For example you bring up virtualization. How does that relate specifically to an SOA? Virtualization as a way to reduce complexity is a separate topic that I'd be interested in. Or "Create and Maintain Capability Matrix". OK, what is a capability matrix? Has it solved issues for you on the job already or are you talking theoretical? Is a Capability Matrix one of the cornerstones of migrating to an SOA? Or the KISS approach? How does that relate to SOA? Is there anything about SOA that makes things simpler? I guess my main complaint is that I'm not seeing the "point" of the posting. If you are truly equating SOA and CORBA as your posting title implies then I'm not sure you are on the right track.
  63. You make some good points. I do agree that ESB should be compared to CORBA rather then SOA. SOA is more of a blue print, concept or even a pattern of how to integrate apps together. You are right SOA is an architecture and in fact CORBA can be used to build a SOA enrvironment (although may not be enough). Check out my blog at http://thought-space-albertm.blogspot.com/ where I talk about ESB. For obvious reasons I can not go into every detail and explain virtualization, KISS as it relates to SOA. There is just not enough space. I did not want it to be a long post. I wanted to evoke a discussion arount it -- and it seems like it sure did. The skepticism I see is aroun ROI that is attached to migrating to SOA type environment. Some more concervative companies are still trying to assess benefits of going to SOA. It also seems that the benefits are not there if appropriate SOA goveranance process is not put in place. Thank you all for your comments (especially those that took my post apart :))). I very much welcome constructive criticism. This is good stuff.
  64. I would like to comment on the point of the posting. I was trying to bring out the growth and management of complexity of SOA based environment. CORBA/SOA comparions was just and over simplification -- almost a reduction of the concept designed to evoke a discussion. Not so much comparison of SOA and CORBA not sure why the editor of my post named my article "SOA? CORBA? The Acronym Changed, Situation Remains" since I did not name it like that when I posted. Maybe the title is messing up the point of my post. The point is simple -- how to manage growing complexity, SOA will enable faster integration of applications and business services -- that growth must be managed. I just see that benefits offered by SOA/ESB are being eroded and will continue to do so unless a sound management/governance process is put in place. That is pretty much it. I my carreer I find that management/monitoring was always an after thought in many IT shops. It is something that you do after apps go to production. That has to change if we want to improve quality of service for SOA based (and non SOA) based apps.
  65. br>I my carreer I find that management/monitoring was always an after thought in many IT shops. It is something that you do after apps go to production. That has to change if we want to improve quality of service for SOA based (and non SOA) based apps.
    You're right, though every management/monitoring vendor out there is already years into adjusting for the exact sorts of problems you've mentioned. Governance and management have been the hottest topics in SOA circles for the past 18 months. There's some fairly mature products out there, but the truth is it's never going to be as simple as installing some software.
  66. Comparing CORBA to SOA is like comparing and engine block from a model T to the general concept of a car. CORBA is a technology, SOA is not. It's more of a strategy and a pretty poorly defined one. Unfortunately so because there are some pretty good approaches buried under that buzzwords. And don't get me started on 'SOA vendors'. We've got one trying to sell us a completely proprietary (and pretty amateurish) point-to-point architecture as an SOA solution. And BTW, you can implement SOA using CORBA. And yes, SOA was influenced by the things that came before it, including CORBA. I know this is absolutely incredible, but time moves forward and we remember (or try anyway) what has come before.
  67. Re: What happened to the editor?[ Go to top ]

    Comparing CORBA to SOA is like comparing and engine block from a model T to the general concept of a car...
    We have a name for that concept already. It's called client-server design. That's why I can't take yet another hyped up buzzword like SOA seriously. Can somebody tell me what is so unique about this "concept" called SOA?
  68. SOA is just riding the next wave of marketing hypes. After this wave has passed by there will be useful technologies (like WCF) to get easier systems integration but basically the problems will stay the same. The SOA technologies really address another problem space than CORBA. SOA is mainly for integrating existing systems in a decoupled way. Here it makes sense to have asynchronous messaging using SOAP documents. In CORBA (or RMI or .NET Remoting or ICE btw) it's all about Object Request Brokering. That means tight coupling to well defined interfaces, a broker infrastructure, multi-language mappings etc. You want that kind of coupling for nearly the same reasons as you use Java-Interfaces: compile-time checking, implementation-hiding, richly typed interface, easy client-programming etc. It all boils down to the same old story: define good interfaces between components and architecture them well. That's all. I don't believe in hypes anymore.
  69. SOA is just riding the next wave of marketing hypes. After this wave has passed by there will be useful technologies (like WCF) to get easier systems integration but basically the problems will stay the same.

    The SOA technologies really address another problem space than CORBA. SOA is mainly for integrating existing systems in a decoupled way. Here it makes sense to have asynchronous messaging using SOAP documents.

    In CORBA (or RMI or .NET Remoting or ICE btw) it's all about Object Request Brokering. That means tight coupling to well defined interfaces, a broker infrastructure, multi-language mappings etc. You want that kind of coupling for nearly the same reasons as you use Java-Interfaces: compile-time checking, implementation-hiding, richly typed interface, easy client-programming etc.

    It all boils down to the same old story: define good interfaces between components and architecture them well. That's all. I don't believe in hypes anymore.
    Yes you should not believe in your imaginary ideas about what SOA is. BTW: 'hypes' is not a noun.
  70. Wow, cool answer with tough arguments ! And thanks for the spelling correction, we here in Germany use "Hype" as a noun all the time.
  71. And thanks for the spelling correction, we here in Germany use "Hype" as a noun all the time.
    It can be a noun here too, it's that "hype" is like the word "deer." It's its own plural.
  72. In CORBA (or RMI or .NET Remoting or ICE btw) it's all about Object Request Brokering. That means tight coupling to well defined interfaces, a broker infrastructure, multi-language mappings etc. You want that kind of coupling for nearly the same reasons as you use Java-Interfaces: compile-time checking, implementation-hiding, richly typed interface, easy client-programming etc.

    It all boils down to the same old story: define good interfaces between components and architecture them well. That's all. I don't believe in hypes anymore.
    CORBA is language independent. You can put a CORBA interface on any legacy systems to talk to other systems. The only difference is the asynchronous part. SOAP based web services are not really asynchronous because they are method calls. That means you cannot something else in the same thread while waiting for the call to complete, which is exactly what asynchronous mean.
  73. The only difference is the asynchronous part. SOAP based web services are not really asynchronous because they are method calls. That means you cannot something else in the same thread while waiting for the call to complete, which is exactly what asynchronous mean.
    Jordan, The asynchronous argument: You're probably referring to the earlier model of SOAP-based Web Services, which relied on RPC, a synchronous mechanism. That model has since been discredited. Today's SOAP-based Web Services rely on messaging, and support many "Message Exchange Patterns", such as: 1. Synchronous Request/Response (like the old RPC you're talking about) 2. Asynchronous Request/Response (send a message on one queue and unblock, wait for and receive the response on another queue) 3. Send-and-forget or Request-only (send a one-way message and don't bother waiting for a response) 4. Publish/Subscribe So be aware that "this is not your father's SOAP" :-). Regards, Ganesh Prasad
  74. The only difference is the asynchronous part. SOAP based web services are not really asynchronous because they are method calls. That means you cannot something else in the same thread while waiting for the call to complete, which is exactly what asynchronous mean.


    Jordan,

    The asynchronous argument: You're probably referring to the earlier model of SOAP-based Web Services, which relied on RPC, a synchronous mechanism. That model has since been discredited. Today's SOAP-based Web Services rely on messaging, and support many "Message Exchange Patterns", such as:

    1. Synchronous Request/Response (like the old RPC you're talking about)
    2. Asynchronous Request/Response (send a message on one queue and unblock, wait for and receive the response on another queue)
    3. Send-and-forget or Request-only (send a one-way message and don't bother waiting for a response)
    4. Publish/Subscribe

    So be aware that "this is not your father's SOAP" :-).

    Regards,
    Ganesh Prasad
    How do you think a message could be sent on a queue ? Maybe with a RPC synchronous call ? Maybe the whole discussion highly depend on the observation point. Guido
  75. =)[ Go to top ]

    http://www.soafacts.com/
  76. The concept of SOA has taken over precisely because of its lack of definition. Any manager (or vendor) can safely claim to have successfully implemented a SOA architecture without fear of being proven wrong. The definition is so ambiguous they can easily backup their claim. They can continue to be sucessful year after year by expanding and improving the SOA architecture throughout the enterprise. SOA is a CIO's dream. This simple fact makes SOA a better lasting technology concept than CORBA.
  77. +1
  78. Good point.
  79. I agree with your view, however at the end of the day it comes down to hard dollars and metrics, such as revenue, customer satistfaction, customer loyalty, market share. Would companies make investements simply to claim "SOA"? While they can, it would be short lived. The purpose of technology is to serve business and improve it as much as possible -- reduce cost, improve productivity, increase profits, revenue. If moving to SOA does not yield any of those then SOA will go down in history as one of the failed experimenets, or a paradigm that has not delivered on its promise. Well maybe the promise is too great -- very well maybe. I think SOA makes businesses more agile and therefore more competitive and therefore on and on an on.
  80. If moving to SOA does not yield any of those then SOA will go down in history as one of the failed experimenets,
    This again demonstrates a gross misunderstanding of what SOA is. It's not an experiment. It's a formalization of proven design techniques.
  81. I agree with your view, however at the end of the day it comes down to hard dollars and metrics, such as revenue, customer satistfaction, customer loyalty, market share. Would companies make investements simply to claim "SOA"? While they can, it would be short lived. The purpose of technology is to serve business and improve it as much as possible -- reduce cost, improve productivity, increase profits, revenue. If moving to SOA does not yield any of those then SOA will go down in history as one of the failed experimenets, or a paradigm that has not delivered on its promise. Well maybe the promise is too great -- very well maybe. I think SOA makes businesses more agile and therefore more competitive and therefore on and on an on.
    Without doubt some folks are going to screw it up royally. Yet a lot of folks will get it right, many already have. If those companies starting seizing market opportunities that their competitors can't (thanks to the agility you mentioned) then that will keep the train rolling. From an internal IT perspective that probably means the folks who do get it right stand to be exceedingly well paid.
  82. Corba - oh my god[ Go to top ]

    One of the most severe misunderstandings about SOA is that it is a Technology like Corba. It is not! SOA is (or rather should be) both an architecture paradigm and IT governance paradigm that aims for creating applications in a robust, composable, coarse grained manner. It is not about synchronous or asynchronous interaction paradigms and it is most definitely not about technology, even though there are a lot of vendors who want to make you believe just that. SOA can be realized with Message Oriented Middleware, EJBs, Corba and what have you. However most realizations I know of fail with one or the other critical requirement I would pose on a SOA architecture. In particular almost no product allows side by side deployment and usage of various version of a service, sad as it is.
  83. Re: Corba - oh my god[ Go to top ]

    One of the most severe misunderstandings about SOA is that it is a Technology like Corba. It is not! SOA is (or rather should be) both an architecture paradigm and IT governance paradigm that aims for creating applications in a robust, composable, coarse grained manner.

    It is not about synchronous or asynchronous interaction paradigms and it is most definitely not about technology, even though there are a lot of vendors who want to make you believe just that.

    SOA can be realized with Message Oriented Middleware, EJBs, Corba and what have you. However most realizations I know of fail with one or the other critical requirement I would pose on a SOA architecture. In particular almost no product allows side by side deployment and usage of various version of a service, sad as it is.
    SOA is one thing, hype... (SOA will fix many things, even your wife... as long as someone pays money) The main thing I miss in the entire SOA hype is substance! We need patterns, we need design principles a good toolset etc... SOA architectures already were done way before SOA as a marketing vehicle ever existed, many projects burned down in flames due to their granularity problems inherent on such projects. Then the entire thing was rebranded as webservices, same problems, but people were wiser not to apply it to everything in existence, just were it made sense, three years later, rebranding, SOA... now it fixes everything, even dead people... All I can see is hype, nothing behind, and a lot of old stuff mashed together which before SOA was everywhere already was mashed together, just as Design patterns for server side applications... Sorry to be harsh here, but from all the buzzword bullshit bingos the last 10 years SOA is the worst, Web 2.0 probably the second worst ;-)
  84. Re: Corba - oh my god[ Go to top ]

    Sorry to be harsh here, but from all the buzzword bullshit bingos the last 10 years SOA is the worst, Web 2.0 probably the second worst ;-)
    C'mon. Web 2.0 is worse, given that it is applied to *everything* regardless. Even to SOA :-). I still think that SOA as I understand it and as it is layed down in our book is a valid principle, but I lot of the stuff that is branded SOA does not even get the basics rights, being (for example) glorified and decorated MOA and BPO products.
  85. Re: Corba - oh my god[ Go to top ]

    But isn't the main goal of SOA being to provide a composable service architecture : services are meant to be composed or recomposed easily in business process. A lonely service isn't really useful. One can do this kind of composable architecture only if services are loosely coupled. And one facet of loose coupling is communication/conversation : asynchronous is loose coupling, synchronous is tight coupling. So asynchronicity is important to SOA. Another really important facet is document based communication. It's the only way to provide effective service mediation.
  86. Re: Corba - oh my god[ Go to top ]

    But isn't the main goal of SOA being to provide a composable service architecture : services are meant to be composed or recomposed easily in business process. A lonely service isn't really useful.
    One can do this kind of composable architecture only if services are loosely coupled.
    Yes. Agreed.
    And one facet of loose coupling is communication/conversation : asynchronous is loose coupling, synchronous is tight coupling. So asynchronicity is important to SOA.
    I'm not convinced that being asynchronous is equivalent to loose-coupling or that being asynchronous implies loose-coupling or vice-versa. Almost any communication across the internet needs to be synchronous. Because it is unreliable, you need a response to ensure delivery. But this is at a communication level. It doesn't mean that the transaction is synchronous. I would say that asynchronous transactions should definitely be preferred in an SOA design because they are much easier to manage and scale much better but I think it's incorrect to say that all services must be asynchronous. That would be too restrictive.
  87. Re: Corba - oh my god[ Go to top ]

    In response to james, there are 2 categories of coupling : (data) type coupling and temporal coupling. Type coupling is the most obvious : the type of exchanged data induce coupling between client and service. Using literal xml document preserve the structural semantic and allow for flexibility/variability without adverse effects (in fact infoset would be enough to convey data). Temporal coupling is more subtle. To support message exchange pattern other than traditional request/reply service must support asynchronicity. It doesn't imply that the message exchange pattern must always be asynchronous. To reduce temporal coupling between client and service allow for a more robust system : partial and transient failures don't block the whole system.
  88. Re: Corba - oh my god[ Go to top ]

    Jose. I would thing there are more that only 2 types of coupling. Actually, coupling is a generic thing that feeds from several variables. The "synchronicity" you mention as temporal is one that is not as trivial to spot. Data typing is another. RPC "exchange" pattern (I hate to call that), is another one, since it forces a semantic in the message body, even a pre-stated structure of operation and parameters with a return value. The transport may be another one, and there is where HTTP nature, for instance, is confused with "synchonicity". How come? HTTP is not a messaging transport. It is a Hyper Text transport, based on the REST idea of distributed resources and local states (although REST came later). No messaging anywhere. Thus, since HTTP operations require a response, and that means they need to be a blocking pattern, doesn't mean that the messaging that piggybacks on it should also be. As Hohpe mentioned in a conference, there is no message that goes and comes back. There are actually two messages. The fact that HTTP is as good to send a message in a request and bring the other message in the response, shouldn't tie the blocking or synchronous pattern to messaging as well. IN other words, you can have the request response without needing a synchronous call. Lastly, and that is something I always say to my students when talking about products, I see no client-server relation in SOA messaging. I see an origin of the message and a destiny. That final target contains a service that consumes the message. A service is not method exposed. It is a cloud of coherent functionality that is activated by messages, and that may send a message back to you. I love that vision. William Martinez Pomares.
  89. SOA will save your life[ Go to top ]

    I have an amazing SOA framework that will solve all of your existing problems. Now, it may be expensive and it may take some time to get right but SOA is the future of composable Enterprise services! Imagine a world where everything is loosely coupled, businesses can easily communicate with each other without a faximile machine, where transactions, security, reliability can be layered on top of any service you desire. Imagine a world of drag and drop WYSIWYG orchestration tools to unite your services so that programmers are practically a thing of the past. SOA isn't HTTP! SOA isn't Web Services! SOA is a state of mind! SOA is what you've been wanting all your life but haven't known how to ask for! SOA is anything we want it to be! Only we're getting it right. Only our software is truly SOA. It may look a lot like our old software with SOA added in liberally but it's not our old software, it's the new wave of the future. Oh, by the way, if you like SOA, you'll love our new Web 2.0+!
  90. A very good article in ACM Queue by Michi Henning on The Rise and Fall of Corba.
  91. Now I understand why management are outsourcing so many jobs to foreign countries. So many IT folks in the US are chasing after the buzzwords. Something as elusive as SOA, a set of design principles, design patterns or best practices, whatever you call it, becomes the next wave of software advances that everyone wants to get a piece of. Businesses looking for the bottom line(justifiably) are tired of the empty promises of the buzzwords. If they get nothing done from developers, at least get it cheaper overseas.
  92. Granted I haven't read all 90 messages in this thread, but I read enough to see this: SOA is not this SOA is not that You don't understand what SOA is. ....yeah, I guess I don't. Okay, as far as I can tell, and I got excorciated for this before by some SOA acronym freak with another post about how I don't TRULY understand the GRAND VISION of SOA. SOA is distributed procedural programming. Services are stateless request-response calls on arbitrary destinations. Anyone remember back in the 90s when every. single. project. design was a huge hierarchical object tree? Every product and technology had its own object tree pasted on other object trees? SOA seems to be going after a high-level design of simple procedural calls and data retrieval/updates/deletes/inserts, with a "unified" calling interface, if one can call the current state of service/webservice acronyms unified or simple. "CORBA is a technology, SOA is an architecture" REALLY? Common Object Request Broker ARCHITECTURE isn't an architecture? What makes Service Oriented Architecture an architecture, considering NO ONE will step up and describe it? Whoever said that, I'm sorry, that was just stupid. Admit it. SOA is an attempt at simplicity that has failed: - technologically - too many different standards - no agreement as to what the hell it is - overly complicated (failing its primary mission: simplicity)
  93. Hi Carl. I agree with several things you say. I disagree with the overall idea. Yes, as the hitting the moles, each time someone tries to define SOA (a mole getting out of the hole) someone crashes a pole in the head of the poor thing just because it didn't understand SOA. There is a difference between what SOA is and what SOA has become due to development incompetence. SOA was confused with distributed procedural (or object oriented too!) programming. Services are stateless, but they were forced to be RPC calls. SOA was forced to sell the idea of a simpler, unified, platform independent interface, which is not (a service IS NOT an interface). SOA was sold out as simplicity when it was just a way to architecture using the service metaphor. SOA has a different vision, not huge, not grande, not even new. CORBA is based on an architectural pattern (also called Style) that is the very well know Broker pattern, that was sold out as an implementation (the same all vendors try to do with SOA). SOA is an architecture style, where you model using services that are named functionalities accessible by messages. Is not panacea, and is not simple. That is why architects (and I mean Enterprise Architects) are the ones that should deal with it, and not Java programmers. Finally, simplicity has nothing to do here. Trying to do SOA without thinking in architecture and with the actual tools, creates stovepipes systems, impedance mismatch, little monsters that make overly complex to call a method using a service metaphor with asynchronous messages. Creates chaos. The question would not be what is SOA and what is not. The question should be Why are all these people trying to make the square SOA vision fit into a round hole? It is hurting a very good abstraction that, by the way, is not good for everyone. Finally, we would never agree on what it is, since every kind of "hammer" looks at it as its very own kind of nail. William Martinez Pomares
  94. REALLY? Common Object Request Broker ARCHITECTURE isn't an architecture? What makes Service Oriented Architecture an architecture, considering NO ONE will step up and describe it? Whoever said that, I'm sorry, that was just stupid. Admit it.
    If having the word 'architecture' in the name makes something an architecture, then SOA is by definition an architecture. QED. Not to be rude but from this thread it seems like a lot of developers have trouble with abstract concepts: if it's not a concrete thing that you can poke at, it doesn't exist. A number of people have explained SOA and one has done so rather eloquently (not me.) Some links have been posted pointing to explanations and one person pointed to an article about how CORBA really sucks big time. Yet, people continue to say that no one will explain. I don't know what to tell you. I guess you'll have to figure out why when you look at it, you see nothing and when others do, they see something. Kind of like those 3D pictures that you have to cross your eyes to see I guess.
  95. Granted I haven't read all 90 messages in this thread, but I read enough to see this:

    SOA is not this
    SOA is not that
    You don't understand what SOA is.

    ....yeah, I guess I don't.
    They want to take IT into the realm of abastract art. Ever feel like being in an art museum, standing in front of huge canvas with a big red square in the middle? Anyway, they can't justify their "Chief Architect" title without an "architecture" to preach for. Since they can't talk about anything concrete and get caught with their empty rhetorics, they hype up something abstract like SOA. No one can say they don't know what they are talking about because nobody knows what it is.
  96. Well, Jordan, at least we architects sometimes do agree about something. This is not about who is right and who isn't. Is not about art (abstraction is the elimination of details to model a reality, not Picasso's paintings). By the way, abstraction eliminates details but keeps structure, which makes what someone says a very concrete solution. I have a hard time trying to make developers crack their shells and see what other people are doing. I'm being unsuccessful to bring a Hibernate user to think abut XML databases, or even Object databases. There are lots of java developers I check their code and see procedural programming, no OO design anywhere. The same is happening with services (forget SOA). Even other people teaching at the university see Services as objects exposing their methods, and there is no way to change that mind. If they cannot understand services unless I talk to them in terms of objects, then they will never understand SOA. At least, my new hope are my students. Some of them are starting to investigate a cross model representation. Actually it is hard, they say, and the tools are not of use, but at least they have the concept pure. By the way, I'm a hard core developer, differenec is I swallowed the right pill. William Martinez Pomares
  97. Well, Jordan, at least we architects sometimes do agree about something.

    This is not about who is right and who isn't. Is not about art (abstraction is the elimination of details to model a reality, not Picasso's paintings).

    By the way, abstraction eliminates details but keeps structure, which makes what someone says a very concrete solution.

    I have a hard time trying to make developers crack their shells and see what other people are doing. I'm being unsuccessful to bring a Hibernate user to think abut XML databases, or even Object databases. There are lots of java developers I check their code and see procedural programming, no OO design anywhere. The same is happening with services (forget SOA). Even other people teaching at the university see Services as objects exposing their methods, and there is no way to change that mind. If they cannot understand services unless I talk to them in terms of objects, then they will never understand SOA.

    At least, my new hope are my students. Some of them are starting to investigate a cross model representation. Actually it is hard, they say, and the tools are not of use, but at least they have the concept pure.

    By the way, I'm a hard core developer, differenec is I swallowed the right pill.

    William Martinez Pomares
    William, I agree that too many Java and C++ code was written in the procedual fashion. OO design is extremely important good software in my opinion. SOA on the other hand suffers the same problem that many of its predecessors already displayed. The concept of breaking software systems into independent, reusable service components has a major flaw. It does not address the changing needs of the business environment. Many of these services, such as "process payment", may be considered permenant, but the devil is always in the details. What are the input and output of these services change all the time. By fixing the interface to the services, we often made them very inflexible. If even the reusability of plain objects are often difficult, how can we be so sure that we can define services that are constant(in all details) and thus reusable? I am not saying that such concept is invalid. But because of this problem, a constant set of services is very hard to define and should be used only when it makes sense. The abuse of the SOA concept is rampant and creates a lot of problems down the road.
  98. Jordan. I see a repeating idea about SOA, services in particular, that doesn't fit in what I have learned from my childhood as an architect. I will explain myself. I recall the old Object oriented days when all the fuzz was about reusability. The idea was clear: separate the code into coherent and functional complete things. Then a problem was found: the interface. You could not reuse the thing because of the interface not being suitable, or requiring things not in the new problem domain. Then a service came. It was the idea of having a business functionality (not an interface, not an object) able to accept messages and offer a business value. It has no reusability concept, the fuzz was actually about replacing fixed interfaces with a simple port. And somebody said: Let's implement it with SOAP. And SOAP was Simple Object Access Protocol, an RPC oriented wrapping protocol used to access distributed objects. Wow. Wait a minute. Something is not working here. I know objects were supposed to accept messages. Nobody uses that. But a service is not an object. A service has no methods or parameters. Definitively, it has no response. There is no interface per se, just a port where you deliver your message. Now, the message is not SOAP. SOAP is a wrapper. The real thing is in the body. Once the service has read from the port the message content, it will now know what to do. And it may decide to send another message. As simple as that. But as difficult to grasp for an object programmer, that it was reduced to a YAMTCARO (Yet another method to call a remote object). NOw, can somebody tell me why a service needs a method name to be called? SOAP had stubs in the client, to simulate the remote object as local. Services are not object, stubs have no place here. Makes no sense. You need a port object to stream your message. Simple. Finally, since a service is just a port, and the service semantics (which are not technically describable) is hidden behind the service cloud. You can create a versioning system underneath the cloud, so old messages can still be accepted and new messages, that represent new business needs, be processed as required. Service cloud still as white as before. It may have a new port, but old ports may be still there. Enterprise architects? Their job is to have one eye in the problem space, and the other in the solution space. They will work with business people to design services scope (business driven), and work with designers to technically create the structure of the cloud. Hope this helps to understand why I say all that I say. William Martinez Pomares.
  99. Jordan.

    I see a repeating idea about SOA, services in particular, that doesn't fit in what I have learned from my childhood as an architect. I will explain myself.

    I recall the old Object oriented days when all the fuzz was about reusability. The idea was clear: separate the code into coherent and functional complete things. Then a problem was found: the interface. You could not reuse the thing because of the interface not being suitable, or requiring things not in the new problem domain.

    Then a service came. It was the idea of having a business functionality (not an interface, not an object) able to accept messages and offer a business value. It has no reusability concept, the fuzz was actually about replacing fixed interfaces with a simple port. And somebody said: Let's implement it with SOAP. And SOAP was Simple Object Access Protocol, an RPC oriented wrapping protocol used to access distributed objects. Wow. Wait a minute. Something is not working here. I know objects were supposed to accept messages. Nobody uses that. But a service is not an object. A service has no methods or parameters. Definitively, it has no response. There is no interface per se, just a port where you deliver your message.

    Now, the message is not SOAP. SOAP is a wrapper. The real thing is in the body.

    Once the service has read from the port the message content, it will now know what to do. And it may decide to send another message. As simple as that. But as difficult to grasp for an object programmer, that it was reduced to a YAMTCARO (Yet another method to call a remote object).

    NOw, can somebody tell me why a service needs a method name to be called? SOAP had stubs in the client, to simulate the remote object as local. Services are not object, stubs have no place here. Makes no sense. You need a port object to stream your message. Simple.

    Finally, since a service is just a port, and the service semantics (which are not technically describable) is hidden behind the service cloud. You can create a versioning system underneath the cloud, so old messages can still be accepted and new messages, that represent new business needs, be processed as required. Service cloud still as white as before. It may have a new port, but old ports may be still there.

    Enterprise architects? Their job is to have one eye in the problem space, and the other in the solution space. They will work with business people to design services scope (business driven), and work with designers to technically create the structure of the cloud.

    Hope this helps to understand why I say all that I say.

    William Martinez Pomares.
    William, your vision or interpretation of services in SOA is very different from the mainstream. The most popular description of services is a set of independent, reusable functional units that can be "reassembled" to form different applications. I am not sure how many architects will agree with you. Anyway, it was my pleasure exchanging ideas with you. I don't have any more to add to this discussion. Thank you.
  100. Now, can somebody tell me why a service needs a method name to be called? SOAP had stubs in the client, to simulate the remote object as local. Services are not object, stubs have no place here. Makes no sense. You need a port object to stream your message. Simple.

    Finally, since a service is just a port, and the service semantics (which are not technically describable) is hidden behind the service cloud. You can create a versioning system underneath the cloud, so old messages can still be accepted and new messages, that represent new business needs, be processed as required.
    Well, if a service is just a port, there must be some semantics for the port to know what to do with the message is receives. While there might be multi purpose messages, they are even harder to maintain than single purpose messages. So, almost all messages to a port will essentially be "single purpose", like "make a booking", "transfer money", "get account statement" etc. Lets call this the "function name" or "message type". Of course the client will usually have some kind of return message, which, for the purpose of this discussion, shall be called the "return value". The inner content of the message shall be called the "argument". What is so different from a method call after all. Essentially nothing. For the sake of simplicity, we might even have some fun, and create an EJB or Corba Object, that we call the Service Port. What you are doing is "de-abstracting" away from perfectly valid abstractions, arguing about the service cloud that might have a silver lining. What you get right though, is that the "service cloud" must have an inherent versioning mechanism, ideally one that is transparent for the caller (which is in fact quite awkward (not hard) to do with current mainstream technology, both from a technical perspective and from a business perspective).
  101. To Jordan: Yes, unfortunately the service view as a business functionality is far away from actual mainstream "understanding", although it is not that far away with what has been done (think about it). It is clear, though, from the WSDL spec and the Web Service Architecture Specs. I don't know if architects would agree with me. Some of the ones I have met do, some others simply don't know much about the theme. And, of course, there is the vast majority of architects that got their title after being the super-developer, and for those everything has the face of an object. Now, Karl. Service is not just a port. A Service is very complex thing that has a simple mission: to provide a business functionality as a service. How do you communicate with it? Using a port. You send a message to a port. That the message body contains an XML structure that is thighly coupled to reassemble a method call, is not of the Service business, it just doesn't care. That is, using that inflexible analogy makes your service miss those important features like being weak coupled, but it is your call. Now, what separates an architect from a designer/developer is that the first one works with the service image I told you, business. The second ones will take that vision, see how can they publish that port, what do they need in the message or in the port itself to determine functionality, create a message processor that will route the requests to business logic and other levels, and then finish the work. The easiest way is the lazy programmer way. They put all the business logic in one class, create a method to publish it, create an XML schema that reassembles the method call, and use the port to get that XML. In other words, they are downsizing the metaphor to an RPC that may be far less expensive if done with EJBs or even CORBA. In other words, it is valid if you want to make your service look like an exposed object. I see no point in it, though. Now on your examples: "make a booking", "transfer money", "get account statement". I see them clear as fine grained method calls. The first thing you hear in the street is to get away from those. They are expensive. Your need to create course grained services. The next example may seem a little extreme. Service: Loan service. Functionality: Actually, the service is able to process loan requests, payments, notifies due loans and you can ask for a loan status. How is it done?: There are four document types, each one has a particular schema: LoanRequest (input), LoanInfoRequest(input/output), LoanNotification (output) and LoanPaymentNote(input). Any input XML document may be sent to a port located in www.willyloans.com/loanport or to the email loanport at willyloans.com. There, an XML processor will determine the schema type, and send the actual data to the loan analysis department, to the loan payments subsystem, or to the loan service desk system. You can guess what each system does, and what each document may contain. You can create four WSDL if you want. All pointing to the same address. Just make them document style. More functionality? Just add it. Another schema and that's it. Versioning? No problem, several XML databases already support that. What do you think? William Martinez Pomares.
  102. To Jordan: Yes, unfortunately the service view as a business functionality is far away from actual mainstream "understanding", although it is not that far away with what has been done (think about it). It is clear, though, from the WSDL spec and the Web Service Architecture Specs.
    I don't know if architects would agree with me. Some of the ones I have met do, some others simply don't know much about the theme. And, of course, there is the vast majority of architects that got their title after being the super-developer, and for those everything has the face of an object.

    Now, Karl.
    Service is not just a port. A Service is very complex thing that has a simple mission: to provide a business functionality as a service.

    How do you communicate with it? Using a port. You send a message to a port. That the message body contains an XML structure that is thighly coupled to reassemble a method call, is not of the Service business, it just doesn't care. That is, using that inflexible analogy makes your service miss those important features like being weak coupled, but it is your call.

    Now, what separates an architect from a designer/developer is that the first one works with the service image I told you, business. The second ones will take that vision, see how can they publish that port, what do they need in the message or in the port itself to determine functionality, create a message processor that will route the requests to business logic and other levels, and then finish the work. The easiest way is the lazy programmer way. They put all the business logic in one class, create a method to publish it, create an XML schema that reassembles the method call, and use the port to get that XML. In other words, they are downsizing the metaphor to an RPC that may be far less expensive if done with EJBs or even CORBA.

    In other words, it is valid if you want to make your service look like an exposed object. I see no point in it, though.

    Now on your examples: "make a booking", "transfer money", "get account statement". I see them clear as fine grained method calls. The first thing you hear in the street is to get away from those. They are expensive. Your need to create course grained services. The next example may seem a little extreme.

    Service: Loan service.
    Functionality: Actually, the service is able to process loan requests, payments, notifies due loans and you can ask for a loan status.
    How is it done?: There are four document types, each one has a particular schema: LoanRequest (input), LoanInfoRequest(input/output), LoanNotification (output) and LoanPaymentNote(input). Any input XML document may be sent to a port located in www.willyloans.com/loanport or to the email loanport at willyloans.com. There, an XML processor will determine the schema type, and send the actual data to the loan analysis department, to the loan payments subsystem, or to the loan service desk system. You can guess what each system does, and what each document may contain.
    You can create four WSDL if you want. All pointing to the same address. Just make them document style.
    More functionality? Just add it. Another schema and that's it. Versioning? No problem, several XML databases already support that.

    What do you think?

    William Martinez Pomares.
    What about tooling support from the major vendors?


  103. What about tooling support from the major vendors?
    Well, John, this may be my last post. I did a research on vendors several months ago, part of a work with Frank Cohen. Frank did find that RPC style web services were not scalable. Document style performed better. To create services like the ones I mention (that are actually the ones intented to be created in the first place), you need to use a document style call. That is, you send a document, an XML document, as the body of the message. The provider agent (the one that implements the service) receives the document and works with it, performing several tasks. The main problem with that, is the fact that you don't use RPC. That is, the body of the message is not required to contain the method name. There a no parameters or such. Just an XML document. So, I started to investigate vendors. I found that, to send an XML document, there was no natural way. You have to tweak and find workarounds. Microsoft invented the "wrapping" style, that is creating a document style with an XML schema that simulates the XML just as it is sent in RPC style. In that way, you may claim using document style but you are using RPC instead. The plain document style (not the wrapped) was called "bare". I tried to create some web "bare" services in tools like Websphere, Oracle and even JBoss. I found out that some would ask for the method name! and some other would fail using clients generated by the same tools. Sun as an article explaining how to create document style services using JAX-RPC here. As you can see, it is plenty of ways (tricks to pass a document in an RPC wrap), but none natural. Axis examples. If you check the one that shows how to send a file as an attachments, you will see the RPC way and the Document way. RPC has a couple of lines, but the other is a complex routine to handle XML with more that one page long. So, yes, the vendors are offering things that make you prefer RPC, and thus making the life so much more complex, breaking the metaphor. I want to see what service vistualization servers may offer. Any other idea I have, I'll post it in my very new blog. Thanks William Martinez Pomares
  104. I did a research on vendors several months ago, part of a work with Frank Cohen. Frank did find that RPC style web services were not scalable. Document style performed better. To create services like the ones I mention (that are actually the ones intented to be created in the first place), you need to use a document style call. That is, you send a document, an XML document, as the body of the message. The provider agent (the one that implements the service) receives the document and works with it, performing several tasks. The main problem with that, is the fact that you don't use RPC. That is, the body of the message is not required to contain the method name. There a no parameters or such. Just an XML document.
    Oh, OK, but what is the big difference between this and a web service operation which accepts the XML as a parameter in-a-string? Scalability? In what sense?
  105. I did a research on vendors several months ago, part of a work with Frank Cohen. Frank did find that RPC style web services were not scalable. Document style performed better. To create services like the ones I mention (that are actually the ones intented to be created in the first place), you need to use a document style call. That is, you send a document, an XML document, as the body of the message. The provider agent (the one that implements the service) receives the document and works with it, performing several tasks. The main problem with that, is the fact that you don't use RPC. That is, the body of the message is not required to contain the method name. There a no parameters or such. Just an XML document.


    Oh, OK, but what is the big difference between this and a web service operation which accepts the XML as a parameter in-a-string?

    Scalability? In what sense?
    Oh, why do you ask this silly question ? SOA scales by definition !!! Because services are stateless, because services are simple invoker of a provider agent. Well, it would be really hard to make services not scalable. But what about the provider agent ? OK, it is the agent not the service. The big picture is completed, the remaining part are implementation details that do not affect the wonderful fresco Guido
  106. I did a research on vendors several months ago, part of a work with Frank Cohen. Frank did find that RPC style web services were not scalable. Document style performed better. To create services like the ones I mention (that are actually the ones intented to be created in the first place), you need to use a document style call. That is, you send a document, an XML document, as the body of the message. The provider agent (the one that implements the service) receives the document and works with it, performing several tasks. The main problem with that, is the fact that you don't use RPC. That is, the body of the message is not required to contain the method name. There a no parameters or such. Just an XML document.


    Oh, OK, but what is the big difference between this and a web service operation which accepts the XML as a parameter in-a-string?

    Scalability? In what sense?

    Oh, why do you ask this silly question ?
    SOA scales by definition !!!
    Because services are stateless, because services are simple invoker of a provider agent.
    Well, it would be really hard to make services not scalable.
    But what about the provider agent ?
    OK, it is the agent not the service.
    The big picture is completed, the remaining part are implementation details that do not affect the wonderful fresco

    Guido
    I dont know, but to me the biggest challenges with SOA arent technological, but rather organisational. As long as the line organisation orders applications, they will get applications. If we want to build services, we must convince them to order services.
  107. I dont know, but to me the biggest challenges with SOA arent technological, but rather organisational.

    As long as the line organisation orders applications, they will get applications. If we want to build services, we must convince them to order services.
    You couldn't be more correct. This is why talking about SOA as a technology makes no sense. The most crucial part of implementing SOA is working with 'the business' to identify the services that are needed. You can pretty much literally implement SOA with any technology. I've worked with COBOL-based services hosted on a mainframe. Lower level implementation concerns are often called services but I think this confuses matters and I wish we could call these something else. I think once someone called these components but I'm not sure that will fly. In any event. SOA is more about what you do than how you do it.
  108. I totally agree with that. William Martinez Pomares
  109. Ok, let see about this ones: 1. A WS with a string parameter may fit for a very tight concept of service. You send a document, and a document does not contain just a single data, but a structured or semi-structure sets of information. You can compress that into a string field, no discussion, but that I wouldn't do. 2. Then, a document is not just a couple of parameters. eXML standards and industry are creating XML documents that are in the order of several megs. Pack that into a string. Parse from XML to String, then encode it to add it to XML SOAP, then decode it, and un-parse it. Make 100 concurrent users try to send the same document to the service. You will receive less that 1 tps. That is a scalability problem. And since RPC is a blocking mechanism by nature, the problem is reflected in the clients too! I have several stories about clients timed out. 3. Still not sure Services are stateless. I know communication between them is. A service is not only a process, it is functionality and may have a state, although they are implemented using a stateless object (EJB). 4. Guido is totally right, Services scale by concept, implementations draw away the scalability. William Martinez Pomares
  110. Make 100 concurrent users try to send the same document to the service. You will receive less that 1 tps. That is a scalability problem.
    No, that is a performance problem. But I dont see how this has any impact from an architectural perspective, or how it differs from sending the same document using raw xml over http.
  111. John. 1. Probably the example was extreme and confusing. Performance problem is when your "expected normal" load is returning a low TPS. Scalability is when you want to increase the load, using more users or bigger documents for instance, and the expected growth lowers dramatically the TPS. So you are right, the example was missing the increase factor. I assumed 1 user and then grow to 100. 2. It depends on what is "architecturally significant". From an architect point of view, I may want to use a service oriented interoperation between two of my partner companies. If I know both companies work with EDI formatted documents, and I see that my architecture design will work only if those are kept in place, I may decide to dig to that level and indicate the use of EDI payload instead of XML. To me, that is "significant" to deep my hand on. As such, I may also indicate to designers that we must use message queues instead of XML-RPC, for instance, since we are dealing with As/400 machines and legacy code. 3. About the scalability, that is a quality property that architects usually look at. I know that the service I'm asking to create is a very sensitive one. And although I have just a few clients now that will use it, I foresee in a month I will have 5 times the clients, so I need it to scale. That is "architecturally significant" too. 4. Finally, I may want to handle the spec, or simply tell to the designer: I need it to scale to 100 users and 10 meg messages. I wrote an article about the need of messages with a full, huge payload, and why can't we separate them (the idea is don't do it!). Use raw xml over html then, but not to "call" the service, but to send data to it. William Martinez Pomares
  112. Sorry, I reread the paragraph and I'm telling a nonsense. The idea is actually to separate the bulk data from the message, what you don't have to do is create messages with bulk data. message are not good carriers of huge payloads. William.
  113. John.

    1. Probably the example was extreme and confusing. Performance problem is when your "expected normal" load is returning a low TPS. Scalability is when you want to increase the load, using more users or bigger documents for instance, and the expected growth lowers dramatically the TPS. So you are right, the example was missing the increase factor. I assumed 1 user and then grow to 100.

    2. It depends on what is "architecturally significant". From an architect point of view, I may want to use a service oriented interoperation between two of my partner companies. If I know both companies work with EDI formatted documents, and I see that my architecture design will work only if those are kept in place, I may decide to dig to that level and indicate the use of EDI payload instead of XML. To me, that is "significant" to deep my hand on. As such, I may also indicate to designers that we must use message queues instead of XML-RPC, for instance, since we are dealing with As/400 machines and legacy code.

    3. About the scalability, that is a quality property that architects usually look at. I know that the service I'm
    asking to create is a very sensitive one. And although I have just a few clients now that will use it, I foresee in a month I will have 5 times the clients, so I need it to scale. That is "architecturally significant" too.

    4. Finally, I may want to handle the spec, or simply tell to the designer: I need it to scale to 100 users and 10 meg messages. I wrote an article about the need of messages with a full, huge payload, and why can't we separate them (the idea is don't do it!). Use raw xml over html then, but not to "call" the service, but to send data to it.

    William Martinez Pomares
    Well, I think that you will find that raw xml over http suffers from the same scalability problems as a web service. Performance wise it might have a slight edge, but from a scalability perspective I cant see any reason for why they would differ. But I am not quite sure how this fits into a discussion on SOA (from the perspective of an enterprise architect).
  114. You are totally right in both appreciations. If you send the same bulk data to the service, either SOAP or plain XML, you may find the same scalability issue. And that is an implementation problem, nothing to do with services design. William.
  115. Use raw xml over html then, but not to "call" the service, but to send data to it.

    William Martinez Pomares
    William Martinez Pomares, Teacher in University, Article Writer,etc. You seem to be very detached from reality and very fond of discussing non-substantial or even non-existent semantical differences.
  116. Are there any metrics that can be used to measure the quality of SOA implementation vs another SOA or non-SOA implementation? If we take 3 comparable applications and implement all 3 using different architecture styles and one of them is SOA -- how do you measure the effectiveness of each one? I am assuming there has to be some hard metrics that can be used to evaluate their effectiveness. It would be interesting to know what those might be. Some people claim that one architectural approach is better then other -- then their must be a set of metrics that is used to determine better vs worse.
  117. Here I'm, still writing posts... That is a very broad question. I would ask what do you want to measure? What do you want to compare? Performance, Time-to-market, scalability, expandability, security, evolution, ...? You can measure the complete product, or measure the effort to construct it. Measure the use, the cost of maintenance. Finally, an architecture style or pattern is not the final implementation. You see, you can do SOA using SOAP or plain XML over http, and use the same in a non SOA way, thus making no final difference in implementation. Thought question, for sure. William
  118. Use raw xml over html then, but not to "call" the service, but to send data to it.

    William Martinez Pomares

    William Martinez Pomares, Teacher in University, Article Writer,etc.

    You seem to be very detached from reality and very fond of discussing non-substantial or even non-existent semantical differences.
    Sure I do! It is fun! Only that I'm not detached from reality. My first job is to work on a company that deals everyday with fashion bandwagon jumpers that want to see what things that are not right implemented. Further more, I discuss with developers all day (I'm a developer too!), in this and other places, and that gives me a lot of material to understand a lot of things, and to know how people understand them. You should try it too. You will find lots of material. Have you read all those discussions from Ted Neward? IT is far much more that just interfaces and goto cycles. BTW, I'm no an article writer. Nobody publishes me. I wrote an article once. I danced a waltz in my wedding and I'm sure I'm not a dancer. About teaching, I began 13 years ago, and I'm still learning. William.
  119. To Jordan: Yes, unfortunately the service view as a business functionality is far away from actual mainstream "understanding", although it is not that far away with what has been done (think about it). It is clear, though, from the WSDL spec and the Web Service Architecture Specs.
    I don't know if architects would agree with me. Some of the ones I have met do, some others simply don't know much about the theme. And, of course, there is the vast majority of architects that got their title after being the super-developer, and for those everything has the face of an object.

    Now, Karl.
    Service is not just a port. A Service is very complex thing that has a simple mission: to provide a business functionality as a service.

    How do you communicate with it? Using a port. You send a message to a port. That the message body contains an XML structure that is thighly coupled to reassemble a method call, is not of the Service business, it just doesn't care. That is, using that inflexible analogy makes your service miss those important features like being weak coupled, but it is your call.

    Now, what separates an architect from a designer/developer is that the first one works with the service image I told you, business. The second ones will take that vision, see how can they publish that port, what do they need in the message or in the port itself to determine functionality, create a message processor that will route the requests to business logic and other levels, and then finish the work. The easiest way is the lazy programmer way. They put all the business logic in one class, create a method to publish it, create an XML schema that reassembles the method call, and use the port to get that XML. In other words, they are downsizing the metaphor to an RPC that may be far less expensive if done with EJBs or even CORBA.

    In other words, it is valid if you want to make your service look like an exposed object. I see no point in it, though.

    Now on your examples: "make a booking", "transfer money", "get account statement". I see them clear as fine grained method calls. The first thing you hear in the street is to get away from those. They are expensive. Your need to create course grained services. The next example may seem a little extreme.

    Service: Loan service.
    Functionality: Actually, the service is able to process loan requests, payments, notifies due loans and you can ask for a loan status.
    How is it done?: There are four document types, each one has a particular schema: LoanRequest (input), LoanInfoRequest(input/output), LoanNotification (output) and LoanPaymentNote(input). Any input XML document may be sent to a port located in www.willyloans.com/loanport or to the email loanport at willyloans.com. There, an XML processor will determine the schema type, and send the actual data to the loan analysis department, to the loan payments subsystem, or to the loan service desk system. You can guess what each system does, and what each document may contain.
    You can create four WSDL if you want. All pointing to the same address. Just make them document style.
    More functionality? Just add it. Another schema and that's it. Versioning? No problem, several XML databases already support that.

    What do you think?

    William Martinez Pomares.
    William, Are you talking REST? Paul.
  120. Well, Paul, I'll answer that one. REST is another word several people use, but may not be clear of what it refers too. Chapter 5 of Fielding's dissertation explains REST. It is an architectural style used to create distributed hypermedia systems. Doesn't sound like services, right? Because it was not created for them. REST is based on a state. Imagine resources in the net. The resource as a state that may be changed by simply performing a reduced set of operations (post, get, put and delete). The resource is accessible using its ID (URI). And you work with a representation of the resource. For most people, REST-like web services is simply calling "services" using arbitrary XML documents and http. It's not that easy. There are lots of confusing ideas there. For instance, there are people saying services are stateless. But resources is REST are not. The communication should be stateless. Confusing, right? Web Services Architecture spec has a view of the architecture where the services are seen as resources. So, we may even say that Web Services using SOAP are actually REST-Like!. REST has not idea of messages. And it is for hypermedia. That means that web services using message queues or some other transports have no meaning in REST-world. Services as resources. Services do not have a representation, they have a port that is actually the web resource used. When you request a page in the Web, the representation of that page (the HTML code) is self-sufficient. The browser will paint it without trouble. But with an XML document, you as a developer must know what those tags mean to actually do something, it is not self-describing as REST request. For this, and for several other dicrepancies, I thing that REST style web services shouldn't have that name, since they are a missreading of the REST idea. Confusing, right? Well, Paul, I think the short answer is that the above ideas of services, (extracted from the spec, not the vendors) are actually implementable using document style web services, (SOAP and WSDL), and also using what has been call REST-like services. We can even implement them using message queues, SMTP, or plain TCP/IP sockets. Funny, huh?. This may go to my blog someday William Martinez Pomares
  121. Hi William, First of all I must commend you on your attempt to grasp back the term "SOA" from the marketers and the vendors. Having said this, such a generic term is virtually meaningless IMO and best avoided if comprehension and effective communication (not a marketing sound-bite) is your stated goal. Like you say:
    Well, Paul, I think the short answer is that the above ideas of services, (extracted from the spec, not the vendors) are actually implementable using document style web services, (SOAP and WSDL), and also using what has been call REST-like services. We can even implement them using message queues, SMTP, or plain TCP/IP sockets.
    Which implies that the term "SOA" has very little information content (in a Shannon sense :^)). Back to the real world and building real systems. I'm not sure I fully agree with your take on REST:
    REST has not idea of messages. And it is for hypermedia. That means that web services using message queues or some other transports have no meaning in REST-world.
    Thanks for referencing Fieldings dissertation, which I have also read. It took me a good while to "get-it" with REST, mostly due to pre-conceived ideas which I held that didn’t hold with its’ basic premise. I eventually got there though, mostly thanks to Mark Baker, and to limit RESTs applicability to "hypermedia" is a misunderstanding IMO. REST talks about "self describing data", that is all.
    For most people, REST-like web services is simply calling "services" using arbitrary XML documents and http. It's not that easy. There are lots of confusing ideas there. For instance, there are people saying services are stateless. But resources is REST are not. The communication should be stateless. Confusing, right?
    I agree that many do find REST confusing, but I don’t believe the underlying idea is confusing in itself. It is one of those ideas where less is more IMO. I find that people (including myself) struggle to come to terms with the less. The central concept behind REST is the idea of a uniform connector, which seems to fit your "document style" "distributed architecture" idea pretty well (I am avoiding the use of the term "web services” since I believe it as been polluted in much the same way as SOA). As for SOAP, there is very little uniformity there. Hence I agree you could implement REST with SOAP, but to do so would miss the point. Anyway, thanks for a rare ray of intellectualism on TSS. I have followed this discussion and felt no need to participate up until now. I will continue the discussion on your blog if you don't mind. It is nice to meet someone with something thoughtful to say. Paul.
  122. To Jordan: Yes, unfortunately the service view as a business functionality is far away from actual mainstream "understanding", although it is not that far away with what has been done (think about it). It is clear, though, from the WSDL spec and the Web Service Architecture Specs.
    I don't know if architects would agree with me. Some of the ones I have met do, some others simply don't know much about the theme. And, of course, there is the vast majority of architects that got their title after being the super-developer, and for those everything has the face of an object.

    Now, Karl.
    Service is not just a port. A Service is very complex thing that has a simple mission: to provide a business functionality as a service.

    How do you communicate with it? Using a port. You send a message to a port. That the message body contains an XML structure that is thighly coupled to reassemble a method call, is not of the Service business, it just doesn't care. That is, using that inflexible analogy makes your service miss those important features like being weak coupled, but it is your call.

    Now, what separates an architect from a designer/developer is that the first one works with the service image I told you, business. The second ones will take that vision, see how can they publish that port, what do they need in the message or in the port itself to determine functionality, create a message processor that will route the requests to business logic and other levels, and then finish the work. The easiest way is the lazy programmer way. They put all the business logic in one class, create a method to publish it, create an XML schema that reassembles the method call, and use the port to get that XML. In other words, they are downsizing the metaphor to an RPC that may be far less expensive if done with EJBs or even CORBA.

    In other words, it is valid if you want to make your service look like an exposed object. I see no point in it, though.

    Now on your examples: "make a booking", "transfer money", "get account statement". I see them clear as fine grained method calls. The first thing you hear in the street is to get away from those. They are expensive. Your need to create course grained services. The next example may seem a little extreme.

    Service: Loan service.
    Functionality: Actually, the service is able to process loan requests, payments, notifies due loans and you can ask for a loan status.
    How is it done?: There are four document types, each one has a particular schema: LoanRequest (input), LoanInfoRequest(input/output), LoanNotification (output) and LoanPaymentNote(input). Any input XML document may be sent to a port located in www.willyloans.com/loanport or to the email loanport at willyloans.com. There, an XML processor will determine the schema type, and send the actual data to the loan analysis department, to the loan payments subsystem, or to the loan service desk system. You can guess what each system does, and what each document may contain.
    You can create four WSDL if you want. All pointing to the same address. Just make them document style.
    More functionality? Just add it. Another schema and that's it. Versioning? No problem, several XML databases already support that.

    What do you think?

    William Martinez Pomares.
    Well, I have appreciated the attempt to raise the discussion to a higher abstraction layer. But, as usual, when it is time to somehow materialize the concepts we fall down to XML. Is SOA just that ? A blob transport protocol and some message handlers ? Is just the reactor pattern ? Wasn't it an architectural style ? Do we need all that mystic around what a SOA is (a Service - note the capitalization - is a very complex...) ? Don't you really think that few pattern would be sufficient and stop here all that pollution of marketing and pseudo-technical BS ? As I already posted, when discussing about SOA, the concepts bounce dangerously from a renewed "Timeless way of building" to vapourware. Guido
  123. It’s really good to read the above discussion as now we have started talking the about the SOA implementation and its associated technologies rather then just SOA from 10000 feet above. Seems like that we are adding an extra (Integration layer) to "revamp" the same old architecture to make the systems interoperable and loosely coupled. This sounds good but are we not adding another layer of complexity by writing some kind of business logic to make things work as independent services. I think we should make the things simple by rearranging our software infrastructure so that each unit can be scaled independently. http://lokeshpant.blogspot.com/2006/05/enterprise-portal-and-service-oriented.html
  124. I think we should make the things simple by rearranging our software infrastructure so that each unit can be scaled independently.

    http://lokeshpant.blogspot.com/2006/05/enterprise-portal-and-service-oriented.html
    If that were (a) possible and/or (b) the only problem, the whole discussion would be sort of superflous. Along come manageability issues, availability issues, inherent problems in "scaling independently", e.g. if one of your technologies is dependent on some database that would scale along with it and so on. And from your Blog the Gartner Quote.
    “The portal can be a logical and appropriate first step toward SOA implementation because its fundamental nature lends itself to SOA approaches”
    Why take a likely unsuitable technology for ones needs in order to make a first appropriate step to SOA? How bizarre. Here's another one (not from Gartner but from myself): Because Web 2.0 uses Ajax and uses XML and also some community services(sic!), Web 2.0 can be an appropriate step towards SOA.
  125. If that were (a) possible and/or (b) the only problem, the whole discussion would be sort of superflous. Along come manageability issues, availability issues, inherent problems in "scaling independently", e.g. if one of your technologies is dependent on some database that would scale along with it and so on.
    That’s what I am trying to say that if your architecture is loosely coupled and if you have managed your different application to work independently without any dependencies (Take one application + database as one service/app) then these entities can be easily scaled in terms of software/application/versions/hardware etc.
    Why take a likely unsuitable technology for ones needs in order to make a first appropriate step to SOA? How bizarre.

    Depends!! what suites your organizations requirement to include a portal or not, if not, then don’t add another set of software. I won’t go for a SOA implementation if the world is implementing it, atleast not for the sake of implementing it :-)

    Here's another one (not from Gartner but from myself): Because Web 2.0 uses Ajax and uses XML and also some community services (sic!), Web 2.0 can be an appropriate step towards SOA.
    Agreed...have a look into http://lokeshpant.blogspot.com/2007/05/jax-india-2007-web20-what-you-should-do.html

  126. Now, Karl.
    Service is not just a port. A Service is very complex thing that has a simple mission: to provide a business functionality as a service.
    A business functionality is not to abstract away from a department or an entire company. I think you are seriously on the wrong track. There are of course coarse grained business functionalities but they are coarse in a context. For example "Store or create customer profile" can be a valid "business functionality". But for an airline network carrier, "Change Booking" is almost impossible to encapsulate (in a meaningful way) in a single business message without *semantically* tightly coupled actions performed prior to this.

    How do you communicate with it? Using a port. You send a message to a port. That the message body contains an XML structure that is thighly coupled to reassemble a method call, is not of the Service business, it just doesn't care. That is, using that inflexible analogy makes your service miss those important features like being weak coupled, but it is your call.
    You can always use any tightly coupled technology as a weakly coupled technology if you must Object perform(Object) is *extremely* weakly coupled.

    Now, what separates an architect from a designer/developer is that the first one works with the service image I told you, business. The second ones will take that vision, see how can they publish that port, what do they need in the message or in the port itself to determine functionality, create a message processor that will route the requests to business logic and other levels, and then finish the work.
    Your notion of an architect is very close to the notion of a sales consultant. Your definition of what you want a service to be is very much like what any customers longs for: Silver bullet.
    The easiest way is the lazy programmer way. They put all the business logic in one class, create a method to publish it, create an XML schema that reassembles the method call, and use the port to get that XML. In other words, they are downsizing the metaphor to an RPC that may be far less expensive if done with EJBs or even CORBA.

    In other words, it is valid if you want to make your service look like an exposed object. I see no point in it, though.
    I see no point in de-abstracting either. You hand in a document for something to be done with it. From the client perspective, that *is* a function call totally and utterly regardless of how you implement it, if it is asynchronously called or not. There *must* be a contract for document handling, or the caller is left dangling with whatever the service does. This *is* a signature. It does not matter how the service is implemented for the user of the service of course. Only the characteristics matter. If you can get all your requirements covered with EJB methods and Corba - fine. If not, use something else.

    Now on your examples: "make a booking", "transfer money", "get account statement". I see them clear as fine grained method calls. The first thing you hear in the street is to get away from those. They are expensive. Your need to create course grained services. The next example may seem a little extreme.
    If my purpose is to travel somewhere "Make a booking" is quite natural, it does not get any more coarse grained than this. Nothing is more expensive than not selling anything I believe. If I can fill out a form to transfer money and hand it to the bank agent and get a stamped copy back, this again is as coarse grained as it gets. If I want account statements for bookkeeping, "get account statement" seems to be a sensible decision. Of course there are business interactions that are even more coarse grained, like say, insureCar or healthInsuranceQuoteRequest but that does not turn any meaningful customer facing business interaction (a service) into having the granularity you want it to have.
  127. A business functionality is not to abstract away from a department or an entire company. I think you are seriously on the wrong track. There are of course coarse grained business functionalities but they are coarse in a context. For example "Store or create customer profile" can be a valid "business functionality". But for an airline network carrier, "Change Booking" is almost impossible to encapsulate (in a meaningful way) in a single business message without *semantically* tightly coupled actions performed prior to this.
    Ok, Karl. I think you an I agree on several things. I have a problem sometimes when people doesn't clearly understand what I'm referring to. Let's see: 1. A business functionality cannot be abstracted in that way. There is a wrong concept between developers, that assume abstraction is talking about business needs, opposite to implementation. Abstraction is creating a model of something, with less detail. You can abstract your implementation using a model of classes in UML, or you can abstract a business process using a business model. Problem comes when developers try to mix the two. 2. A service offers some functionality. That should be clear. The developers implements all he needs for the service to work. Simple. 3. "Object perform(Object)", as I say, it's your call. That assumes objects in the platforms, assumes a response, and assumes parameters. That is coupled to me, you only "loose" the particular object type. 4. My notion of an architect is much more complex. I teach at the university that course. An architect looses some detail as a master designer, to obtain it back as a business analyst. As I said, Architect is not the oldest programmer in the company, it has competence in six major roles or subdomains. But I cannot comprise six moths of lecture in a paragraph. 5. Far away from what I have said in this thread. Services are not for everyone, they are not panacea nor silver bullets, they need more an architect than a java developer, and they won't be useful or even different from what we already have until the mainstream stops buying the vendors interpretation of a YAMTCARO, and requirement analyst stop asking the developers to create services just because everyone is doing that. 6. As you see it, it may be right. "Make a Booking" seems to me a perfect task for a Booking Service. You can also add a another task to cancel a reservation and even request an availability report. All of them perfect tasks for a Booking Service. Those are called "operations". 7. Lastly, I mention a "complex thing" not because services are difficult to create. They are just not as simple as creating a method with a string parameter. Hope this helps. William Martinez Pomares
  128. The coupling mystery[ Go to top ]

    "Object perform(Object)", as I say, it's your call. That assumes objects in the platforms, assumes a response, and assumes parameters. That is coupled to me, you only "loose" the particular object type.
    I find this notion of "coupled" strange to say the least. At the end of the day for whatever service, a client will send something to it. Whether you call it the input message or the input object or the input document does not really matter. The client gets back a result. If the result is retrieved synchronously or asynchronously, again, does not matter. The only thing (most of the time, with the notable exception of fire-and-forget and delayed receipts) that needs to be ensured is that the response is what the client expects and that it is returned/retrieved within a specified time frame. (To be fair, from a business service perspective it is a little more complicated, because from a client perspective you might of course get various responses, say an MOM message, a SMS and an email as a booking confirmation, but still there will usually be a "primary" response). Essentially, to me, this means that the service must be stable over time. This is the only decoupling that I can see to be mandatory in an SOA and it is totally technology agnostic (and ironically it is one that a lot of products and tools are very bad in providing, regardless of the implementing technology).
  129. A business functionality is not to abstract away from a department or an entire company. I think you are seriously on the wrong track. There are of course coarse grained business functionalities but they are coarse in a context. For example "Store or create customer profile" can be a valid "business functionality". But for an airline network carrier, "Change Booking" is almost impossible to encapsulate (in a meaningful way) in a single business message without *semantically* tightly coupled actions performed prior to this.


    Ok, Karl.
    I think you an I agree on several things. I have a problem sometimes when people doesn't clearly understand what I'm referring to. Let's see:

    1. A business functionality cannot be abstracted in that way. There is a wrong concept between developers, that assume abstraction is talking about business needs, opposite to implementation. Abstraction is creating a model of something, with less detail. You can abstract your implementation using a model of classes in UML, or you can abstract a business process using a business model. Problem comes when developers try to mix the two.

    2. A service offers some functionality. That should be clear. The developers implements all he needs for the service to work. Simple.

    3. "Object perform(Object)", as I say, it's your call. That assumes objects in the platforms, assumes a response, and assumes parameters. That is coupled to me, you only "loose" the particular object type.

    4. My notion of an architect is much more complex. I teach at the university that course. An architect looses some detail as a master designer, to obtain it back as a business analyst. As I said, Architect is not the oldest programmer in the company, it has competence in six major roles or subdomains. But I cannot comprise six moths of lecture in a paragraph.

    5. Far away from what I have said in this thread. Services are not for everyone, they are not panacea nor silver bullets, they need more an architect than a java developer, and they won't be useful or even different from what we already have until the mainstream stops buying the vendors interpretation of a YAMTCARO, and requirement analyst stop asking the developers to create services just because everyone is doing that.

    6. As you see it, it may be right. "Make a Booking" seems to me a perfect task for a Booking Service. You can also add a another task to cancel a reservation and even request an availability report. All of them perfect tasks for a Booking Service. Those are called "operations".

    7. Lastly, I mention a "complex thing" not because services are difficult to create. They are just not as simple as creating a method with a string parameter.

    Hope this helps.

    William Martinez Pomares
    Hi William, I have read the example on your blog and it is a RESTful service just as I thought. I think you are confused in a number of ways. 1. Firstly your starting place should not be the WS-* specs. If you know anything about specs you will realise that they are mostly political documents and have very little to do with "best practice" and practical "real world" design. 2. Secondly you seem to want to take an implementation agnostic stance. Shunning working code and viewing the world from an architectural perspective. In the end it is the code that counts! 3. You seem to not understand what is meant by a "Uniform Connector" in a RESTful sense, and that indeed an Uniform Connector can be deemed a message passing interface in an OO sense, the only restriction being a fixed number of verbs (GET, PUT, etc). I tried to post to your blog to no avail. So I will try and explain here. The issue is indeed coupling. With SOAP and Web Services the interface is not uniform and can change. Clients are dependent on the interface and will break should the interface change over time. This is the same problem with CORBA as the original author points out. The trick with REST is to define an interface that doesn't change. The "uniform connector". By doing this you reduce coupling, because the client no longer needs to know (is no longer dependant on) the specific interface of the server. The client can assume a uniform interface. Having done this you have now reduced the volcabulary between your client and server to a uniform number of verbs, but this can be overcome by implicity encoding the meaning of each document in the document itself. So with REST it is the document (message) that describes to the server the service required by the client, not the interface. By doing this you can meet the uniform connector restraint and reduce coupling. So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb: SEND(MESSAGE, RECIEVER) It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent: RECIEVER.MESSAGEX() Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux. Paul.
  130. The never changing interface[ Go to top ]

    So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.
    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like String processMessage(messageName, messageContent) does precisely the same. The problem with these kind of service description is, that they shift the whole burden of implementing and maintaining the client interface on the client. Which, from a user perspective sucks. As a user of service, I do not want to know what the precise message mechanism is. So in the end, I need all sorts of scaffolding to support message creation and versioning. The fact that the protocol does not really care about versioning and actual message content also does not take the burden off you to handle the stuff in the server. Of course certain things are easily done, if you do not care about the actual message content, like adding a field. But this metaphor starts to break down quickly, as soon as you start removing a field in the response or to actually restructure the response. The only way to keep the client stable is effectively to have a version number in the request, which is, again, not really different from adding version numbers to your method signature (and data objects effectively). The problem here and the profound misunderstanding is that there is something like semantically weak coupling. In my experience, this does not exist. There is, effectively only ever temporally weak coupling, which is a glorified term for "unless totally impossible, clients must continue to work even if the service undergoes a version change". How that is implemented is totally technology agnostic. There is of course also "technically weak coupling" but this is usually a solution and not a requirement.
  131. Re: The never changing interface[ Go to top ]

    So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.


    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like

    String processMessage(messageName, messageContent)

    does precisely the same.
    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector". Paul.
  132. So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.


    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like

    String processMessage(messageName, messageContent)

    does precisely the same.


    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".

    Paul.
    Your are simply delegating to problem to others: the users of the connectors. OK, it is perfectly reasonable to add layers of abstraction, just as TCP that gives you a virtual circuit to a port. It is an abstraction built over an unreliable network. It solves a problem. But, what problem does solve the uniform connector ? It looks like an extra layer with little or no benefit. I mean that behind the connector there is something that must know very well the "payload" received. And there must be an agreement (a contract ? an "iterface" definition ? call it as you want) with the subject that put that "payload" on the wire. So, wrt to the end to end communication, that undoubtedly exists because messages do not live on the wire only, they must be processed sometime, what is the benefit of the uniform connector. Guido
  133. Re: The never changing interface[ Go to top ]

    So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.


    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like

    String processMessage(messageName, messageContent)

    does precisely the same.


    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".

    Paul.
    In effect you trade "Data coupling" for "Data Structure/Stamp coupling". By all means do, but in most cases this is considered to increase coupling, rather than decrease it.
  134. Re: The never changing interface[ Go to top ]

    So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.


    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like

    String processMessage(messageName, messageContent)

    does precisely the same.


    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".

    Paul.


    In effect you trade "Data coupling" for "Data Structure/Stamp coupling". By all means do, but in most cases this is considered to increase coupling, rather than decrease it.
    Slow down guys and think a little :^) It is only stamp coupling if the data in my document is not related to each other. I.e. if the data in the document does not represent a cohesive whole. What I think you really mean is control coupling, but even here this is not the case because the client doesn't control the server through the data. The operation performed by the server is implicit. The server can do what it likes. Let me give an example of a uniform connector: GET(URL) POST(URL, DATA) PUT(URL, RESOURCE) DELETE(URL) There you go, just four verbs. Now all web servers in the world understand this interface. Also all webservers offer extensible services through this uniform interface that can change at any time without breaking existing clients. Lets give another example: SEND(MESSAGE, RECEIVER) All messaging systems in the world can deal with this one too. And again the services offered by the receiver are extensible without breaking existing clients. do you see a pattern here..? BTW. Wikipedia provides a good discussion on coupling: http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Paul.
  135. Although this is a kind of rewording of earlier responses, but let it be. We are talking about an interface that defines the service (business) functionality. A "never changing interface" cannot fulfill its purpose. It just delegate the definition into a "document interface", while it lies unnecessarily in the way. Somewhere, somehow one has to understand the definition and cope with its changes. It may seem that a change in a document interface (versioning) is gracefully "handled" because it can naturally be ignored, not blowing up the application. This is just avoiding immediate solution. Of course, IMO.
  136. So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.


    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like

    String processMessage(messageName, messageContent)

    does precisely the same.


    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".

    Paul.


    In effect you trade "Data coupling" for "Data Structure/Stamp coupling". By all means do, but in most cases this is considered to increase coupling, rather than decrease it.


    Slow down guys and think a little :^)

    It is only stamp coupling if the data in my document is not related to each other. I.e. if the data in the document does not represent a cohesive whole. What I think you really mean is control coupling, but even here this is not the case because the client doesn't control the server through the data. The operation performed by the server is implicit. The server can do what it likes.

    Let me give an example of a uniform connector:

    GET(URL)
    POST(URL, DATA)
    PUT(URL, RESOURCE)
    DELETE(URL)
    Let me give you an example of uniform connector. typedef sequence IOBuffer; interface StreamSource { IOBuffer read(in long nbytes) raises (IOException); void close() raises (IOException); }; interface RESTfulObject { StreamSource get(); void post(Any data); RESTfulObject put(Any data); void delete(); }


    There you go, just four verbs. Now all web servers in the world understand this interface. Also all webservers offer extensible services through this uniform interface that can change at any time without breaking existing clients.

    There you go too. All CORBA servers in the world understand this IDL. Also all CORBA servers offer extensible services through this uniform interface that can change at any time without breaking existing clients. Wait a minute. This is partially true. What is the service here ? The webserver or the "implementation" of the resource ? If it is the webserver, well, tell me, what is the difference with a CORBA server ? If the service is the implementation of the resource then, what would happen to existing clients if the document returned by GET(URL) changes. What would happen to existing clients if DATA argument to POST operations changes its structure ? Maybe some voodoo would help. Guido
  137. So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.


    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like

    String processMessage(messageName, messageContent)

    does precisely the same.


    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".

    Paul.


    In effect you trade "Data coupling" for "Data Structure/Stamp coupling". By all means do, but in most cases this is considered to increase coupling, rather than decrease it.


    Slow down guys and think a little :^)

    It is only stamp coupling if the data in my document is not related to each other. I.e. if the data in the document does not represent a cohesive whole. What I think you really mean is control coupling, but even here this is not the case because the client doesn't control the server through the data. The operation performed by the server is implicit. The server can do what it likes.

    Let me give an example of a uniform connector:

    GET(URL)
    POST(URL, DATA)
    PUT(URL, RESOURCE)
    DELETE(URL)

    Let me give you an example of uniform connector.


    typedef sequence IOBuffer;

    interface StreamSource {
    IOBuffer read(in long nbytes) raises (IOException);
    void close() raises (IOException);
    };


    interface RESTfulObject {

    StreamSource get();
    void post(Any data);
    RESTfulObject put(Any data);
    void delete();

    }




    There you go, just four verbs. Now all web servers in the world understand this interface. Also all webservers offer extensible services through this uniform interface that can change at any time without breaking existing clients.



    There you go too.
    All CORBA servers in the world understand this IDL. Also all CORBA servers offer extensible services through this uniform interface that can change at any time without breaking existing clients.
    Wait a minute.
    This is partially true. What is the service here ?
    The webserver or the "implementation" of the resource ?
    If it is the webserver, well, tell me, what is the difference with a CORBA server ?
    If the service is the implementation of the resource then, what would happen to existing clients if the document returned by GET(URL) changes.
    What would happen to existing clients if DATA argument to POST operations changes its structure ?
    Maybe some voodoo would help.

    Guido
    Guido, No. This is not uniform. All CORBA Servers do not guarantee this interface in IDL. So for CORBA servers who do not publish this IDL to their clients this will not work. Like I say, with IDL, WSDL etc clients can assume very little, and the runtime interface is brittle and breaks very often (every time there is a benign change to the service). Paul.


  138. Guido,

    No. This is not uniform. All CORBA Servers do not guarantee this interface in IDL. So for CORBA servers who do not publish this IDL to their clients this will not work.

    Like I say, with IDL, WSDL etc clients can assume very little, and the runtime interface is brittle and breaks very often (every time there is a benign change to the service).

    Paul.
    You should know that webservers have your common uniform interface because they implements HTTP protocol (an OO protocol) that defines basic methods (GET, POST etc) and explictly requires for extensibility. I cannot believe that tight coupling is caused by a lack of a RFC. The IDL I propose is a kind of CORBA-ized HTTP protocol. Any CORBA server that implements that IDL would achieve your goal Well, I really think that your goal hides the real problem that is behind the scene, pretending that the implementation of the resource is an implementation irrelevant detail. Do you really think that the heart of a SOA is just a conventions for the URLs in a HTTP world ? However, from a conceptual point of view (the one where all SOA discussions should keep anchored) there is no difference between your (HTTP-coupled) approach and a CORBA one. Guido
  139. Re: The never changing interface[ Go to top ]

    Guido,

    No. This is not uniform. All CORBA Servers do not guarantee this interface in IDL. So for CORBA servers who do not publish this IDL to their clients this will not work.

    Now, it is getting seriously weired. Apparently, you want all systems in the world to use the same technical interface. You want them to be uniform globally. And because HTTP Servers are around, you sort of assume, this same interface must be HTTP? But what is the advantage for the client? As a client, I just don't care about this low level kind contract. I am interested in business contracts.
    Like I say, with IDL, WSDL etc clients can assume very little, and the runtime interface is brittle and breaks very often (every time there is a benign change to the service).

    Paul.
    But only if the runtime interface is indeed changed. If it is not changed, it does not change. Simple as that. There is nothing in Corba/EJB and what have you that force you to make your service to be explicit. It does not become more true just because you insist. Also, if I switch off POST on my HTTP Servers, I have as per your definition changed the runtime interface.
  140. Re: The never changing interface[ Go to top ]

    Hi Guys, This is my last post. BTW you don't have to take my word for it, read Roy Fieldings disseration or listen to what Alan Kay has been bitching about for over 20 years. Maybe they are just weirdos too :^).
    Guido,

    No. This is not uniform. All CORBA Servers do not guarantee this interface in IDL. So for CORBA servers who do not publish this IDL to their clients this will not work.




    Now, it is getting seriously weired. Apparently, you want all systems in the world to use the same technical interface. You want them to be uniform globally. And because HTTP Servers are around, you sort of assume, this same interface must be HTTP? But what is the advantage for the client? As a client, I just don't care about this low level kind contract. I am interested in business contracts.

    No I just want Servers that share a common Protocol to agree a uniform connector interface. Protocol means a shared understanding. With CORBA, EJB, WS-* etc. it is only the wire protocol that is uniform and agreed, there is no uniform service protocol.

    Like I say, with IDL, WSDL etc clients can assume very little, and the runtime interface is brittle and breaks very often (every time there is a benign change to the service).

    Paul.


    But only if the runtime interface is indeed changed. If it is not changed, it does not change. Simple as that. There is nothing in Corba/EJB and what have you that force you to make your service to be explicit. It does not become more true just because you insist. Also, if I switch off POST on my HTTP Servers, I have as per your definition changed the runtime interface.
    I didn't say that you were forced to do anything with CORBA. That is just my point. With REST you are forced (or constrained). It is the RESTful constraint of a uniform connector which means that your client can rely on a basic service protocol which is common to all servers and will never change at runtime. An HTTP Webserver without POST is not an HTTP Webserver, by definition. Paul.
  141. Hi Guys,

    This is my last post.
    First relax. We are only discussing, exchanging opinion. In a quite politically correct way, it seems. Then, as you want. This is a free site, noone can force you to participate to a discussion. It has been your choice and you can stop whenever you want.
    BTW you don't have to take my word for it, read Roy Fieldings disseration or listen to what Alan Kay has been bitching about for over 20 years. Maybe they are just weirdos too :^).
    Maybe, why not. Anyway, I will give a try.


    Guido,

    No. This is not uniform. All CORBA Servers do not guarantee this interface in IDL. So for CORBA servers who do not publish this IDL to their clients this will not work.




    Now, it is getting seriously weired. Apparently, you want all systems in the world to use the same technical interface. You want them to be uniform globally. And because HTTP Servers are around, you sort of assume, this same interface must be HTTP? But what is the advantage for the client? As a client, I just don't care about this low level kind contract. I am interested in business contracts.



    No I just want Servers that share a common Protocol to agree a uniform connector interface. Protocol means a shared understanding. With CORBA, EJB, WS-* etc. it is only the wire protocol that is uniform and agreed, there is no uniform service protocol.
    Well, I learned to take nothing for granted on TSS I don't know what is a protocol for you. Expecially a service protocol.



    Like I say, with IDL, WSDL etc clients can assume very little, and the runtime interface is brittle and breaks very often (every time there is a benign change to the service).

    Paul.


    But only if the runtime interface is indeed changed. If it is not changed, it does not change. Simple as that. There is nothing in Corba/EJB and what have you that force you to make your service to be explicit. It does not become more true just because you insist. Also, if I switch off POST on my HTTP Servers, I have as per your definition changed the runtime interface.

    I didn't say that you were forced to do anything with CORBA. That is just my point. With REST you are forced (or constrained). It is the RESTful constraint of a uniform connector which means that your client can rely on a basic service protocol which is common to all servers and will never change at runtime. An HTTP Webserver without POST is not an HTTP Webserver, by definition.

    Paul.
    Again, you are still not answering (voluntarily ?) my question about the implementation of the resource. And my question about the benefit of a uniform connector. You cannot say "put behind whatever you want because the important part is the way you activate what is behind". It is whatever is behind the is the entity I want to talk with. SOA is not an (uniform) interconnection mechanism. Guido
  142. Hi Guido,
    This is partially true. What is the service here ? The webserver or the "implementation" of the resource ? If it is the webserver, well, tell me, what is the difference with a CORBA server ? If the service is the implementation of the resource then, what would happen to existing clients if the document returned by GET(URL) changes. What would happen to existing clients if DATA argument to POST operations changes its structure ? Maybe some voodoo would help.
    What is the service? Well it depends. Lets assume that we are using a GET(URL). The HTTP protocol says that a "GET" means you want to retrieve a resource from the server. The "URL" tells you the universal name of that resource. The HEADER in the HTTP response will tell you what type of resource this is, i.e the mime type. So for Youtube the service may be to retrive a video clip. If my client doesn't understand the mime type in the HTTP response it can prompt the user to download a plug-in. So the service is defined by GET and the document (video) in the HTTP response. The Equivalent in Corba RPC would be: Stream getStreamingVideo(String videoName); defined in IDL. Now what happens when I want to add another service? Say I want to allow users to vote on videos: With HTTP I would use a POST URL. So clients could post a vote. This is a benign change (adding a form to my video page) and clients should not break. With Corba I would need to change my IDL: Stream getStreamingVideo(String videoName); void postVote(String videoName, Int vote); This change to my IDL would break all existing clients (without some dodgy versioning scheme). Also existing clients will not be able to submit votes without code changes. Either way I need to recompile all my clients. This is a big deal, and why CORBA, EJB, SOM, COM, OpenDoc etc never really took off. Paul.
  143. Hi Guido,


    This is partially true. What is the service here ?
    The webserver or the "implementation" of the resource ?
    If it is the webserver, well, tell me, what is the difference with a CORBA server ?
    If the service is the implementation of the resource then, what would happen to existing clients if the document returned by GET(URL) changes.
    What would happen to existing clients if DATA argument to POST operations changes its structure ?
    Maybe some voodoo would help.


    What is the service? Well it depends. Lets assume that we are using a GET(URL).

    The HTTP protocol says that a "GET" means you want to retrieve a resource from the server. The "URL" tells you the universal name of that resource. The HEADER in the HTTP response will tell you what type of resource this is, i.e the mime type.

    So for Youtube the service may be to retrive a video clip. If my client doesn't understand the mime type in the HTTP response it can prompt the user to download a plug-in.

    So the service is defined by GET and the document (video) in the HTTP response. The Equivalent in Corba RPC would be:

    Stream getStreamingVideo(String videoName);

    defined in IDL.

    Now what happens when I want to add another service? Say I want to allow users to vote on videos:

    With HTTP I would use a POST URL. So clients could post a vote. This is a benign change (adding a form to my video page) and clients should not break. With Corba I would need to change my IDL:

    Stream getStreamingVideo(String videoName);
    void postVote(String videoName, Int vote);

    This change to my IDL would break all existing clients (without some dodgy versioning scheme). Also existing clients will not be able to submit votes without code changes. Either way I need to recompile all my clients.

    This is a big deal, and why CORBA, EJB, SOM, COM, OpenDoc etc never really took off.

    Paul.
    Hi Paul, first let's agree on the concept that a URL is totally equivalent to an IOR. With this in mind your IDL proposal is wrong. But, let's assume your IDL, there are tons of solution not breaking existing client. Well, let's agree. Existing clients are those that play videos. New clients are those that play videos and let you vote. I think you know that inheritance is possible with CORBA, something like interface VideoService { Stream getStreamingVideo(String videoName); } interface CRMVideoService extends VideoService { Votable getVotable(String videoName); } Need more ? Never heard about DII ? If we are discussing at a conceptual level, there isn't any difference. But, I think your are adding to a conceptual discussion some implementation stuff. When you say
    With HTTP I would use a POST URL. So clients could post a vote. This is a benign change (adding a form to my video page) and clients should not break.
    You are wrong. Which client are you talking about. A web browser, I guess. Now, a web browser is able to POST a vote without breaking because of HTML. But, if HTML changes clients will break !!!!!!! A web browser is able to POST a vote because there is a human behind that is able to understand in which field to put the vote; there are some metadata (the descriptive part of the page) that allows that. If you strip metadata (i.e., a page with only input fields) I bet you will unable to vote. CORBA never took off ? Checkout Michi Henning writings for that. EJB ? I prefer to say nothing on this. COM ? I would bet that DDE was an important part of it Guido.
  144. Hi Guido,


    This is partially true. What is the service here ?
    The webserver or the "implementation" of the resource ?
    If it is the webserver, well, tell me, what is the difference with a CORBA server ?
    If the service is the implementation of the resource then, what would happen to existing clients if the document returned by GET(URL) changes.
    What would happen to existing clients if DATA argument to POST operations changes its structure ?
    Maybe some voodoo would help.


    What is the service? Well it depends. Lets assume that we are using a GET(URL).

    The HTTP protocol says that a "GET" means you want to retrieve a resource from the server. The "URL" tells you the universal name of that resource. The HEADER in the HTTP response will tell you what type of resource this is, i.e the mime type.

    So for Youtube the service may be to retrive a video clip. If my client doesn't understand the mime type in the HTTP response it can prompt the user to download a plug-in.

    So the service is defined by GET and the document (video) in the HTTP response. The Equivalent in Corba RPC would be:

    Stream getStreamingVideo(String videoName);

    defined in IDL.

    Now what happens when I want to add another service? Say I want to allow users to vote on videos:

    With HTTP I would use a POST URL. So clients could post a vote. This is a benign change (adding a form to my video page) and clients should not break. With Corba I would need to change my IDL:

    Stream getStreamingVideo(String videoName);
    void postVote(String videoName, Int vote);

    This change to my IDL would break all existing clients (without some dodgy versioning scheme). Also existing clients will not be able to submit votes without code changes. Either way I need to recompile all my clients.

    This is a big deal, and why CORBA, EJB, SOM, COM, OpenDoc etc never really took off.

    Paul.

    Hi Paul,
    first let's agree on the concept that a URL is totally equivalent to an IOR.
    With this in mind your IDL proposal is wrong.
    But, let's assume your IDL, there are tons of solution not breaking existing client.
    Well, let's agree. Existing clients are those that play videos.
    New clients are those that play videos and let you vote.
    I think you know that inheritance is possible with CORBA, something like

    interface VideoService {
    Stream getStreamingVideo(String videoName);
    }
    interface CRMVideoService extends VideoService {
    Votable getVotable(String videoName);
    }


    Need more ?
    Never heard about DII ?
    If we are discussing at a conceptual level, there isn't any difference.
    But, I think your are adding to a conceptual discussion some implementation stuff.
    When you say

    With HTTP I would use a POST URL. So clients could post a vote. This is a benign change (adding a form to my video page) and clients should not break.

    You are wrong.
    Which client are you talking about.
    A web browser, I guess.
    Now, a web browser is able to POST a vote without breaking because of HTML.
    But, if HTML changes clients will break !!!!!!!
    A web browser is able to POST a vote because there is a human behind that is able to understand in which field to put the vote; there are some metadata (the descriptive part of the page) that allows that.
    If you strip metadata (i.e., a page with only input fields) I bet you will unable to vote.
    CORBA never took off ? Checkout Michi Henning writings for that.
    EJB ? I prefer to say nothing on this.
    COM ? I would bet that DDE was an important part of it

    Guido.
    Hi Guido, I'm wrong? I suggest that you read the dissertation for yourself and then decide :^). Feel free to contact me on my blog when you are better informed: http://pab-data.blogspot.com/2006/10/rest-epiphany.html Looking forward to hearing from you. Paul.
  145. Hi Guido,

    I'm wrong? I suggest that you read the dissertation for yourself and then decide :^).

    Feel free to contact me on my blog when you are better informed:

    http://pab-data.blogspot.com/2006/10/rest-epiphany.html

    Looking forward to hearing from you.

    Paul.
    There are 3 possible outcomes: 1. I don't understand the dissertation 2. I don't understand the way you explain things 3. The dissertation hardly fits in the discussion, at least in the terms I am using Anyway, your intent was to stop posting on this thread and that'all. Maybe there were better way to do it, but OK anyone tries to give it's best, I guess. Guido.
  146. Re: The never changing interface[ Go to top ]

    So with REST the interface never needs to chnage, and as a consequence is less brittle then CORBA or WS-*. Incidently pure OO message passing uses the same trick. It is the server that determings the meaning of an OO message. The interface has only a single verb:

    SEND(MESSAGE, RECIEVER)

    It is the reciever that interprets the message and selects the appropriate method (process) to satisfy the service request. This approach is not RPC and is less coupled then the C++/Java Equivalent:


    RECIEVER.MESSAGEX()

    Where MESSAGEX is now hard-coded into the interface. The method selector is now part of the interface, rather then part of the message. Which means to add a new message would require a change in the interface thus breaking all clients. This is the crux.


    I find this discussion kind of bizarre to say the least. The technology, whether it is Corba, EJB, SOAP whatever (including REST) does impose absolutely nothing in this respect. The developer does. With EJB or Corba, something like

    String processMessage(messageName, messageContent)

    does precisely the same.


    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".

    Paul.


    In effect you trade "Data coupling" for "Data Structure/Stamp coupling". By all means do, but in most cases this is considered to increase coupling, rather than decrease it.


    Slow down guys and think a little :^)

    It is only stamp coupling if the data in my document is not related to each other. I.e. if the data in the document does not represent a cohesive whole. What I think you really mean is control coupling, but even here this is not the case because the client doesn't control the server through the data. The operation performed by the server is implicit. The server can do what it likes.

    Let me give an example of a uniform connector:

    GET(URL)
    POST(URL, DATA)
    PUT(URL, RESOURCE)
    DELETE(URL)

    There you go, just four verbs. Now all web servers in the world understand this interface. Also all webservers offer extensible services through this uniform interface that can change at any time without breaking existing clients.

    Lets give another example:

    SEND(MESSAGE, RECEIVER)

    All messaging systems in the world can deal with this one too. And again the services offered by the receiver are extensible without breaking existing clients.

    do you see a pattern here..?

    BTW. Wikipedia provides a good discussion on coupling:
    http://en.wikipedia.org/wiki/Coupling_%28computer_science%29

    Paul.
    Nope, Paul, youre just moving the "interface" into the document/payload instead of clearly stating it in the operation signature. There can be plenty of reasons for doing so, but looser coupling isnt one of them. HTTP post is great, and all servers understand it, but it there must be special code that understands the content of the post to handle it. This code is tightly coupled to the client, just like a web service endpoint is to its client.
  147. Re: The never changing interface[ Go to top ]

    Nope, Paul, youre just moving the "interface" into the document/payload instead of clearly stating it in the operation signature.

    There can be plenty of reasons for doing so, but looser coupling isnt one of them.

    HTTP post is great, and all servers understand it, but it there must be special code that understands the content of the post to handle it. This code is tightly coupled to the client, just like a web service endpoint is to its client.
    Hi John, You've got it. The service interface is in the data (if Mark Baker heard me say this he would say that is not an accurate description, e.g. "GET" is part of the interface but is not part of the data). Why do this? Well first of all it allows late-binding. The message interface is not fixed at compile time, but is determined (interpreted) at runtime. Secondly, the data can be self describing. So an intelligent client can gleam information about the service that wasn't fixed at compile time (e.g new links, new form elements, new mime-types etc) and deal with them in an intelligent way. This makes the service extensible. It also decouples the service interface from the client. Say if you extend your service, this represents a change to the service interface, but existing clients will still work, possibly ignoring the extensions. Messaging works in a similar way and allows the same thing. To get the full feel for what REST is about I suggest that you read the dissertation yourself: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm REST is not the last word in distributed computing, but it does point in the right direction I believe. As for WS-*, well it is a re-hash of the old RPC idea which has failed several times before. BTW. REST is not the only architectural style that focuses on runtime extensibility. As I said before pure message passing as performed in Smalltalk, Lisp etc takes a similar approach, and in so doing avoids a number of the problems with WS-*. Paul.
  148. Re: The never changing interface[ Go to top ]

    Nope, Paul, youre just moving the "interface" into the document/payload instead of clearly stating it in the operation signature.

    There can be plenty of reasons for doing so, but looser coupling isnt one of them.

    HTTP post is great, and all servers understand it, but it there must be special code that understands the content of the post to handle it. This code is tightly coupled to the client, just like a web service endpoint is to its client.


    Hi John,

    You've got it. The service interface is in the data (if Mark Baker heard me say this he would say that is not an accurate description, e.g. "GET" is part of the interface but is not part of the data). Why do this? Well first of all it allows late-binding. The message interface is not fixed at compile time, but is determined (interpreted) at runtime. Secondly, the data can be self describing. So an intelligent client can gleam information about the service that wasn't fixed at compile time (e.g new links, new form elements, new mime-types etc) and deal with them in an intelligent way.


    This makes the service extensible.

    It also decouples the service interface from the client. Say if you extend your service, this represents a change to the service interface, but existing clients will still work, possibly ignoring the extensions. Messaging works in a similar way and allows the same thing.

    To get the full feel for what REST is about I suggest that you read the dissertation yourself:

    http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

    REST is not the last word in distributed computing, but it does point in the right direction I believe. As for WS-*, well it is a re-hash of the old RPC idea which has failed several times before.

    BTW. REST is not the only architectural style that focuses on runtime extensibility. As I said before pure message passing as performed in Smalltalk, Lisp etc takes a similar approach, and in so doing avoids a number of the problems with WS-*.

    Paul.
    Hi Paul, Its trivial to do late binding with a web service, but very few people actually do it. Why? Because there are pretty few use cases when you have any use of it. J2EE web services has the dynamic invocation interface - but the only ones who use it are tool builders. Versioning is actually pretty simple, the main point to realize is that the "next" version of your service is actually a new service. Follow that path and existing clients will not break, while new clients will be able to take advantage of new features. Web services might be a re-hash of rpc (or not), but it has 3 advantages over previous efforts - (1) it works over http, (2) it works over http, (3) support from microsoft AND not-microsoft (ibm, sun, etc). BTW - I have used MQ series since -99 and I love it. I´ll use it any time I can and certainly I´ll prefer it to web services any day. But not because of late binding. I know that I have to design - and commit - to an interface in any case. Its the transaction support, guaranteed delivery, management interface, plethora of platform support, etc that makes me cherish MQ. Also, Smalltalk was my first real programming language (lets forget about pascal), and I love it as well. But for any effort with more than 5 average developers involved I prefer a strongly types language.
  149. Re: The never changing interface[ Go to top ]

    Nope, Paul, youre just moving the "interface" into the document/payload instead of clearly stating it in the operation signature.

    There can be plenty of reasons for doing so, but looser coupling isnt one of them.

    HTTP post is great, and all servers understand it, but it there must be special code that understands the content of the post to handle it. This code is tightly coupled to the client, just like a web service endpoint is to its client.


    Hi John,

    You've got it. The service interface is in the data (if Mark Baker heard me say this he would say that is not an accurate description, e.g. "GET" is part of the interface but is not part of the data). Why do this? Well first of all it allows late-binding. The message interface is not fixed at compile time, but is determined (interpreted) at runtime. Secondly, the data can be self describing. So an intelligent client can gleam information about the service that wasn't fixed at compile time (e.g new links, new form elements, new mime-types etc) and deal with them in an intelligent way.


    This makes the service extensible.

    It also decouples the service interface from the client. Say if you extend your service, this represents a change to the service interface, but existing clients will still work, possibly ignoring the extensions. Messaging works in a similar way and allows the same thing.

    To get the full feel for what REST is about I suggest that you read the dissertation yourself:

    http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

    REST is not the last word in distributed computing, but it does point in the right direction I believe. As for WS-*, well it is a re-hash of the old RPC idea which has failed several times before.

    BTW. REST is not the only architectural style that focuses on runtime extensibility. As I said before pure message passing as performed in Smalltalk, Lisp etc takes a similar approach, and in so doing avoids a number of the problems with WS-*.

    Paul.


    Hi Paul,

    Its trivial to do late binding with a web service, but very few people actually do it. Why? Because there are pretty few use cases when you have any use of it. J2EE web services has the dynamic invocation interface - but the only ones who use it are tool builders.

    Versioning is actually pretty simple, the main point to realize is that the "next" version of your service is actually a new service. Follow that path and existing clients will not break, while new clients will be able to take advantage of new features.

    Web services might be a re-hash of rpc (or not), but it has 3 advantages over previous efforts - (1) it works over http, (2) it works over http, (3) support from microsoft AND not-microsoft (ibm, sun, etc).

    BTW - I have used MQ series since -99 and I love it. I´ll use it any time I can and certainly I´ll prefer it to web services any day. But not because of late binding. I know that I have to design - and commit - to an interface in any case. Its the transaction support, guaranteed delivery, management interface, plethora of platform support, etc that makes me cherish MQ.

    Also, Smalltalk was my first real programming language (lets forget about pascal), and I love it as well. But for any effort with more than 5 average developers involved I prefer a strongly types language.
    Hi John, Like I said, REST is just an option. What I have found is that it is much simpler than WS-* for most use-cases. As for Smalltalk and strongly typed, I think you mean "manifestly typed". I agree here, manifest typing has its benefits. Fortunately manifest typing is available in Smalltalk too: http://www.strongtalk.org/ Paul.
  150. Re: The never changing interface[ Go to top ]

    Hi John,

    Like I said, REST is just an option. What I have found is that it is much simpler than WS-* for most use-cases.
    I think that depends on what you think should be included in "most use-cases". I know that for 99% of the use-cases that I am involved in realising web services is the way to go. I could of course implement a support layer for REST that would give me the same features as are already provided by WS, but why would I when its already there, with development support in the major IDE:s? I have done plenty of plain XML over HTTP services, before there was WS, some of which are still in production use, and I have no regrets about that.
  151. Re: The never changing interface[ Go to top ]

    Hi John,

    Like I said, REST is just an option. What I have found is that it is much simpler than WS-* for most use-cases.


    I think that depends on what you think should be included in "most use-cases". I know that for 99% of the use-cases that I am involved in realising web services is the way to go. I could of course implement a support layer for REST that would give me the same features as are already provided by WS, but why would I when its already there, with development support in the major IDE:s?

    I have done plenty of plain XML over HTTP services, before there was WS, some of which are still in production use, and I have no regrets about that.
    Hi John, I said "most use-cases" to be diplomatic. In fact IMO REST is superior to WS-* in all the use cases I've seen or can think off. But that is just my opinion :^). The reason why I've come to dislike these "discussions", is that they often come down to Ego. Distributed Architecture is not a black or white subject, no solution is either completely right or complety wrong. I am not saying that you are motivated by Ego, but generally I feel that Ego does seem to drive the tone of most TSS "debates". William and I, have merely tried to explain an alternative architectural style to WS-*. Now my explanation is probably flawed in many ways, but it is an honest attempt. I felt that williams explanation was pretty good however. If you are interested in REST as an alternative to WS-* here are some useful resources: The dissertation (a bit heavy going, but a vital source inorder to get to grips with the language used by REST folk): http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Mark Bakers website. Mark is a knowledgeable REST advocate and helped me understand REST when I was struggling: http://www.markbaker.ca/ As you can see he is much better qualified then me, and he as published some interesting articles on REST. There is also a REST discussion group on yahoo: http://tech.groups.yahoo.com/group/rest-discuss/ BTW. Good luck in your search for truth and enlightenment :^). Paul.
  152. Re: The never changing interface[ Go to top ]

    If you are interested in REST as an alternative to WS-*
    Well, I am, which is why I did read Fieldings work, some year ago. I just happened to come to a different conclusion than you. It doesnt have to mean that I am less enlightened than you - perhaps my input parameters are just different.
  153. Re: The never changing interface[ Go to top ]

    If you are interested in REST as an alternative to WS-*


    Well, I am, which is why I did read Fieldings work, some year ago. I just happened to come to a different conclusion than you.

    It doesnt have to mean that I am less enlightened than you - perhaps my input parameters are just different.
    Hi John, No I didn't mean that I was more enlightened then you. After all I spend most of my time stumbling in the dark :^). I was just wishing you well on your journey. If you have explored REST before and disgarded it then obviously it doesn't lay on your path to truth and enlightenment :^). Best wishes and Peace. Paul.
  154. Extension myths[ Go to top ]

    Say if you extend your service, this represents a change to the service interface, but existing clients will still work, possibly ignoring the extensions.
    As has been posted here several times before: Generally this is wishful thinking. Your clients are clients to your service not to your service protocol. If you change the return contract in an incompatible way, your clients break. If you "extend" the input protocol in an incompatible way the clients break. What's more important: A user of a service wants an API and an interface to program to. They don't want to code HTTP requests, corba request and the such.
  155. Re: The never changing interface[ Go to top ]

    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".
    How do different HTTP Servers differ from different Corba vendors? What if I find that I want to use some technology (say Corba) because I found it is the superior transport layer? Why is a connector that uses Corba and falls back to the defintion of String handleMessage(String message) not uniform? It does never get more uniform than this plus I can use the same technology for doing meaningful things with the message itself that are hidden from the caller. Essentially you are arguing for a technology layer rather than a concept that add zero value.
  156. Re: The never changing interface[ Go to top ]

    No. EJB, CORBA and WS-* aren't the same. With each of these technologies you specify the server interface yourself (by using a Java Interface, IDL and WSDL respectively). If you can specify the interface, then by definition you cannot guarantee that the interface is uniform across all servers (including ones that you did not write). Hence you broken the RESTful constraint of a "uniform connector".


    How do different HTTP Servers differ from different Corba vendors? What if I find that I want to use some technology (say Corba) because I found it is the superior transport layer? Why is a connector that uses Corba and falls back to the defintion of

    String handleMessage(String message)

    not uniform? It does never get more uniform than this plus I can use the same technology for doing meaningful things with the message itself that are hidden from the caller. Essentially you are arguing for a technology layer rather than a concept that add zero value.
    Karl, String handleMessage(String message) Is a remote procedure call to a procedure called "handleMessage" which takes a single parameter "message" of type "String" and returns a value of type "String". OK. Lets test this for uniformity. Is a Java String the same as a C++ String or a Smalltalk String? No. So we need an intermediate service definition: IDL. So lets look at this in IDL: String handleMessage(String message) This IDL interface may place restrictions on what can be passed. For example my String needs to look pretty much like a C++ String. Is that uniform? Also,lets assume, that I have defined a universal RPC server of my own with the following IDL: Object[] handle(Object[] params) Can I receive your message and return an answer? Do we have an agreed protocol? Are either of these interfaces uniform in anyway? Paul.
  157. Re: The never changing interface[ Go to top ]

    Karl,

    String handleMessage(String message)

    Is a remote procedure call to a procedure called "handleMessage" which takes a single parameter "message" of type "String" and returns a value of type "String".


    OK. Lets test this for uniformity. Is a Java String the same as a C++ String or a Smalltalk String? No. So we need an intermediate service definition: IDL. So lets look at this in IDL:

    String handleMessage(String message)

    This IDL interface may place restrictions on what can be passed. For example my String needs to look pretty much like a C++ String. Is that uniform?
    Essentially, I'd say that binding to a programming language is a good thing, so I would consider this a uniform connector. As long as you know the IDL and the description of the possible messages, you can use the service with whatever client you want. If I send rubbish to your uniform connector I would get rubbish (or an error message) back as well. So as long as my client program puts in the message in the expected form, I am fine. You will always need client side binding, so what is the problem. Of course, in order to really be uniform, one could always start passing byte arrays.
  158. Re: The never changing interface[ Go to top ]

    Karl,

    String handleMessage(String message)

    Is a remote procedure call to a procedure called "handleMessage" which takes a single parameter "message" of type "String" and returns a value of type "String".


    OK. Lets test this for uniformity. Is a Java String the same as a C++ String or a Smalltalk String? No. So we need an intermediate service definition: IDL. So lets look at this in IDL:

    String handleMessage(String message)

    This IDL interface may place restrictions on what can be passed. For example my String needs to look pretty much like a C++ String. Is that uniform?


    Essentially, I'd say that binding to a programming language is a good thing, so I would consider this a uniform connector. As long as you know the IDL and the description of the possible messages, you can use the service with whatever client you want. If I send rubbish to your uniform connector I would get rubbish (or an error message) back as well.

    So as long as my client program puts in the message in the expected form, I am fine. You will always need client side binding, so what is the problem. Of course, in order to really be uniform, one could always start passing byte arrays.
    Hi Karl, The problem is that I cannot guarantee the interface to my server. I can make no assumptions. This is why I need to get the IDL, compile it into stubs and link the stubs to my client. After compile/link time all bets are off. Should the server change it's service interface my client will break, and I will need new IDL, new stubs and a new client executable. Imagine having to do this to all the web browsers out there every time you wanted to extend your website? With REST I can add new pages to my website all the time and the browser understands this and can deal with it at runtime. This is what I mean by an extensible interface. Paul.
  159. Re: The never changing interface[ Go to top ]

    With REST I can add new pages to my website all the time and the browser understands this and can deal with it at runtime. This is what I mean by an extensible interface.
    Right, and with the Corba/EJB/POS (Plain Old Sockets) approach, I can add services to my implementation and the clients will know how to handle it, just like with your example. Still the clients have to know the contract and the server has to guarantuee that the contracts stay in place. This is a systems management/infrastructure/system architecture issue and has nothing to do with REST, Corba, EJB or POS.
  160. Hi Paul. Sorry I answer till now. Thanks to read my blog! But I'm not sure if you read actually mine, since I have not post on Rest. Anyway, I agree totally with you. Let me tell you that I understand what the "Uniform Connector" means (actually, I haven't mentioned before with that name). Please read back my posts, I was the one to say that the service is just functionality with a port, and that the only thing you can do is to post a message to it. Messaging is the weakest of all coupling. I also mention the message is the one to dictate what the service should do, and that the service is not a mere interface. About WS*, I'm not a vendor of it. I meant be REST to indicate that not all people understand what it means and apply what they think it is. WS* can do the trick too, with a document style WSDL and a schema that accepts anytype!. Finally, I still don't agree with OO. You may have an object that knows how to send messages, but not a stub with a object do(object) method, that is golden hammer syndrome, making a simple message sending operation into an OO method invocation. I'm glad someone agrees with me (at least I understand you do). William Martinez.
  161. Hi Paul.

    Sorry I answer till now. Thanks to read my blog!
    But I'm not sure if you read actually mine, since I have not post on Rest.

    Anyway, I agree totally with you. Let me tell you that I understand what the "Uniform Connector" means (actually, I haven't mentioned before with that name). Please read back my posts, I was the one to say that the service is just functionality with a port, and that the only thing you can do is to post a message to it. Messaging is the weakest of all coupling. I also mention the message is the one to dictate what the service should do, and that the service is not a mere interface.

    About WS*, I'm not a vendor of it. I meant be REST to indicate that not all people understand what it means and apply what they think it is. WS* can do the trick too, with a document style WSDL and a schema that accepts anytype!.

    Finally, I still don't agree with OO. You may have an object that knows how to send messages, but not a stub with a object do(object) method, that is golden hammer syndrome, making a simple message sending operation into an OO method invocation.

    I'm glad someone agrees with me (at least I understand you do).

    William Martinez.
    Hi William, I'm glad someone out there understands. Like I said what you have been describing is a RESTful service IMO. I also agree that you could implement a RESTful service usng SOAP, but to do so IMO kinds of misses the point. I'm all for keeping things simple, and SOAP adds nothing but complexity. As for OO - well that term as been polluted even more than SOA :^). With pure OO there is no need for stubs. What you have described is a "virtual function call" which I agree is akin to a procedure, hence RPC in CORBA et al. What I am talking about is pure message passing where the sender knows nothing about the receiver. The receiver answers the message either with an object or with a "doesNotUnderstand". This is pure messaging and makes no assumptions about the implementation (Class) of the receiver. Like I said before it is satified by the following "uniform connector": SEND(MESSAGE, RECEIVER) Now if all OO languages were implemented this way, then you could have message passing over the internet between objects (assuming an agreed message representation of course). Alan Kay as gone as far as suggesting that all objects should have an IP address. Personaly I think a URL would be more appropriate. With languages like Smalltalk, Lisp, Ruby, Python etc this is possible. With Java, C++ it is not. Hence CORBA, COM,... Anyway thanks for your contribution, and I look forward to you enabling posts on your blog. Paul.
  162. REALLY? Common Object Request Broker ARCHITECTURE isn't an architecture?
    Just because you declare it "architecture" it, won't make it one. Or to continue with word games, at best it is an architecture for "Common Object Request Brokering". Or on a slightly different note, just because you declare "Mission accomplished" does not win you the war (on software architecture that is!). Argueably, at the time the term "CORBA" was coined, the idea of "architecture" was different from what it is now. From an architectural point of view, Corba does not enforce nor support a particular architecture, even though it now supports (NOW, NOT IN THE 90s, YOU HEAR ME! IN THE 90s CORBA WAS NOT EVEN "COMMON" FOR ANY PRACTICAL PURPOSE! - sorry, I just had to shout that out, for it is the doom of men that they forget) creating an architecture, that is the support for non-functional requirements for a software system, and a fair number of the things that do this in CORBA are to my best knowledge still are optional. Why do I get worked up about this? Because a lot of the people who believe that CORBA is an architecture will happily wander off in the wrong direction (yet again and again and again) and one thing the term SOA can do, if nothing else, is to guide those people to use CORBA decently. Because CORBA in and by itself will not.
  163. Even if I can agree that SOA is, as someone likes to call it, an architectural style (read here few patterns and anti-pattern to follow) the reality is quite different. SOA is used to promote webservices: here it is not clear why old products are rebranded as SOA-ready even if almost everyone say that SOA can be implemented with EJB/CORBA or whatever. So why those products were not SOA-ready before ? SOA is compared to technologies (most frequent is CORBA): CORBA is normally blamed as a complex technology that had a wrong model (RPC, thightly-coupling, language dependency - yes, it has been said this too!!!!-) Well, the reality is that distributed systems are not for dummies. It is not possible to approach this domain after reading "Teach yourself CORBA in 10 minutes", design monster systems and then blame the technology rather than the own stupidity. If you design an IDL with an operation equivalent to String.getCharAt(int i) you cannot say CORBA is not good. It is like you decide to read a row from a database as SELECT col1 from table where id.. SELECT col2 from table where id.. ... and the say SQL is wrong. Everybody say that SOA is an old concept but it seems that a lot of people is using the buzzword to re-sell old stuff. But, someone could say why bother with marketing on TSS that is for technicians. Right, the technicians. Independent, of course. Guido
  164. Well, the reality is that distributed systems are not for dummies. It is not possible to approach this domain after reading "Teach yourself CORBA in 10 minutes", design monster systems and then blame the technology rather than the own stupidity.
    # Generally, I would agree that distributed systems are not for dummies. Because of this fact an ordering principle (or an architecture) is required to make such an infrastructure accessible for the less-than-genius programmer and designer while at the same time meeting the (so called!) non-functional requirements. One of my favorites are sentences like "Well, SOA is not simple", "Corba is not simple" etc. Of course they provide some degree of simplification, anything different would be outright stupid. Problem is, products and architectures tend to create a whole new class of problems that did not exist before (or more correctly, that nobody noticed). And more often than not, for a lot of products and technologies, the tradeoff is simple not worth the bought in problems - which is one of the reasons, there is so much chanting around stuff like ruby on rails and the like!
  165. Well, the reality is that distributed systems are not for dummies. It is not possible to approach this domain after reading "Teach yourself CORBA in 10 minutes", design monster systems and then blame the technology rather than the own stupidity.
    #

    Generally, I would agree that distributed systems are not for dummies. Because of this fact an ordering principle (or an architecture) is required to make such an infrastructure accessible for the less-than-genius programmer and designer while at the same time meeting the (so called!) non-functional requirements.

    One of my favorites are sentences like "Well, SOA is not simple", "Corba is not simple" etc. Of course they provide some degree of simplification, anything different would be outright stupid.
    I would rather say that problems in the domain covered by CORBA are not simple. CORBA isn't that difficult (at all), even in its slightly advanced aspects. But you must know what you are using. You cannot give a gun to a baby and then complaint because it fires.
    Problem is, products and architectures tend to create a whole new class of problems that did not exist before (or more correctly, that nobody noticed)
    Yes and no. When doing concurrent programming you have to deal with critical section, deadlocks, starvation etc. But concurrent programming has not been invented for fun.
    . And more often than not, for a lot of products and technologies, the tradeoff is simple not worth the bought in problems - which is one of the reasons, there is so much chanting around stuff like ruby on rails and the like!
    Again, it is hard to tell if these problems are due to the technology itself or it misuse. Guido
  166. SOA is too vaguely defined (if there is a consensus on its definition) to be compared to anything. Web Services vs CORBA Web Services, even though it doesn't offer anything new, is better than CORBA because of it is based on HTTP. That means no special middleware is needed to process the communication. A standard HTTP server is all that's required. This is an important advantage because it removed a lot of vendor specific issues that came with proprietary CORBA ORBs.
  167. ...Web Services vs CORBA

    Web Services, even though it doesn't offer anything new, is better than CORBA because of it is based on HTTP. That means no special middleware is needed to process the communication. A standard HTTP server is all that's required. This is an important advantage because it removed a lot of vendor specific issues that came with proprietary CORBA ORBs.
    What a nonsense! WS-* - either push responsibilities to do a lot of plumbing to the developers, or force using vendor provided libraries.
  168. SOA is too vaguely defined (if there is a consensus on its definition) to be compared to anything.

    Web Services vs CORBA

    Web Services, even though it doesn't offer anything new
    To me is not clear what they offer at all.
    , is better than CORBA because of it is based on HTTP. That means no special middleware is needed to process the
    slow
    communication.
    OK, for demos may be adequate.
    A standard HTTP server is all that's required. This is an important advantage because it removed a lot of vendor specific issues that came with proprietary CORBA ORBs.
    Maybe you are unaware of what CORBA is surely since version 2.3, but most likely since the epoch. And I have some doubt on WebService/SOAP too. You should not always listen words thrown in a blender. Guido
  169. br>Maybe you are unaware of what CORBA is surely since version 2.3, but most likely since the epoch.
    And I have some doubt on WebService/SOAP too.
    You should not always listen words thrown in a blender.

    Guido
    I admit that my experience with CORBA came from the earlier days(v2.1). The specification may have evolved to cover some of the limitations. Performance is an issue with many web services implementations. But I do like the idea of having just a web server that I know well.
  170. SOA and CORBA are two different concept.SOA is not a technology whereas CORBA is a distributed Object Oriented language and platform independent technology.You can say CORBA already have some of the built in service that we are facing in the SOA world like Interface repository ( Enterprise repository in SOA) , Implementation repository etc.These are the services which can be built and published and client application will register for it and consume it.CORBA had a definite programming model and backbone(ORB) to run. SOA, on the other hand , is a concept for loosely coupled , refactored , distributed architecture where there will be different service producers and consumers.The consumer and producers will be interacting in a very flexible and decoupled way so that enterprise application complexity on tight coupling gets reduced.SOA opens up the face for different concepts like webservice , ESB , Enterprise repository ,Enterprise Security etc. When CORBA came , it was not designed to solve the integration issues in enterprise.It got popularity because of its independence nature over language and platform. We didn't have webservice , even if SOAP was coming to market with its limited features over RPC. So you can't directly compare CORBA with SOA.SOA is not just XML and SOAP or WebService , its huge and capable of giving more to enterprise world for IT and Business.