What is SOA?

For many people SOA means Web Services or the adoption of XML standards, to others it involves taking on and learning new technologies. While the use of Web Services can be part of an SOA and you may decided to extend you architecture with new products it does not have to be the case.

Randy Heffner (Vice President and Principal Analyst, Forrester Research) describes SOA as a broad set of design concepts that centre on your business processes and transactions. These processes are then exposed using application-to-application protocols, of which Web Services, XML or JMS messaging may be such protocols.

The key here is that the SOA is designed and solutions built by looking at the business. It does not matter which products you use, although some products will be better than others and you may already have your preferences. A SOA allows for best-in-breed solutions to be implemented that achieve the goals of the business, rather than applications being given to the business that shape how business will be done.

Why SOA?

SOA can be seen as a way of better integrating business systems. Applications in the past have been built as Silo stacks. That is an application that has its own business logic and data store and interfaces. Generally the application works in isolation and because of this often the same business processes will be repeated in a number of applications. Whenever the business demands a change to the way a processing is performed many silos have to be changed. Using services can reduce the repetition of business logic thus ensuring each application performs the same functions in the same way. It also ensures that changes in business processes are implemented at the same time.

Another problem with conventional applications is that they often consist of many interfaces to external systems to share and synchronise information. Often these interfaces will be performing the same function, but will do so in different ways. Over time a whole network of tightly coupled interfaces evolves making the replacement of any one application very difficult; a successor has to replicate each of these interfaces. It also means that in the event that an interface requires change that all applications have to be modified. Having a service and an agreed message structure on which all applications will communicate reduces the amount of rework involved in a change and also allows for a plug-and-play approach to applications.

Applications and I.T solutions have previously been built using a bottom-up design, when systems and data sources area linked together to provide a grander, seemly integrated solution. However the rigidity of the links means that they are often inflexible and when the business needs change, applications cannot accommodate the changes in a timely fashion.

A well designed SOA is one that has been approached using a top-down methodology as it is this kind of design that will reflect the business processes. Once this is done solutions are built that can truly provide services that support the business needs. As business processes are now a group of provided services they are very flexible. Adapting to changes in business procedures is simply a matter of modifying the process chain, by adding new services to support the new requirements.

Does SOA give me ROI?

Like all development the building blocks are always the most expensive to put into place. Therefore the initial components may be costly, but as you move more services into your SOA you will achieve greater reuse and the quicker future development will be.

Analysis by Forrester Research's Ken Vollmer and Mike Gilpin report, that when application component is reused over and over, SOA becomes more than 30% more cost effective than traditional development approaches.

What's going on in my SOA?

Visibility and management of a SOA becomes the next challenge. It is key from a service owner’s point of view to understand who is using their service? When did they use it and what level of service did they get?

When there are problems or performance issues it will generally be the man in the middle that gets the finger pointed at them as the person responsible. As a service is at the heart of each call in a service enabled application the finger may very well point to you.

Unless there have been service specific code added to audit the service calls and responses then it will be difficult to pinpoint the real problem. However the problem may not be with your service, but something else you rely on down stream. Adding code will slow down the responsiveness of your service and so reduce the maximum throughput it is capable of.

There are products available to help with this, we believe the best product for this is Progress Actional. Actional for SOA Operations has a number of interceptors that will capture and collate requests, messages and operations that flow throughout your SOA as well as where request are made from and responses are sent to. No coding changes to a service are required. Data is collected and returned to a server to show you an exact data flow and identifying service dependencies. The collected data can also be analyzed to ensure compliance with service level policies and alert SOA Administrators and Service Owners of non compliance.

How can Proaxima help?

Proaxima specialise in the development of SOA Proof of Concepts, Prototypes and Pilots.

Proof of Concept

The primary aim of a Proof of Concept is to prove that the architecture and products used fit their intended use. The solution should not be considered a production release and will only be guaranteed to work within certain constraints. A demonstration of the proof of concept will be provided with a technical insight into the products used. This could include installation and configuration to your own hardware if evaluation licenses permit.

Prototype

The prototype is a real-time solution with specific but limited scope and functionality. The prototype will be written so that it could play a part in a production release, but it is intended to be placed into a controlled/testing environment. Further work or rework should be expected before it would achieve production status. As part of the prototype handover product installation and configuration of hardware will be performed if evaluation licenses permit. It would be expected that additional training and/or mentoring would be required to take this prototype into production.

Pilot

A fully functioning solution that complies with the functionality provided in a specification document. The solution would need to under go quality assurance and testing, but should be considered as production worthy. Installation and configuration of the environment would be provided, but production based licenses would be required. Documentation of the functionality would be supplied and optional ongoing support could be arranged.