thinking-out-loud

Portals on an SOA

This 3 1/2 year-old article at Business Integration Journal predicts the coming of Enterprise Portals and how they'll be built on Service Oriented Architectures. I was surprise that it was written in Jan 2001 because it's more relevant and true today than ever. Recently I posted on the business drivers for SOA. The benefits I listed will be realized via business process automation and management a la tools like BizTalk Server 2004 and, as described in the article, in intranet, extranet, and combined enterprise portals.

Services Partition the Enterprise

I was recently chatting with my good friend and sometimes business partner, Rhett. He and I went to college together. He studied math, I studied physics. Both of us ended up in computers, thanks in large part to our personal desire, another good friend, Russ McClelland, and his introduction to Luke Hohmann, who was working at the time at ObjectSpace in Dallas. We both started on the same day at ObjectSpace. Good times. Good times.

Now.

The other day, he was searching for the name of a mathematical concept. He thought it was a complete covering. I thought MathWorld would be the obvious place to look, but my math chops are far, far too rusty to interpret the closest match they came up.

I did a little digging this morning, and I struck gold with "Set Partition." In math, a set is a collection of things. A set partition is a set of subsets such that none of the subsets overlaps and the union of which is the original set.

Then.

You might be asking yourself --

"Hey, self?"
"You again? What it is!?!"
"Sorry to bother you, but isn't this blog usually about software architecture, service oriented architecture, and bpm related items?"
"Well, yes, but..."
"So, what is with the set partition thing?"
"I don't know, maybe he is trying to draw an analogy?"
"Hmm. Maybe."

I digress.

I was very glad that Rhett brought the idea to mind, because it does provide an analogy for the ideal of service decomposition and rationalization in the enterprise. I believe that service-oriented architecture for the enterprise is a platform for the enterprise's future business process management platform. The business process is comprised of activities that are necessary to acheive the goal of the business process. These activities are a good first pass at scoping a service. The service defines the set of interactions necessary for the singular role involved in the activity to acheive it's subgoal. If two different activities require the same service, then you have an overlapping set, and the service should be partitioned to remove this overlap.
So the principle is:

The collection of services that span the enterprise should be a partitioning set with no overlapping operations.

I liken this principle to the concept of normalization in relational databases. Just as any database design should start off with a well-normalized data design and back down from that to address performance and complexity, enterprises should start with the partitioning set of services as the ideal SOA, and back down from there to address performance, scalability, availability, and so on.

Now.

That being said, reality is going to creep into this idealized world. For one, the data necessary to fullfill a service contract may span multiple applications and data stores, and in fact, may be geographically or temporally separated. You may need this bit of data from that application over there, and the work necessary to rationalize the architecture outweighs the benefit of having such a rationalization [in the near term]. Second, performance and scalability are going to require architectural techniques such as caching, federation, compression, clustering, load-balancing, load-sharing, and so on. These performance optimizations corrupt the ideal, but the evils are necessary. Be pragmatic, and be continuously improving the architecture by working toward the ideal.

As Dave Thomas would probably say, and Thom [or his computer] once said, "Pragmatism, not idealism."

Office Information Bridge, ESOA

Mark Harrison posts about the Microsoft Office Information Bridge, and provides a convenient, one stop location to get the goods (beta, docs, presentations, interview videos, and so on).

The latest version of Microsoft Office creates an excellent story for the information worker, and the Information Bridge builds upon that to enable enterprises to leverage their investment in Service Oriented Architecture.

I will try to publish more as I dig in a bit.

Data Services in SOA?

In my last post on entity aggregation, I commented on some logical inconsistencies in a couple of Clemens Vaster's posts. I decided to hop over there and comment directly to see if I could get some additional information on the notion of data services. I wanted to at least mention the comments here. Also, it is worth noting that the two posts that I am dissecting were written almost a year apart, and the general "caveat lector" notion of blogging surely should apply in that sense.

Entity Aggregation Pattern

Ramkumar Kothandaraman published an article on entity aggregation in the MSDN .NET Architecture Center. Definitely a good read.

Clemens Vasters also has an excellent, detailed post on data services (with pictures!!!) that includes an entity aggregation example. I personally take issue with the notion of data services (whether the service contains business logic is an implementation detail that isn't expressed in the service contract, so the notion seems flawed), and I think there is some logical inconsistencies in his message about data ownership compared to an earlier post of his regarding why he wants wsdl to die, in that a service owning its own data requires more than a single operation to fully manage the lifecycle, which suggests that an autonomous service *has* *to* *have* more than one operation. Despite that, as I said before, he really makes me think about service orientation, so I don't consider this a bad thing. He is one of the few people out there that gives enough substance to differ with, it seems.

OORam revisited

Todd recently posted about OORam. It is a sophisticated modeling technique that deals well with separation of concerns. The process was originally documented in a book that is out of print, but you can obtain an online copy of it directly from the author's website. Note to the downloader: It is a large pdf (400+ pages).

Early in the book, the author discusses the distinction between class and role. There is an interesting excerpt from that section:

In an OOram role model, patterns of interacting objects are abstracted into a corresponding pattern of interacting roles.... The corresponding objects will belong to the same class if they have the same properties; they will belong to different classes if they have different properties. The role model abstraction belongs to the realm of modeling. The class abstraction belongs to the realm of implementation.

This is a distillation of the essence and motivation of Craig Larman's Information Expert Pattern. The information expert pattern states something along the lines of "assign the responsibility to the object that has the most information necessary to solve the problem at the point in time." I had the great fortune to work with Craig at ObjectSpace. We used to teach that the expert pattern was the responsibility assignment pattern of choice 90% of the time. This scales up well to architectural concerns, but that is another discussion.

Craig's book on Object Oriented Analysis and Design is a must read for anyone working with objects, which is practically everyone in software today.

What many people may not realize as being significant about the OORam is that the primary author, Trygve M. H. Reenskaug, not only contributed this great-but-often-overlooked process to the world of software, but he also invented the much referenced, much bastardized Model-View-Controller UI architecture in his early work as one of the designers of Smalltalk. MVC is arguably the most used architectural pattern in existence, the current, impressive real-and-hype wave of SOA notwithstanding.