{ explore .net }

Finally I had the time to take the S90.03 exam (SOA Design & Architecture ), I know you've all been waiting for some info on this.

For the moment I don't have the time to go into detail about it but I'll give you the general idea of the exam:

It goes more into detail about the principles of service design, the relation between the different principles, how they are related to the SOA goals and the place of SOA in the enterprise. Specially service composition seems very important in the exam.

For my eager followers, you won't have to wait very long for some info on exam S90.04, I scheduled the exam for September 27.

Introduction

A service is the essential artifact in SOA, everything revolves around it, you'll be analyzing, modeling, designing, implementing, governing and versioning services. A service is a specialized piece of business logic, a piece of software that is designed by following the ideas, principles and patterns in mind that will fulfill a specific business need. Finally, some logic implemented as a web service is not automatically a (SOA) service.

Classifying services

When you're modeling and designing services you'll see that most services can be classified as a Utility, Entity or Task service:

- utility services: these are the services that don't have any real business knowledge and they are the most agnostic, this gives them the highest reuse potential. Utility services could encapsulate logging, notification,...

- entity services: these will most likely support CRUD operations on business entities such as clients and orders. Although they are working with business entities they are still very business agnostic, they don't have any knowledge of the business process that is using them. This gives them a also a high reuse potential.

- task services: they are specialized in executing a specific business task and so they have specific business knowledge and rules, this makes them less likely candidates to be reused

Modeling/designing services ...

Before you start a specific service implementation think about the big picture first and make an enterprise service blueprint. This is a high level overview of the services that will probably be needed by the enterprise. It will give you more guidance, direction, help set priorities and avoid future overlap between services.

Business is at the core of a SOA solution so everything starts by a specific business need that needs to be fulfilled. Then it's no surprise that the SOA delivery life cycle starts with the business analysis. When this is done the service modeling can start, this is to conceptualize the services that will fulfill the business need, this must be done by the business analyst and architect to keep the business and services aligned. Now comes the design fase, here the final services are chosen and get their technical design from the architect. Now the actual development of the services can start. A future article will go into more detail about the SOA delivery life cycle.

Always keep the principles and goals of SOA in your mind, are the services loosely coupled, do I have a standardize service contract, what will be the impact on the governance... Make every service as specialized and agnostic as you can, this will greatly enhance their reuse potential and avoid overlap with other services.

Service Implementations

Once your services are designed you can start implementing them. The technology that you'll be using is up to you, you're not limited by only SOAP based web services. The services can be also implemented as components or REST services. You don't necessary need to use an "open" technology, if your enterprise is completely Microsoft oriented you could use WCF over TCP with binary encoding and you would still be doing SOA.

Introduction

Service Loose Coupling means that each service is an isolated entity with limited dependencies on other (shared) resources. These resources could be technologies, (legacy) applications, databases, components, API's, infrastructure... The more a service is isolated from external resources the more predictable and reliable it will be. Don't start thinking that you can't have dependencies/relationships between services, service compositions are essential to SOA and is also one of the SOA principles but services shouldn't share the same underlying resources such as a database.

Standardized Service Contract

Service Loose Coupling also means that the service contract should be created with this principle in mind. When the contract is generated from a developer tool or runtime environment you automatically make the service dependent on that technology and so the service implementation and consumers will also be dependent on that technology.

Good Coupling and Bad Coupling

By now you should have realized that some types of coupling are good (allowed) and some are not good (or should be limited) and some are necessary. Coupling a service to a service contract is good but not the other way. Coupling between services is good, services must be composed to to create new business capabilities. Eventually the service will be coupled to a specific technology and runtime, this is necessary, you must develop your service with some technology but avoid the coupling of you contract to a specific technology.

I just scheduled my first soaschool.com exam for December 30, just in time to keep on track with my planning to do one exam this year :-)

I've read the book SOA: Principles of Service Design completely, read the self-study material and I tried the sample questions. Until D-day I'll probably listen to the the CD's with podcasts and review the most important chapters of the book that concern the first exam.

Once I took the exam I'll let you know what it was like.

UPDATE: Because the exam center unexpectedly had to close last week I was forced to reschedule my exam to January 21.

The second international SOA symposium is organized from October 22-23 2009 in Rotterdam, the Netherlands. There are also 3 days of workshops (Oct. 19-21).

But, the presentations of last years symposium can be downloaded for free. Topics include SOA in genereal, architecture, ESB, REST, web services... They also mention that soon some video presentations will become available.