SOA from the trenches (part 2): SOA vs. Object Orientation
When I'm presenting my SOA thoughts to a developer/architect audience,
I often get the comment: "Been there, done that. We're using
encapsulation, interfaces, component based development with OO
programming for years now. What makes SOA different and why should we
give it a try?"
This is a valid question, since the principles of modularity,
encapsulation, distinction between interface and implementation,
information hiding, etc. hold both for SOA and OO. But in my opinion
there are some differentiators:
Granularity
The granularity comes to mind first. SOA is built with coarse-grained services respectively coarse-grained service interfaces and the services hold a self-contained business function. As a result from OOA&OOD OO systems tend to be very fine-grained.Complexity
OO systems tend to be complex - not to say overly complex. Large systems are very often big lumps of software with high coopling instead of being modular. The use of inheritance and design patterns complicates things even more. Would you prefer to work with 50 reusable services or 10.000 reusable classes?Distinction between Process, Rules and Data
In OOA&OOD you create classes, that have attributes and operations - and these classes have a behavior. Classes in OO systems may hold process flow, business rules and data - sometimes they hold all at once. As a result business logic in OO systems is scattered between different classes and hard to comprehend and (more important) hard to change. In SOA you typically make a clear distinction on which systems keep process flowing, you fomulate explicit business rules and separate systems may be responsible for the data. And yes, we're stepping back to a procedural model with SOA. End users don't see their business in an object oriented way. What they are working with is a business process, or should I say with a business procedure?Reuse
Have you ever used business classes someone else has written? Probably you have used the classes of a team mate. But you probably have never used any business relevant classes from a different project - at least I never have. There seems to be a kind of natural resistance of developers against that kind of inter project reuse with OO systems. You probably have been making use of frameworks and third party libraries and that is what you do within an SOA. You reuse black box components (i.e. services not classes).There are more differences (like distribution of artifacts, transactionality), but these are some of the most important. Service-orientation doesn't replace Object-orientation, both complement each other. The best way to create services is still by using OO languages and systems.
Posted at 10:06AM Mrz 28, 2007 by Armin Wallrab in Java | Kommentare[0]