Leading Microsoft architect Don Box said the world of service-oriented architectures (SOA) will eclipse object-oriented programming. According to Box, "Objects are great; they're based on trying to put as much of the programmer's thinking into the code" as possible, whereas with SOA "all this stuff shifts the focus from types and abstractions to contracts and schemas".

Don Box says SOA paradigms will eclipse OO programming.

What do you guys think about this?

I suppose that by 'ecplise' he means shifts in focus, not a technology displacement, as in the end objects are still a viable implementation technique for any service.

Playing devils advocate for a moment, I heard a vendor friend once say that it's in Microsoft's interest for people to shift focus on services or on the interoperabilty, as then the choice of implementation platform will become less important, which would remove the media's emphasis on J2EE leadership.

it's in Microsoft's interest for people to shift focus on services or on the interoperabilty, as then the choice of implementation platform will become less important

That sounds like a bit of a stretch. That philosophy works when you are writing services from scratch. But most of us at the enterprise level are enlisting previously-existing assets into an SOA. If those assets operate in a heterogeneous (or non-Windows) environment, then J2EE maintains its advantages over .NET.

I know it is more buzz-word compliant to say SOA as opposed to RPC. So, thinking of services in terms of discrete units of work that provide value encapsulated into a well known contract is probably more buzz-word compliant than thinking of them merely as components with standard-based APIs.

But really, is this evolution or a repackaging of components vs. objects?

Russ

Its funny,

But to me SOAs are nothing new. Anybody remember Orfali-Harkley's Martian books on CORBA and the "Object Bus"? SOA using Web Services finally managed to do what CORBA failed to, provide a vendor/technology-neutral mechanism for describing, finding and invoking coarse-grained services.

In the end, SOA and objects compliment each other. Services exposed through an SOA expose a coarse-grained business process (addOrder, reduceInventory). However, the actual implementation of the service is still going to need the finer-grained model provided by an OO-based implementation. Otherwise you end with "fat" web services. (Just when we were starting to get our EJBs on a diet :) )

I always get nervouse when bold statements are made about revolutionizing the way code is written.

      - John Carnell

I new around here and have been doing OOP for about 3 years. Please enlighten me how can you have SOA without OO programming. Isn't OOP what you would use as building blocks for SOA.

If this is the case, I think that the only reason for this artical is so this guy can 1)Convice people to buy his book, 2) Take a cheap shot at non-MS Solutions, 3) Part of a last ditch effort to get managment to look at MS products and solutions vs solutions that are more "Open"

- Rob Potts

<quote>
Objects are to services what ICs [integrated circuits] are to devices
</quote>

Web services are the building blocks of a service oriented architecture and they can be built in any language (Perl for instance).

Don Box is a Microsoft advocate and whatever the marketing dept. says, Don Box says.

SOA is nothing else than an emphasize on the systems' "exposed" interfaces. This has nothing to do with eclipsing OO. SOA's can be built in assembler, structured languages, OO-languages, functional languages and any platform. It is simply an abstraction which is orthogonal to all these things.

Some people would even call it a pattern ;-)

>

Don is actually an advocate of the stuff him and his team create... Hard not to advocate your own work, don't you think...

a.

A service is a remote function.

In the beginning there were services (functions, routines).
Than came objects. You need an object when you
have tightly correlated services that manipulate some
state: the object represents this state.

when we will need to model the state services
act upon, we will come back to objects.

I would like to add something.

Objects are used to model the domain an
application is about. But objects are completely
useless without the notion of controller.
In fact who invokes the object. In the end
the will be some data coming from a network card,
a mouse, a keyboard, that are targeted to your object.
The controller is something the bridges the gap between
two sematically separated layers, that translates (lifts) lower
level data to the semantic level of the application.

Now you can go to sleep.

Don Box is right.

~C

Box is smoking bananna peels.

His views of how the global exchange of symbols via the internet is to transpire is incredibly impractical.

