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.
