DISQUS

DISQUS Hello! Thinking inside a bigger box is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Thinking inside a bigger box

Jump to original thread »
Author

Four bold claims about SOA

Started by jhannes · 10 months ago

Two of the hardest problems of software development are integration and what we could call business-IT alignment: The whole organization working towards the same goal.
SOA claims to address both of these problems. After listening harder than I’ve ever done before to SOA evangelists%2 ... Continue reading »

7 comments

  • Marcus Ahnve

    1 year ago

    Brilliant - one of the best pieces I have read on SOA.
    reply
  • Johannes Brodwall

    1 year ago

    Geir Hedemark points out another thing that I didn't really think of about BPM: If you expose and reuse your services (Use Case steps, remember?), you can no longer change these. So your "flexible" processes may be composed of "frozen" steps.
    reply
  • Geir Hedemark

    1 year ago

    Good post, Johannes, and thanks for the kind words.

    I have a slightly more positive view on SOA than you do, especially when it comes to ESBs, and if you have chosen to stay clear of the "SOA is WS-*" crowd.

    Some tasks out there are by nature sequential and/or asynchronous. You can take a big hammer and force these things into a synchronous, object-oriented way of developing, but the mismatch between what you are solving and the tools you are using to create a solution will cause pain. I think that pain may very often be larger than using an ESB. In these cases, I think an ESB is a very good option.
    reply
  • Johannes Brodwall

    1 year ago

    Hi, Geir

    Do you mean ESBs or BPM? I thought BPM was what people used to deal with events?

    Personally, I've never found a conflict between object orientation and event driven applications. I would love to hear a bit of elaboration on this.
    reply
  • Geir Hedemark

    1 year ago

    I mean ESBs, but explained myself very badly.

    For me, SOA is a quite amorphous term. What I tried to say was that I like the idea of being able to use an ESB for tasks that are asynchronous in nature - stuff like EDIFACT-like messages flowing through your system.

    I have seen people try to use servlets for handling message-based problems. I don't think servlets are very well suited to publish-consume style tasks. Have a look at JSR 32 if you are wondering what I am on about - this is the servlet API applied to asynchronous messaging.

    I have also been subjected to opinions that ended up as "we only need ESBs" in my head. I may be to blame here. though. ESBs are not a very good environment to implement request-response style applications - the technology tends to get in the way. We have servlets to do that kind of stuff.

    There is also a possible mismatch between a rich domain model - where the subclasses has behaviour - and a message-based paradigm, where the intelligence sits in transformers along the path of the messages. I keep feeling that the messages are anemic domain objects getting passed around between transaction scripts, but I am also confident I need to move carefully here, lest I start a holy war. You can move to a rich domain model within the services/transformers themselves, but the technologies I have been using seem to get in the way of doing this - I tend to spend most of my time copying object contents if I force the information into a domain model.There may be something I don't see, though.

    I really, really want some way of bolting behaviour to the side of a data carrier without having to write boilerplate code. Qi4j or annotations would work, but nobody seems to know these technologies out there yet, so I tend to try not to use them in projects.

    Hope this helps.
    reply
  • Lars Arne Skår

    1 year ago

    I think you hit the spot about popular claims. In addition, myself and others throw in a claim that this SOA-fad also put an emphasis on semantic interoperability as well as the technical interoperability; i.e. we often times get into an argument "what is a good service". A similar claim was given with OO-fad ("What is good object"). For some reason still does not get that wide attention. Maybe because the technical stuff is easier to disagree/agree on.

    Of these claim, I have to admit it is the 2. one I have the most faith in at the moment. The WS-* gang went into the same trap as the Corba-gang did with to much focus on solving all possible techical interoperability challenges which in turn created tight coupling in practice which again violated the originial intention. The WS-thing was so much easier to deal with when it was only XML and HTTP. Maybe that is the reason why REST is getting so popular these days.

    Many smart people claim that REST is insufficient for "real stuff"; in particular vendors of tools supporting SOAP and the other WS-* stuff. However, we are clearly observing that the use of REST tend to be much more dynamic and agile in "real life" than these "ultra-flexible" and "ultra-powerful" standardized WS-stuff.

    The usefulness of the BPM stuff is greatly overrated to say the least - at least at the current state. In many ways it resembles the state of the case tools we had in the 80s and the 90s. Still, I like to live in the hope that one day this could be really useful; the fact that BPEL is being used and getting some support - even outside of the vendors providing tools for BPEL show some promise. BPEL doesn't solve everything, but being fairly simple and "low-key" is in my mind a good thing. Maybe it should be kept that way.

    Getting back to claim nr. 2, I am in much favour of the view that a service bus is no more than a "galvanic divider" between a service provider and a service requestor, and in some circumstances this gives value; i.e. when you want loose coupling between systems. The reason why there is issues with this claim, is all the other stuff vendors put in the ESB. They create ambiguity in where to put stuff, and also introduces yet another operational complexity which again also gives even more deployment complexity which is hard enough as it is.

    My faith lies on the open source movement and that the vendors will react constructively to what is usually called light weight ESB which again may lead to more practically oriented ESBs. Similar things did happen to J2EE/Java EE with Spring and some important adjustments to the EJB spec in EJB 3.0. While not being perfect yet - the movement seems to be healthy.

    - My reaction to this very insightful blog. Thanks!
    reply
  • Johannes Brodwall

    1 year ago

    Both Geir and Lars Arne seems to have more insight into the use of ESBs than me.

    Personally, I have never seem the problem that Geir is describing with using OO in an event driven world. Granted, I have never perceived this to be a major source of problems, but I end up translating events (usually incoming documents) to "command objects" which update the state of the object model. I've never missed an ESB when doing this. What am I misunderstanding?

    Lars Arne's "galvanic divider" is closer to things I have encountered. But in my cases the "galvanic divider" became just another layer of crud on top of many more layers of crud. As I understand it, this view of ESBs would either mean that you have to have a generic representation of any message type or you need to have individual representations for different messages. If you go for the first option, you're screwed, as most people who've tried know. If you go for the second option, don't you just add another layer of complexity with no corresponding value, as the new representation will have to match the old one, anyway?

    Maybe it would be clearer to me if I saw the ESB tool you guys use.
    reply

Add New Comment

Returning? Login