The average business Joe - the non computer, but very business savy client - will be looking for a system that, in its implementation, resembles a traditional language (English, for instance). When a system interaction can be put into a sentence by introspecting on the invocation flow that closely resembles the grammar of a natural linguistic sentence, the system has a much better chance of surviving and thriving.

This push by so many technical cultures to implement some sort of intrinsically perfect klingon liquid data implementation is ludicrous and impractical.

Just my two cents.

Best,

John C. Dale

Ah yes, the 'klingon, liquid data'.

+ 1
.V

You have described Data Structures. They are not objects in the sence of OO paradigm.

Are "controller"s objects? Can objects be controllers?
Are you talking about "object" as in English dictionary? or like a programmer?
or as in the book "A theory of Objects"?

Services can be implemented without understanding OOP concepts: True - but modifying a given service is not without risk to dependent applications or process. Understanding OOP concepts will take you a long way in building dependable services. Example: Changing the implementation without modifying existing interface or method signature.

Maybe he was misquoted or just fat-fingered his responses.

What about Dom? Can't a serialized XML structure be considered an Object?

Object Oriented, to me, is to appropriately (read as cohesively) name some state, associate some behavior with that state, and make a software map of some external-world system or event.

Any useful software model/implementation is OO.

On the surface, it seems like quite a rediculous statement - OO will be repolaced by SOA - as any software systematicity by its very nature models some real world concept whether it comes in a nice package or not.

Do Polymorphism and Inheritance go away? How? Aren't these useful techniques in implementing some SOA?

I think somebody's out to lunch, and it's not Darren from the Subway commercials.

We'll use OOP to implement services. But the real work from than on will be done with services, which better simulate reality.
"I use a bus which comes about each 5 minutes, and i pay this much each time". This is SOA, not OOP.

The bus object (the real metal one) stores passengers, and gasoline, and oil, and has a motor, and has various methods like 'drive()' and 'turn()' and 'addPassenger()' and 'removePassenger()' and isan Automobile.

You have it right from the client perspective. I need to know where the bus is (maybe I can call a bus factory?), when it arrives, how much I need to pay, and where it is going.

I fail to see how your analogy doesn't break down.

Best,

John C. Dale

<quote>
The bus object (the real metal one) stores passengers, and gasoline, and oil, and has a motor, and has various methods like 'drive()' and 'turn()' and 'addPassenger()' and 'removePassenger()' and isan Automobile.
</quote>
Exactly. As I said, services will be built using AOP and other services. But at a high enough level, services are used, not built.

Try getting on a bus and saying to the driver "addPassenger(this)" and see what happens. I did, and he threw a StupidPassengerException (and then he threw me off the bus).

>> I fail to see how your analogy doesn't break down.

If you're talking about London buses then they break down all the time. So I suppose that it is a good analogy for some of the software systems I've worked on.

You are right. In the technical sense, the statement is ridiculous. However, software marketers are forever spinning out new terms to repackage existing concepts in their attempt to generate market excitement. So yeah, the SOA buzzword will eclipse the OO buzzword and Component buzzword on magazine covers, analyst reports and in job adds. If you have built a distributed OO system that performs well and scales, take a minute to think about how you did it, then add SOA to your resume and call it a day. I am waiting for someone to create an algebra for services and inadvertantly rediscover functional decomposition.

Does he mean Distributed Objects? Because lat time I checked, SOA is based on the Interface. Web Services does nothing but address how application interface with each other?? How is SOA applications going to replace the implementation? I mean, I expose Java Objects or C# Objects as a web service. How I access it is SOA minded, how I implemented are objects. Saying something like Aspects might make more sense (not that I am saying Aspects will replace OO, but from a comparison point of view).

Microsoft focuses on the interface because the serverside implementation has never been that strong. MS has always had strong client tooling and runtime support, but I think the objective is to push focus to the strength they feel they have in their products rather than people looking at the weakness in the product.

