Sean McGrath on the “fallacy of business objects”


This is an interesting read (by Sean McGrath). I also enjoyed reading one of the references in his article on “Object have failed” by (Richard P. Gabriel).

7 responses to “Sean McGrath on the “fallacy of business objects””

  1. Mark Little
    I remember where *that* is coming from, but there are other comments (not in your blog, so this isn’t aimed at you) that do seem to equate SOA=good and OO=bad, and that SOA will save the day. Get over it! It’s a tool. It isn’t the Second Coming of Christ, or Buddha, or (deity name=”whatever”) 😉 Anyway, as you know I agree with the WSRF=bad. Like I said before, if people want CORBA, then use CORBA. It’s more mature, more stable, and probably perfect for the sorts of things that those arenas require. Don’t pollute the SOA space just ’cause it’s the latest buzzword!
  2. Mark Little
    BTW, I think I broke your blog software. In the last reply, I wanted to say “(deity name=”whatever”)” but use XML syntax. But when I tried, I got a “page not found error” on submission 🙁 It went away when I made the angle brackets ()
  3. Mark, thanks! I know about the issue. I am not encoding the contents appropriately, that’s why. I am fixing it in the next version which is coming up with more functionality. This version of pblog has other problems too 🙁
  4. Mark Little
    You’ve got to make a distinction between the concept of OO (which has existed since the early 60s) and the implementations of it. It’s true that some implementations fall short of the ideal, and marketing people (and universities) have a lot to answer for in encouraging one style/implementation over all else 🙁 It’s also not true to say that interface changes can’t be handled by systems: CORBA can do it and the old saying about “another level of indirection” helps. A lot of problems come back to principles versus practice. This equation (that you seem to like) of “OO==bad and SOA==good” is not founded on anything solid. Let’s use the right tool for the right job! Java (as an example) shouldn’t be used for everything, and where it is it fails and tends to result in “Java==bad”. But you try using COBOL in the same places and you’ll find a different subset of places it isn’t appropriate for. Does this mean that “COBOL==bad”? Yes, but only if you don’t give the full equation of “COBOL==bad caveat=in these situations” (Hmmm, maybe I shouldn’t have used the equation analogy 😉 There are cases where OO works really well. Likewise there are cases where it doesn’t. The same can be said of SOA (whatever the underlying implementation, which could be based on CORBA, for example). It’s another style for architecting solutions to a particular problem, just as OO is, just as procedural programming is, just as prolog is for functional programming (you get the idea). It’s not a global panacea. Let’s not get back into the hype we had with Java!
  5. Mark, I agree with everything you said. That’s my position as well. I will only disagree with your statement that I dislike OO. On the contrary. I really really like OO and I am using an OO programming language for all the code I do and for implementing my Web Services. What I don’t like is the application of OO concepts where SOA is more appropriate. Yes, use the right tool for the right job. It is definitely true that you can build service-oriented applications using CORBA. You can even do functional programming using C++ or object-orientation using C.
  6. Mark Little
    OK, then we’re in agreement then. If you (and I mean “anyone”, not you personally) want to use OO concepts in the Web, then use CORBA. It works across firewalls these days, so that old sticking point isn’t there. I would add, however, that if you want to do SOA, then you could also use CORBA. It just may not be as cross-platform as you might achieve using, say, XML and SOAP-over-HTTP.
  7. Yes, we are in full agreement. You have to remember how everything started. It was because of OGSI and now WSRF. I see them as an attempt to implement some (if not all) of the OO concepts using angle brackets (lifetime, references to objects, coupling of object intetity with object naming, properties, etc.).