SOA in a Nutshell

Service-oriented architecture has emerged as the means to improve business intelligence, innovation and agility, through developing loosely coupled distinct automation logic units. These loosely coupled automation logic units allow an abstraction of business logic and technology.

SOA encourages units of logic to exist autonomously yet not isolated from each other. In SOA the units of logic are known as "services".

Automation Logic

The automation logic components used by SOA comprise of:

1. Messages: which represent the data required to complete some or parts of a unit of work.

2. Operations: which represent the logic required to process messages to complete a unit of work

3. Services: which represent logically grouped set of operations capable of performing related units of work.

4. Processes: which contain and define the business rules that determine which service operations are used to complete a unit of automation. Instances of processes wherein a group of services follow a particular path through the process logic to complete a task are known as activities.

SOA Principles

Key principles in SOA are:

1. Autonomous services
2. Loosely coupled services
3. Services abstract underlying logic
4. Composable services
5. Formal contracts to define information exchange between services
6. Reusable services
7. Stateless services
8. Discoverable services

Software Components

Systems engineers define requirements at various levels, the highest of those levels is the business level, then comes the enterprise level, then the system level, then the component level. For a physical system a component could be easy to identify, how about software?

One way of defining a component in the software world is an active object with clear self-defined interfaces [1]. Active objects are objects with have their own thread of control.

Another definition is that a component is an object written to specification. Components are defined to meet several criteria namely; multi-use, non-context-specific, composable, contained and of independent versioning [2].

So a component level requirement is a requirement that tells the developer the needs that the code shall be able to accomplish.

[1] Hassan Gomma, "Designing Concurrent, Distributed, and Real-Time Applications with UML", Addison Wesley, 2000

[2] http://en.wikipedia.org/wiki/Software_componentry

The 4 Ps of Marketing and 13 Aspects of a Good Requirement

Just as marketing has 4 Ps: Product, Promotion, Place and Price

Requirements have 13 attributes:
1. Describe what and not how
2. Atomic
3. Unique
4. Documented
5. Identifies owner
6. Traceable
7. Necessary
8. Complete
9. Unambiguous
10. Identifies applicable states
11. Testable and quantitative
12. Not a constraint
13. Not a goal

Rule of thumb: A requirement should be satisfied by only 1 design component, it not feasible then it should be broken down further.