It's a bit different. Services are analogous to RPC via UDP/IP while objects are analogous to RPC via TCP/IP. For RPC via UDP/IP, you simply send a message.

The advantage of this approach is that you don't have to wait for a reply and the message doesn't have to be handled right away. It's also very easy to serialize messages so they could be replied at any moment of time. It's often possible to create a broadcast bus without resorting to the less scalable publish subscribe pattern. The down side is that you don't know if the message arrived or is being executed now. You also don't have transactions or context (although it is often possible to kludge those via session ids) or return values from the message.

For RPC via TCP/IP, you have to open a connection, send the message, and close the connection. The advantage of this approach is that your message is guarenteed to be recieved (or the connection will tell you if there is a failures). Maintaining sessions is also easy. The down side is that small one-time messages carry a heavy connection overhead, you can't broadcast without resorting to client polling or the publish subscribe pattern.

So the SOP versus OOP "war" is not really new and there are advantages and disadvantages to each so neither will die out. Currently SOAP and RPC-XML are more portable than regular RCP wire protocol or RMI/CORBA wire protocol, but it's only a matter of time before RMI/CORBA are implement on top of SOAP and RPC-XML if for no other reason than to quiet the "SOAP is the one true way" critics.

When I am asking for distributed object, I meant to say he was not comparing the right things. I disagree what you say about TCP. Services can be synchronous or asynchronous. I do not see how SOA mandates one way communication as you are trying to eluse to with your UDP example. To me SOA repesents services that are described by a technology such as WSDL and can use any protocol. They can be stored in a repository like UDDI/ebXML. Nothing to do with TCP/UDP comparison.

To be fair to Don Box, he does say that OO will by done in the background behind the SOA. And in the realm of distributed computing, I think he is right: I see the industry moving to more interoperable XML-based services to manage machine-to-machine interactions.

But that is only distributed computing. There are still going to be *huge* number of single-machine applications, and all of those will be (or should be) OO. This will include all the internal logic for the SOA. These single-machine processing is where all the gory logic will be. In the end, the SOA will be very easy, maybe even automatically generated, and all hard programming work will still be done the way it is now.

I think in the long run AOP will be a bigger paradigm shift then SOA, which is really something old (RPC) repackaged in a new format (XML-based messages).

I seem to remember when J2EE was touted as being coarse-grained. I reckon that SOA will simply be leveraged into equally complex applications. Todays contracts and schemas become tomorrow's types and abstractions. It's all just oil under the fingernails.

How can such a thing be even considered anything other than empty marketing talk and hype : it's almost like saying rpc and procedural language are superior to corba and OO language : there are some very strong reasons OO technologies where required in the the late 70s.

Anyway any good distributed OO architecture is based on coarse grained granularity on the boundaries (services, nothing new here), based on middle grained granularity entities : the components, which are themselves built using fine grained granularity entities : the objects.

In my opinion it's far more important for us to shift focus from synchronous architecture to asynchronous (possibly document based) architecture (loose coupling is very very important in distributed system and so far microsoft technologies is only focused on synchronous middleware).

