We all execute many services (or operations) every time we sit down in front of and use a PC: logging in, opening files, reading/writing/deleting email, running antivirus software, and so on. As programmers and software designers, we enjoy an advantage in being able to view things in the abstract. So, let’s do that now! On a more abstract level, what we do when we use a PC is to manipulate services, as illustrated in Figure 1. It might be helpful to think of the boxes in Figure 1 as services; that is, to think of your email as a service, to think of the files on your PC as a service, and so on. You then use (or consume) these services. The services go together to make up an SOA.
Looked at in this way, we all use SOA every single day and have done so for a long time! Extending the analogy, there are other services, such as phones, fax, power, and so on.
Figure 1 User operations on standard software services
Many organizations are now migrating toward SOA, which adds elements that I haven’t really discussed yet: workflows and business processes. Workflows are the steps taken to achieve a given business aim—for example, when you request some time off, there is a series of business steps that occurs:
- You ask your manager.
- Your manager might then evaluate workload and backup personnel and then grant the leave.
- The manager might then notify HR of your impending time off.
- HR then reduces your annual allocation appropriately.
These are simple workflows that fit into overall business processes. Again, we’ve all been using them for a long time! But the terminology has changed or is gradually coming into mainstream use.
So to sum up, an SOA can be thought of as being made up of the following major elements:
- Operations or actions (for example, requesting time off, deleting email, creating files, accessing Web services, and so on)
- Business processes
Let’s now see how these concepts map into network operations.