What’s in a word. In deployments the nature of the words you use can kill you. SOA (Service Oriented Architecture) is living proof of this opportunity for confusion.
Remembering the fundamental guiding principles of SOA (see endnote below from wikipedia) we have an issue/opporunity around the concepts of interoperability, componentization, encapsulation and reuse.
To me this means that the service is independent in nature to the other services around it other than rules of interaction and to a lesser extend the platform. So when you start talking about SOA deployment there is often confusion when reviewed or implemented by the school of thought of our old systems.
Since the systems are supposed to be independent entities that do not exist if not published in the registry, if I deploy a new service and don’t tell anyone, do I need to test the whole system? No! If I add it to the registry do I need to test the whole system? No!
In the old world of tight coupling there were issues when you made even the simplest of changes which called for massive regression tests.
So when we think about deployment in a SOA world we need to break it up into different types:
- Infrastructure
- Upgrade/Add Hardware
- Upgrade underlying enterprise platform that service lives on (BEA, SAP or Websphere)
- Network
- Location
- Services Deployment – New
- Services Deployment – Old – modifying an existing service, add elements or change business rules
- New customers/consumers of our services
These to me are the main points of consideration that should drive behaviour, but choose your words wisely or you will spend so much time testing that you will spend more than your development budget and that defeats the purpose.
ENDNOTES:
Wikipedia excerpt about SOA which I like:
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA[6]
- Reuse, granularity, modularity, composability, componentization, and interoperability
- Compliance to standards (both common and industry-specific)
- Services identification and categorization, provisioning and delivery, and monitoring and tracking
The following specific architectural principles for design
and service definition focus on specific themes that influence the
intrinsic behaviour of a system and the style of its design:
- Service Encapsulation
– A lot of existing web-services are consolidated to be used under the
SOA Architecture. Many a times, such services have not been planned to
be under SOA. - Service Loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
- Service contract – Services adhere to a communications agreement, as defined collectively by one or more service description documents
- Service abstraction – Beyond what is described in the service contract, services hide logic from the outside world
- Service reusability – Logic is divided into services with the intention of promoting reuse
- Service composability – Collections of services can be coordinated and assembled to form composite services
- Service autonomy – Services have control over the logic they encapsulate
- Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
- Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms[7]