web services base technologies are badly designed : willing to address everything they failed to do even one thing right (to be useful, the soap stuff needs security, tx, orchestration and it's internals are even now highly over complicated, the web services async stuff is a joke so far).

Too bad we always hear more marketing talks (the silver bullet product shows again) than talks based on experience (bad or good) in period of economical slowdown.

PS : I do agree that AOP will have a major impact on the way we design distributed systems, it complements quite nicely the OO paradigm (they seem quite orthogonal).

+1

I wonder how an interrogation protocol can be compared with a Development Methodology!!

Sorry! interrogation/integration

Hmmm, looks like the marketspeak of choice now is "Service Oriented Architecture", say goodbye to the oft abused term "web services".

'Box said unlike objects, services try to introduce very few abstractions. Services assume a minimal stable and shared kernel, "and in the world of Web services, that's XML 1.0, HTTP and SOAP," he said. In addition, service orientation assumes high-latency, low-fidelity connectivity; services composed of coarse-grained message boundaries; and services that share schemas and contracts but not types, he said.'

Um, if you really wanted to go minimal, then what's SOAP got to do with anything?

On the same line of thought, what does WSDL have to doing with anything? Doesn't it compile directly to a type?

All one truly needs is REST, XML and Schemas. Everything else seems to look like fluff.

One more article like this, and I'm gonna wash his mouth with SOAP!

It seems to me that Bob is schizoprhenic. Here he is a MS architect, and he's basically contradicting the entire .Net philosophy. Isn't .Net one huge abstraction, ADO.Net is an abstraction of the data layer, the .Net libraries are an abstraction of the OS. The CLR is an abstraction of the various programming languages?

It seems to me that putting lipstick (web services) on a pig (procedural code) doesn't make the pig any more attractive. If you have monolithic code then putting a web service interface on it still leaves you with large problems. Those of maintaining the code and that holy grail of software OO/Component re-use. Services just lower the cost (time to implement) of software to software transactions. They don't address the other software problems of design,maintenance and re-use.

Client-Supplier contracts (that of pre,post-conditions and invariants) that guarantee the black box component/OO approach are a hugeley important aspect of modern programming. Services though are just a lightweight implementation of an interface, nothing more.

I think a lot of people may actually be missing Don's point.

I have seen the talk that's being described here and it's not about MS v Sun or any other religious war you could imagine, but instead about architecting and designing resilient, manageable and *interoperable* systems.

SOA is not about replacing OOP, but rather architecting solutions so that pieces of your code (and their associated data) are isolated and can be changed and implemented in different ways without effecting the rest of your application.

I'm sure even Java guys would see the benefit of such architectures if they got over the fact that it was presented by an MS-guy (who incidentally, has also been a Java-advocate in the past)...

<quote>
SOA is not about replacing OOP, but rather
>>> architecting solutions so that pieces of your code (and their associated data) are isolated and can be changed and implemented in different ways without effecting the rest of your application. <</quote>

I remember seeing exactly the same text somewhere... Where was it? Oh yeah, in an OO book. In fact, isn't this the exact rationale behind OO?

Could it be that SOA is another way to implement the abstractions, tiers vs. layers, that kind of thing? That SOA is essentially OO used differently to satisfy different needs and requirements?

Nah, that would be too obvious...

I think it's reasonable to say that the focus for a lot of valueable work in IT will be at the integration layer, whether that's A2A or B2B and that the service paradigm will be extremely important independent of the implementation strategy of the service. Certainly the distributed object paradigm will be eclipsed by a service paradigm.

Greg

Well its an abstraction thats for sure, but SOA is not OO. SOA is about messaging, describing messages and services but never mentioning implementation, very loosely coupled. Specific implementations/languages/platforms can map their own types to the definitions in the description of that service but they do not need to.

Commercial talk driven by marketing purpose of Microsoft.
SOA if there is such an idiom, cannot be compared with OO. Different concept, different context, different graluarity, just different...

One thing might be true, separate roles of an SOA architect and OO architect might need to be distinguished clearly (while currently these two are typically confused into one)

Box seems to assume that every computing problem can be boiled down to a set of cooperating services. For starters: I don't think so. It's very early in the
game, but it seems to me SOA has less to do with how code is built than how data and logic are distributed using that code.

The history of computing suggests that each 'innovation' (a word MS has commandeered and seems to think it owns) is built on the shoulders of what has come before it. If you want a service, you have to build it with something. At the very least, OO will be put to good use building SOA's. OO may be subsumed but not replaced by SOA. One is the building block for the other.

In the end, this kind of prognostication sounds more self-serving than visionary. But he may be correct in one perspective: the hype surrounding SOA certainly HAS eclipsed the staid and proven results that OO provides.

Some of you should read this article by Werner Vogels titled "Web Services are NOT Distributed Objects: Common Misconceptions about Service Oriented Architectures". It has been discussed at many places on the web in the past days; it clears up a lot of the myths that some particpants in this discussion still see as true:

http://weblogs.cs.cornell.edu/AllThingsDistributed/Archives/000120.html

Sorry, the link to the article is : http://weblogs.cs.cornell.edu/AllThingsDistributed/Archives/000120.html

thanks for the link to the vogels article, I have a lot of respect for the Cornell folks (i used to be an active member of the dist-obj mailing list).

JXTA is better then .NET.

The future is being invented by kids still in college - not gray-beards like Don Box. Too bad Microsoft can't figure this out. They don't even know who to rip-off right now - they already have ripped off all the good ideas. Don hasn't had anything interesting to say since his most excellant 'Essential COM'. Dons vision on web services is short sighted. What about P2P web-services. What about implementing every Gang Of Four DP but with interacting Web Services. What about Observer web services - what about web services that filter out the results of other web services, that decorate other web services. Don't let Don tell you about the future. GO Make it. No wonder the e-conomy sucks.

Don, a grey beard? LOL.

Don's easily one of the brightest minds in software today, especially in terms of being able to grasp a paradigm in its totality and being able to explain it. You kind of have to be able to learn his means of communicating - his books can be hard to parse through - but once you have, it's usually a treasure of insights.

In this article, he's pushing the same line that the "component software" guys like Brad Cox have been pushing for over a decade. Right there he's giving away his hand: SOA is not anything revolutionary, it's merely the same old component based development on top of a new technology kernel (SOAP, HTTP, XML).

His view of OO is also somewhat unique because of years of arguments about whether COM is "truly" OO. For years people said it wasn't because it didn't have inheritance. Now with all of the AOP and modern design techniques, most realize that polymorphism was the "real deal" and inheritance wasn't as big a deal. It's funny how things work out. I get the impression that Don is pointing to a version of OO that already is culturally extinct.

Don does get a little bit ahead of himself sometimes with how excited he gets about XML. It's important to understand the perspective he's coming from when you read stuff like this, as he's been saying this kind of thing for over 2 years now (anybody remember the last eWeek quip suggesting that we have to move away from HTTP?) Don's a provocateur, he does this stuff to shake people out of their stasis. That doesn't mean he's always correct.

For example, at a tutorial at OOPSLA 2001, he mentioned that "objects were great back in the 1980's" and proceeded to suggest that all distributed processing could be done by XSLT transformations or some sort of XML Post-Validation Schema Infoset compliant language. A lot of people are opposed to this idea (just read the XML-DEV and SOAP mailinglists out there), but he was suggesting it was fait accompli. Microsoft's rumoured X# will probably be an attempt at this kind of paradigm. It will be interesting to see what they come out with, I think the idea has merit, but I'm skeptical.

Another suggestion he made was that there are effectively two distributed systems stacks in use today: the network component network stack (COM, CORBA, EJB) and the web server stack (HTTP, XML, SOAP). He went on to suggest that if all of the world's EJB systems died, it would only cause a few guys "a weekend worth of work" to fix it, because 99% of EJB projects never make it to production anyway. The web, on the other hand, could not go down.

Now, I get the point here: the web is much bigger than EJB ever could be. But I know for a fact that if EJB all of a sudden "died" everywhere, then almost half (or more!) of the world's equitiy, fixed income, and derivatives trading systems would cease to function, and it would be months to swap architectures.

He really seems to believe that it won't be a tremendous paradigm shift for developers to move away from the "network component" model of old to the "network service" of new.

Well, he's right, and he's wrong. XML Web Services and SOA probably will make traditional component-based development irrelevant, if there really were any life left in them. EJB, CORBA, and COM are really no longer relevant - they're way too complicated at the "core kernel" level (which is DCE RPC/CDR and CORBA/IIOP), and don't add much value above what you will be able to do with the WS-* and W3C specifications. But it will take a long time to migrate people off of it, and for products to mature into these new specifications. And, the specifications don't add a tremendous amount of novelty over component based approaches. They change the core kernel, but the higher-level features are very similar.

So, will SOA defeat OO? I think not. It's a red-herring. OO is a "programming in the small" construct that has over 30 years of history behind it. SOA is a "programming in the large" construct that replaces prior constructs such as "distributed objects" and "component-oriented architectures" that took their cues from OO programming. And SOA has to be programming in the large because of the fundamental problems inherent in distributed computing: partial failure, latency, non-uniform memory access, and concurrency. These are "big" issues, not something one deals with at the "micro" level. SOA at the "micro" level is nothing more than traditional modular library development.

He seems to be suggesting that most programmers will be programming at the "SOA wiring" level and that the real problem is that too many people are building "software ICs". This is wrong-headed. The problem is twofold: reuse is hard, and distributed computing is hard. There are a lot more problems in that space that still haven't satisfactorily been resolved. I still think it's much cheaper to build software that relies on people to build these OO "software ICs" than it does to put together a distributed system out of reusable services.

The underlying protocols don't change that reality, it's that we haven't developed enough education in the software development community at large to all become distributed systems programmers. I see way too many systems that are "distributed by skill set", one component in CORBA, one in EJB, one in .NET, all talking to each other through MOM or CORBA or XML, but with no performance or scalability. That's the world we're entering with this relentless hype about web services: an SOA version of the "world wide wait".

Finally, Don goes on to say: "all this stuff shifts the focus from types and abstractions to contracts and schemas". This is a meaningless statement.

Let's do a Merriam Webster look up, shall we?

Type: qualities common to a number of individuals that distinguish them as an identifiable class

Abstraction: expressing a quality apart from an object

Schema: a mental codification of experience that includes a particular organized way of perceiving cognitively and responding to a complex situation or set of stimuli

Contract: a binding agreement between two or more persons or parties

Type = Schema = Abstraction. They're the same thing. And we all know that contracts exist in OO and design-by-contract was popularized by Bertrand Meyer.

So. SOA is good, but it takes a lot of ideas from component based software, which in turn took a lot of ideas from OO. I think it's a red herring to say it's going to defeat "OO" in the same way that AOP is going to defeat OO, or components were going to. We're just evolving the way we do things. We're paying an homage to the past, in my opinion. The only thing that will "defeat" OO would be a paradigm we haven't seen yet (like what OO was in the early 1970's.)

