Friday 23 November 2007

Services and Web Services

I speak to a lot if people about Service Oriented Architecture and find that many people do not really understand what a service is and what role Web Services plays. The root of the problem is that to understand what a service is, you first need to understand the make up of an SOA. The two key components of an SOA are the Business logic and, for want of a better description, the plumbing. It is the separation of the business logic from the plumbing that makes SOA technology important.


The plumbing layer is concerned with executing services and handling messages. It is entirely independent of the business logic and it is this separation that distinguishes SOA from previous IT architectures. The plumbing is very techie and is consistent throughout i.e. it never changes. The business logic layer is, or should be, entirely free of programmers and their code and allows business analysts to model their processes without recourse to code or script.


It is this separation that gives SOA its agility. Models of business processes can be amended at the same pace the users business needs are changing, overcoming the disconnect between IT timescales and business expectations that has dogged IT until now.


Business processes are built up by linking together models of individual business actions called, in SOA speak, Services. An example of an individual service would be to perform a credit check. Another may be to determine stock availability and so on. Business processes are created by stringing together services. Two factors work together to make this technology very agile. The first is that many services can be re-used over and over again and the second is that the code less development of new services by business analysts is itself very fast.


Typically, a new business service would be made up of a mixture of existing services and newly designed services. The next important feature of SOA technology is that the services are not hard wired or integrated together in the traditional manner - They are loosely integrated. A services communicate with each other by asking for information. For example, if a credit check is needed, any service anywhere in the network can ask the credit checking service to perform a a credit check. This is possible because every service uses an agreed standard for communication. It does not matter what this standard method is as long as every service within an architecture uses the same one.


This brings us to Web Services. These are just a recognized and agreed standard way of communicating between services. Standards such as this are needed so that business processes can be designed that call on services not resident and under the control of the local designers. An example of a commonly used external service is Google maps.


There is one problem with web services - they are relatively slow. For this reason it makes sense to adopt a faster, leaner communication standard internally and to reserve the use of Web Services for external communications.