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.