Objects and Web Services
Remember that OO design always starts at the Conceptual Level [Don is a nuts and bolts guy]. Its nice to know that guys like Don have figured out all the goopy stuff, but we need to look at the big picture.
Currently there are embryonic web services at work. One is RSS. RSS is kind of ho-hum but is giving the community a chance to work with XML and sharpen thier tools for the future. RSS can be collected, consumed, sifted, filtered.
 
So I open up a Web Service start-up. Clients register for data mined from the web, which is acquired from RSS feeds. As the Clients get data, they shift focus or adjust their query.
These are all things we want to analyse at the Object level. Publisher-Subscriber relationships - even if we Publish via email. Who cares about the medium, well Don does and thats why we have Don. But the community has to figure out the application of the technology. This all the stuff we have been doing all along, instead of a Registry we have WSDL, thats all.

I guess Web Services has to go through a functional programming phase, in which the services are like libraries. But ultimately Web Services will be Objects - interacting, fire messages to each other - I can't wait.

I shouldn't be so hard on Don.
I agree with him but find his discussion a little short-sighted. It is hard to get excited about Web Services when they are reduced to the simple aquisition of data across a network, which has been encoded in XML.
Perhaps this is why Web Services are NOT proliferating. Explain Web Services to the 55 year-old IT manager and watch him shrug his shoulders or yawn. Why should he expose data to the internet? Is someone going to pay for it? <laughs> Is it just one more channel for hackers and the like. <yes>