Andreas S.T. Brunvoll - WebLog

Leaving Microsoft

abrunvol — Thu, 16 Dec 2004 09:27:00 GMT

After three years I am leaving Microsoft to become the architect of Norways largest hospital, Ullevål Universitetssykehus. This probably means that this blog will move off blogs.msdn.com, but still be accessible through http://weblogs.asp.net/abrunvol. The ambition is also to spend more time blogging ;-)

The four tenets of SOA - part 2

abrunvol — Mon, 19 Jul 2004 21:53:00 GMT

I was not able to finish the thoughts on ”The four tenets of SOA” in one go, so this is part two. BTW, Ian Mariano reminded me of an official Microsoft whitepaper explaining Microsoft positioning on SOA, and how we see SOA as a way towards Connected Systems. The whitepaper is found at MSDN Architecture Center: Service Orientation and Its Role in Your Connected Systems Strategy.

I would also like to point out that the most important part of this, for me, is not actually the four tenets, but more of how services will be defined going forward. The tenets seem to be a good starting point for that discussion, but the crucial question for me is to understand whether we will define services as either:

- Technical aspects of distributed applications

- Providing business capabilities as coarse-grained services in the enterprise architecture

- A combination of the above

(And I do strongly believe it is #2 that is closest to were we are going.)

Tenet #4 – Compatibility is based upon policy.

When I am out presenting SOA to customers and partners, this is the tenet I feel is the hardest to explain. It seems to me that many feel the compability issue is somewhat “off-topic” of the general “What is a service”-discussion.

The concept that a service provider and a service consumer can use a policy to negotiate appropriate protocol, message format, security requirements etc is very tempting, and there is no doubt about WS-Policy is containing very nice capabilities. But on the other hand, is this really a requirement for being service oriented, isn’t this more of an implementation detail or maybe more correct; a web service infrastructure ability? In my opinion service-orientation is not tied into being web services only, although web services in most (many) cases would be the right technology for implementing SOA. As I mentioned earlier, I feel that service-orientation is more of providing coarse-grained services, corresponding to business capabilities in the enterprise, than a technical aspect of distributed computing. This means you could do fully “valid” service-orientation without the ability of providing a machine interpretable policy for the service, or actually completely without leveraging web service technology at all.

MGB 2004: The four tenets of service orientation and other thougths on SOA - part 1

abrunvol — Fri, 16 Jul 2004 18:36:00 GMT

I am at the Microsoft General Briefing (MGB) in Atlanta, an intenal conference for Microsoft Field employees. The two days before the conference started we had an Architecture Training in Atlanta, very good, learned a lot in two days, and I got to eat dinner with Pat Helland ;-)

In the training I joined a very interesting (chalk) talk by Mike Burner, which discussed Microsoft position around SOA, and SOA generally. In the discussion there was raised the questions whether Don's four tenets of service orientation actually are correct. The four tenets are:

Boundaries are explicit
Services are autonomous
Services share schema and contract, not class
Compability is based upon policy

Tenet 1 and 3 are no problem. One of the good things with service orientation is that it becoumes explicit to the developers (service consumers) that there are some cost associated with the use of a service.

The interesting discussion is around #2 and #4. Are services really autonomous? How about infrastructure services like authentication and authorization? Would you expect every service to implement their own security, or rely on common security services to provide the necessary implementation. How about logging and auditing? In many of the recent presentations and discussion I have been to on SOA, one starts to categorize services into Process, Activity, Entity and Infrastructure. For activity and process services (if you forget about their dependence on infrastructure services) I can see the concept of them being autonomous, but for entity services? As entity services is described as wrappers for CRUD-operations, they will likely not reflect the business rules of the system/applications they are a part of, and subsequently not be autonomous.

This brings up another question on SOA, in my view. When discussing SOA, service orientation is motivated from the alignment of business and IT. Ie services are coarse grained operations that reflect business use cases, and they are implemented using (asyncronous) messaging, for example using web services. But, with the introduction of entity services, we break with the concept of business and it alignment, and are more focused around the technical aspects or definition of a service. A service is defined by its technical "signature" (message-based), and not by its functional or architectural role. I dislike the latter definition, as this is more of a implementation detail than leveraging functionality (services) within an architecture.

The first stumbling steps...

abrunvol — Fri, 16 Jul 2004 17:14:00 GMT

Just getting started :-D

I am an Architect Advisor in Microsoft Norway, working with customers and partners on architectural questions and .NET development.

The disclaimer:

The content of this site are my own personal opinions and do not represent my employer's view in anyway. In addition, my thoughts and opinions often change, and as a weblog is intended to provide a semi-permanent point in time snapshot you should not consider out of date posts to reflect my current thoughts and opinions.