SOA and OO

  • Article

 Finally, I am back from a long vacation/business trips. Happy to be blogging again.

 

Recently, some heated discussions are going on around the subject of SOA and OO. There are different schools of thoughts about this subject. Here is few of those

 

  1. SOA will make OO obsolete/redundant.
  2. SOA is just a marketing hype where as OO is real thing
  3. SOA and OO can peacefully co-exist

 

I subscribe to peaceful co-existence of SOA and OO. Both SOA and OO has their sweet spots. Both define a set of abstractions that can be used to solve a particular problem. It is really up to designers/architects to use the right abstractions to solve the problem at hand.

 

It is a well known fact that abstractions are useful in managing complexity and building an application that can be manageable etc. There can be multiple levels of abstractions. Lower levels of abstractions can be considered as 'details' or 'implementation details' of higher level.

 

The issue is: if you pick the wrong abstraction level as the top level abstraction, you will get into serious mess later on in the project. For the purpose of this discussion, let us call the top level abstraction as 'First class' abstractions.

 

Let's get back to OO. OO has its roots in real-time systems where the concepts of objects, encapsulation etc made real sense. These concepts are at the core of those systems and hence they fit the bill of Top level abstraction. Sure enough, you may need domain specific abstractions etc on top of the top level abstractions. Let's leave the domain specific abstractions out of this discussion for now.

 

But, somehow, we generalized this and thought that OO can be used as 'First class' abstractions for building any software application. In my opinion, this is where we went wrong. OO is definitely not the top level abstraction for building business applications. OO appears in second or lower levels of abstractions.

 

To illustrate this idea, let's take the example of compiler. The first class abstractions required to build a compiler are: lexical analysis (tokenizer), syntactic analysis (Parser), AST, semantic analysis, back-end concepts(optimizer, code gen etc). Once you understand the top level abstractions and associated formalisms (like regular expressions, LALR Grammars etc), then you can choose the right implementation based on your project constraints. If you take parser as an example, you can either hand-write the parser using OO or you can write the grammar using LALR(x) syntax to generate code using tools such as yacc or bison or whatever.

 

Same holds good for database implementations. First class abstractions in the database are defined by relational calculus. The abstractions are Relations, relational operators, relational query etc. Each operator (like Join for example) can be implemented using many different mechanisms or algorithms (such as Hash join, nested loop join etc). Finally, a developer may choose to implement an algorithm using OO. So, in this case OO appears at third level of abstraction.

 

Let's turn our focus on business applications.

 

First class abstractions required to build business applications

Following are the top level abstractions required to build business app

 

  • Business concepts such as customer, employee etc.
  • Business rules - Structural, Validation, Policy etc.
  • Business process: both with in and between systems
  • Human workflow: How do tasks flow between different actors?
  • Presentation Layer
    • UI Process - Ability to define user activity flow

 

There may be few more. But, these are the things that developers should think about when building business applications as these abstractions map directly to business requirements. SOA defines additional abstractions on top of these. It includes

 

  • Service boundary
  • Service contracts (Service definitions)
  • Service Agents

 

At this point, some may argue that OO is absolutely required to implement any of these abstractions. I dispute that too. For example, there are many different ways to implement business rules.  One such implementation is forward chaining/backward chaining algorithms used in AI. In fact, this is a preferred and elegant way to implement business rules than its OO counterpart (recently some one mentioned about the AOP way of implementing business rules).

 

Today, Microsoft already has modeling tools that support few such abstractions such as Business process (Biztalk orchestration) and Business rules (Business Rules Engine/Designer). In future, Whitehorse - modeling tool that will be shipped with VS.NET, will surface all the above mentioned first class abstractions to developers and architects alike and generate appropriate code.

 

Note: Speaking of modeling, I don't think UML is adequate to express first class abstractions. The reason is this. UML defines a set of fixed models (like class diagrams, sequence, activity, state etc) and a limited extension mechanism (such as stereotyping etc). Now to model first class abstractions for compiler such as Lex analyser or parser, one has to use one of the static models to express these concepts. It is like you are starting from implementation (like class diagrams) and going up the abstraction level (like stereotyping) to define the higher level abstractions. I believe, that is not the optimal way to do things. In essence, premise behind UML is that any model can be reduced or derived from the set of core models UML provides. I think this approach will not work and that's precisely the reason, folks are finding UML so difficult to use in practical scenarios.