Discussions

News: SOA Approach to Integration

  1. SOA Approach to Integration (12 messages)

    After I read Service Oriented Architecture with Java I decided to read another SOA-book of Packt Publishing. The book is titled: SOA Approach to Integration As an Enterprise Integration Architect I was very pleased to read this book and I would recommend every integration architect to read it. Why? Not only because it will teach you the ideas behind SOA from an integration perspective, but also because it teaches you the developers language. The book is also of great value if you are a developer, because it teaches you the various technologies to implement SOA. The book starts with positioning SOA as an integration style, which I do think is a valid perspective. The term Process-Oriented Architecture is introduced. Yet another acronym, POA, which sounds to me like BPM. BPM, however, is not mentioned in the index of the book. But let's stay away from this semantic discussion. The authors explain best practices for using XML for integration. They explain the web services approach, including design guidelines. The WS-I Basic Profile comes to the scene and - in the context of Process Oriented Integration - BPEL is comprehensively explained, including some code snippets. To me the most interesting part of the book was the last chapter. These 90 pages (a quarter of the book) deal with the SOA platform, being the Enterprise Service Bus (ESB). The ESB architecture is described as well as the concepts of Service Containers as the primary tier of the bus. Bus Services are mentioned (Mediation, Transformation and Process Flows); Security and Transactions; Reliability, Scalability and Management; Application Development Considerations; and finally Extending the ESB to Partners. These are the things developers are concerned with. It is a very good idea for an architect to have a notice of what puts the burden on the developers, and to be able to understand their language. My conclusion is that this book supplies its readers with feet-on-earth knowledge of SOA between concepts and technical implementation. Very worthwhile reading.

    Threaded Messages (12)

  2. Re: SOA Approach to Integration[ Go to top ]

    I find it interesting that you mention the term Process-Oriented Architecture to describe SOA. It occurred to me that SOA is a procedural approach to web services. By the same token, I think REST is an object-oriented approach to web services.
  3. Re: SOA Approach to Integration[ Go to top ]

    I find it interesting that you mention the term Process-Oriented Architecture to describe SOA.

    It occurred to me that SOA is a procedural approach to web services.

    By the same token, I think REST is an object-oriented approach to web services.
    You can use REST to implement SOA. I would suggest learning what SOA actually is before making these kinds of judgements. SOA is not just another word for web services not HTTP+SOAP+WSDL even though that's usually how it's implemented. Anyone who tells you otherwise is confused. Often people who claim they have a service oriented architecture really have JABOWS (just a bunch of web services.)
  4. Re: SOA Approach to Integration[ Go to top ]

    Very misleading couple of sentences here. SOA cannot be an approach "of any kind" to web services, SOA is not web services, the "S" in SOA stands for "service", not for "web services". It is valid to say that SOA is a methodology and when applying it one can choose web services, if a web services implementation is used to achieve SOA then a communication protocol must be used and among options SOAP and REST are popular choices. Even at the communication protocol level I don't see where procedural or object-oriented comes into picture in the two liner comparison.
  5. I fully agree with this, and is a battle I have had many times. For me the definition of SOA is very simple, and should never mention technologies. I like to think of SOA as the proper encapsulation of business logic and data into reusable blocks, that can be used in isolation or together to form compostion applications. I am amazed there are so many books on this as the concept should be simple. In fact, SOA is just another word for good component design, and really is nothing new. But that's my view, no doubt others will have a different slant on it.
  6. Re: SOA Approach to Integration[ Go to top ]

    In fact, SOA is just another word for good component design, and really is nothing new.
    This is a completely useless definition. What's next, SOCC - Service Oriented Cancer cure, which is just another word for good cancer treatment?
  7. Re: SOA Approach to Integration[ Go to top ]

    Not sure if you are agreeing with me or not, but to clarify I am saying that SOA is just another term for good design and therefore is effectively useless and means nothing. But, to be honest, if it keeps me in a job, then I welcome it ;-)
  8. Re: SOA Approach to Integration[ Go to top ]

    Not sure if you are agreeing with me or not, but to clarify I am saying that SOA is just another term for good design and therefore is effectively useless and means nothing.

    But, to be honest, if it keeps me in a job, then I welcome it ;-)
    And what exactly is 'good design'? When you say SOA is just good design, do you think that people immediately know what you mean? I am getting sick of the silliness around SOA. A lot of people think it's just web services, Managers think it's a magical software product that eliminates the need for skilled people, and then other developers continue to propagate the lie that it has no meaning. It's fine to disagree with SOA and think it's a bad approach but saying that it doesn't mean anything specific is completely false. When you say SOA is just good component design, that means anyone who thinks their design is good can say they are doing SOA. And this is exactly the problem with SOA. Everyone is saying they are doing it and few really know what it is. If you don't know what SOA is, then all that proves is that you don't know what it is. I hate to break this to everyone but just because you don't understand something doesn't mean it's not real.
  9. In fact, SOA is just another word for good component design, and really is nothing new. But that's my view, no doubt others will have a different slant on it.
    I fully disagree with it. My take on SOA is as follows: SOA is about organizing (and exposing) your business logic as modular, reusable, 'loosely coupled services' as opposed to modular, reusable but 'tightly coupled components'. SOA is next generation architecture and an evolution over 'Component Based Architecture' (CBA). Although CBA ushered in good things like modularity and (limited)reusability, it also brought in a few not so good things like tight coupling and lack of interoperability. The problem with CBA, is that, while implementing, it forces you to use 'one' component model of your choice (DCOM, CORBA, EJB, RMI etc) and all these component models are language/platform/vendor dependent in one way or another. The net result of using CBA is that your application components are reusable from 'within' your application but are not reusable from 'other external' applications as those external applications may be running on different platform/language/component model. The key difference between SOA and CBA is that SOA removes this coupling on platform/vendor/language dependencies. Just like how CBA could have been implemented using any component technology like CORBA, DCOM, EJB etc, SOA can be implemented using any set of standards and protocols (web services stack with SOAP, WSDL and HTTP , being an obvious choice) as long as it does not induce dependencies on language, platform, vendor etc. To cut the long story short, SOA is about how your reusable logic is exposed (as services) and not about how it is implemented (may be as some components) while CBA was about both implementing and exposing. -- Pradeep LN
  10. Re: SOA Approach to Integration[ Go to top ]

    Very misleading couple of sentences here.

    SOA cannot be an approach "of any kind" to web services, SOA is not web services, the "S" in SOA stands for "service", not for "web services".
    It is valid to say that SOA is a methodology and when applying it one can choose web services, if a web services implementation is used to achieve SOA then a communication protocol must be used and among options SOAP and REST are popular choices. Even at the communication protocol level I don't see where procedural or object-oriented comes into picture in the two liner comparison.
    Hi Edgardo, I agree with you that SOA is more complex than the technologies it encompasses, and I also agree with James that SOA can be implemented with REST. What I meant was that SOAP-based SOA implementations seem to have more in common with the thinking behind procedural programming, while the RESTful approach seems to be more more object-oriented. SOAP and WSDL put the emphasis on the service interface (which procedures are available), while REST puts the emphasis on resources (which objects are available). The link between procedural/object-oriented programming and SOAP/REST may be tenuous, but I think makes an interesting analogy for a key difference between these two approaches. Ian
  11. Re: SOA Approach to Integration[ Go to top ]

    What I meant was that SOAP-based SOA implementations seem to have more in common with the thinking behind procedural programming, while the RESTful approach seems to be more more object-oriented.

    SOAP and WSDL put the emphasis on the service interface (which procedures are available), while REST puts the emphasis on resources (which objects are available).

    The link between procedural/object-oriented programming and SOAP/REST may be tenuous, but I think makes an interesting analogy for a key difference between these two approaches.
    I don't think that REST or SOAP is more OO than the other. Architecturally, the approaches have only subtle differences. I think people think differently about them which may be what you are pointing to. REST is superior in my mind because it's so much simpler and much more flexible and composable. The weakness that REST has in the SOA space is that it's contracts are too loose and have only ad hoc documentation. While I've never been completely sold on the value of automated service discovery, there's definitely value in contract stability and visibility in the chaotic environments where the SOA approach makes sense. Unfortunately the REST community has an ideological block to addressing this need. What's really perplex is that there's nothing about REST (as described by Fielding) that prevents it from being addressed.
  12. Re: SOA Approach to Integration[ Go to top ]

    I don't think that REST or SOAP is more OO than the other. Architecturally, the approaches have only subtle differences. I think people think differently about them which may be what you are pointing to.

    REST is superior in my mind because it's so much simpler and much more flexible and composable. The weakness that REST has in the SOA space is that it's contracts are too loose and have only ad hoc documentation. While I've never been completely sold on the value of automated service discovery, there's definitely value in contract stability and visibility in the chaotic environments where the SOA approach makes sense.

    Unfortunately the REST community has an ideological block to addressing this need. What's really perplex is that there's nothing about REST (as described by Fielding) that prevents it from being addressed.
    I think if you take REST literally (and most zealots do of course) it is more object oriented when you identify an object with a resource. With this in mind, you can think of an rest environment as a bunch of objects you can send messages to, and my sending around there URLs, you could even send pointer to objects to other objects. So it is very easy to turn a REST environment to be a loosely coupled OO environment. SOAP is more tightly coupled, and using it in a dynamic way is also possible (sending WSDL documents or URLs to them around) of course. But somehow it feels much to clumsy to be used in a really distributed environment. However, as long as there is just one remote object I don't see much difference between REST and SOAP altogether :-). The really interesting thing using REST is being able to change the interface and the data without breaking existing contracts, that can be near impossible with SOAPs encouragement for strong typing once an interface is in place.
  13. Re: SOA Approach to Integration[ Go to top ]

    I think if you take REST literally (and most zealots do of course) it is more object oriented when you identify an object with a resource. With this in mind, you can think of an rest environment as a bunch of objects you can send messages to, and my sending around there URLs, you could even send pointer to objects to other objects. So it is very easy to turn a REST environment to be a loosely coupled OO environment.
    What I mean when I say the difference is subtle is that WSDL/SOAP based services can be structured the same way and, in fact I think they often are. The difference is that the resource comes in the payload instead of in the address. At a low level, there's really no difference because the address is just part of the message being sent by the client. That it represents a resource is something that exists only in our minds. Having said that, people tend to think more procedurally about SOAP/WSDL based services. I think the REST way of thinking is generally better but it's not a difference that's based in the protocol. When you consider something like composition, the REST approach does have distinct advantages, IMO. And if you build SOAP/WSDL services to be primarily resource based, then all the extra layers of fluff are just redundant.
    SOAP is more tightly coupled, and using it in a dynamic way is also possible (sending WSDL documents or URLs to them around) of course. But somehow it feels much to clumsy to be used in a really distributed environment. However, as long as there is just one remote object I don't see much difference between REST and SOAP altogether :-).

    The really interesting thing using REST is being able to change the interface and the data without breaking existing contracts, that can be near impossible with SOAPs encouragement for strong typing once an interface is in place.
    I think versioning of services is something that should be built into any services approach from the very beginning. My experience (SOAP/WSDL and otherwise) tells me that once you publish a contract, you pretty much have to assume that it's there forever. This is one of the things I think SOA gets right: it's contract centric. I don't really see how REST changes this. I think it offers some interesting ways to for versioning but I'm not totally clear how that would work. Do you use something like the mime-type to do this?