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.

what constitutes a reuseable service

At the core of the SOA drive lies the desire for reuse. This is because reuse is seen as the way to shorten development times and therefore achieve some measure of agility. The idea is to create services which are then registered and aviable for re-use. The problem is what constitues a re-useable service?

For example, a service might be created that can access data from a specified table and return values that meet certain criteria. A service such as this is nicely non-specific and so the options for its re-use are large. However, developing solutions that orchestrate services of this type will still be a long task.

An alterantive example is to consider re-use at the compound service level. As an example, we might have created a compound service that returns customer data from a specified database. The methods available may return the primary address, delvery address and so on. This woudl be a compond service because it will include several simple services, including the one in our first example. It could even have been contructed with a set of graphical interfaces already defined

The options for re-using the compound service are more limited than those for the simple service, but using compound services at this level speeds up the time needed to create new processes immensly. Which extreme is best suited to a developeers needs

Ready, Steady, Stop - SOA gets in the way

Imagine your a supplier of software. You have invested in developing your software offerings over a decade or so and now you want to know how to respond to the move towards SOA among your customers. This is the problem facing a company I visited this week. They had two problems. The first is that they have several software offerings sold individually and in combination. Currently, these systems are not integrated and each time they sell a combination they hard wire them together afresh. The IT Department believes that the integration requirement is the same every time, but the implementers disagree.

The second problem is how to present themselves externally. If their customers are moving towards an SOA architecture, they are wondering if perhaps they should offer a loosely coupled integration option via web services.

The IT department is proposing that they adopt an SOA strategy and that they integrate their existing software systems using web services and offer web services as the means of integrating their products into their customers IT environments.

Unfortunately, this is a loose loose option. The first point is that adding a few web services to the existing software has nothing what ever to do with SOA. Adopting an SOA strategy would require them to re-build all their software from the ground up. Using web services simply as a means of integrating existing lumps of software is not only nothing to do with SOA's but also will not prove to be an advantage over using an EAI approach. Web services are slow and intended for inter company links where traffic volumes are low.

Unfortunately, the argument for using them for integration with the customers existing software systems is even weaker. With no advance knowledge of the system to be integrated with or how it has been implemented, it is unlikely that a pre-conceived web service will work any time let alone every time. Add to that that the traffic volumes involved are often very large and you have a recipe for disaster.

The Immediate problem for this companyis that the decision by IT adopt the use of web services and present it as an SOA strategy is blocking all attempts by the company's divisional management teams to address their immediate needs for a better way to meet their integration needs

Integration hub v ESB

I know several vendors of software products who are debating the same question: Should they go all out to use Web Services as the only primary interface for integration? Each of them sells software products that have to be integrated with other systems, often legacy systems in already in use at their customers.

This question raises two important issues plus one interesting technology question: The first is just how real is the movement towards SOA's i.e how long will it be before the big majority of their customer operates an ESB with which they can contract? The second is how important from a marketing perspective is it that they be seen to be ready to participate in an SOA?

The interesting technology question is: How good are Web Services for integration tasks anyway?

To give a view on the first question - there is a lot of activity in the marketplace. SOA's are the subject of the moment. That said, there are very few implemented examples of any meaning and the jury is definitely still out on whether or not the approach will give an adequate return on investment.

The answer to the second question - how important is the market perception of a products SOA credentials - paradoxically this seems to be very important. So here we have a conundrum. In practical terms there are very few ESB's in use. The majority of customers of these software's will need an alternative to Web Services for several years yet. But purchasers will want to be reassured that when and if they do get there their vendors will be ready for them

The more difficult question concerns Web Services themselves as the technology of choice. Being XML based they are slow - very possibly too slow for integration use where traffic volumes are high and/or each transaction is very broad.

Being practical, in the short term vendors will be forced to offer rules based EAI or, if their customers will wear it, individually hard coded integrations. Wouldn't it be good if there was a solution out there that offered its users the option to start will a rules based EAI approach and phase in an ESB solution when the customer was ready using the same suite of software?

Trend goes live with SOA solution

Trend Communications has gone live with a ground breaking on-line quotation and order entry system. Developed using EdenAgileIT (www.datadialogs.com).You can view it at

http://83.138.140.161:7734/TrendProto.html)

the solution consists of 150 re-usable services developed using Eden's codeless modeler and orchestrated with a combination of Eden's ESB and JAVA designer. The resulting Rich Internet Application revolutionises the way Trend does business through its distributors.

The approach Trend adopted was to leave their legacy ERP system alone rather than trying to expose any legacy functionality as services and the create the entire customer facing process set from scratch. Quotations under development are stored in a separate SQL Server database and only when an order is confirmed are the details of the assemblies required, with their bills of material passed into the ERP system (Infor's System21on an i-series) so limited are the options for using this ERP system within an SOA architecture that Trend decided not to try and literally Poke the data directly into the ERP systems database (This turned out to be much easier than the vendors scare stories would have Trend believe)

Web services were not used because the large volumes of data involved made them too slow. That's the third time this month I have encountered SOA developments electing to not use Web Services. It looks as though We Services are best suited to inter-company collaborative developments where high volumes are not an issue

Watching an SOA strategy take shape

Before I get on with the technical SOA stuff I promised, here is a diversion you might find interesting. I have come across a mid-sized company that packages and sells materials through supermarkets - Its a well known brand name with a turnover in the £60m range. Just the range that is going to have to deal with the issues I have discussed thus far in this blog.

They have already set up a strategy group to look at the feasibility of Service Oriented Architecture so I have the perfect opportunity to watch the process as it develops and write about it in this blog.

As soon as they give me the information, I will tell you about both the politics of the venture and the technical decisions they take with their reasoning. First decision will be how to start - Agility first i.e a quick kill by identifying a process or related set of processes or the purist, technology led approach through the creation of an ESB and an entirely new process built with all new services.

I can tell you the toolset they have chosen is IBM's Webspere and Weblogic. Watch this space!