Avoid Work Station maintenance with SOA

Many years ago when dumb terminals were the order of the day, upgrading those terminals meant changing a fuse or simply replacing them all together. They have by and large been replaced by a PC on every desk which has enabled unparalleled access to applications by users in all forms of organization.

With progress there are always pain points which only became evident as work stations were rolled out across organizations. One of the main pain points with work stations all over an organization is the requirement to upgrade software on each and every work station when specific server software must be updated. This can range from a few hundred PCs to many thousands and results in thousands of person days to keep such software up to date.

Consider then a solution which avoids the need to upgrade software on every PC when server software is updated. Imagine a situation where the software is installed on the server and the work stations just start using the new server software out of the box. Doesn’t this sound like a very attractive scenario ?

Well the wait is over as SOA standards like SOAP and REST mean that this can happen today. When a server communicates using the SOAP or REST standards, there is no requirement to install a work station specific component. This is achieved because the work station software either knows how to call a REST based service already or can learn how to call a SOAP service by exchanging a few messages with the server.

This has the potential to revolutionise how often you need to upgrade the work stations in your organization. The SOA Gateway will enable you to create services on your server systems that require no software footprint on your workstations.

“Response times” vs “Delivery times” - how can a SOA help ?

Those of us of a particular vintage will remember green screen applications which were essentially character based screens to allow you to communicate with your applications. We will also remember the fact that these applications generally had response times of less than a second from the time you hit ‘enter’. There was a general rule of thumb that if the response took any longer than 1 second, the user’s attention would be lost and thus reduced productivity was the outcome.

Moving forward we now have visually quite stunning graphical interfaces with which to communicate with our applications, however, how many of these provide “delivery times” of 10’s of seconds between interactions ? This is generally because the screen being displayed is made up of many parts and takes many round trips to the system to complete the screen.

This does not have to be the case. With a well designed Service Oriented Architecture, one or a limited number of services can generally provide all the information required for one screen. This means that the data to build the screen can be retrieved in less than a second. The additional ‘beautification’ that admittedly makes the screen look good is normally static in that it doesn’t change from display to display and can be cached locally.

Using a Service Oriented Architecture (SOA) and caching of graphical images, it is therefore possible to have the benefit of a fully graphical interface with response times of less than a second reminiscent of the green screen era. Many studies have shown that such responsive applications improve the productivity and job satisfaction of people using those applications many times over.

The SOA Gateway will enable you to create the services that will provide such an architecture.

How can a Service Oriented Architecture (SOA) help with Quality ?

For many projects and implementations, the cost of implementing a good quality assurance suite can cost as much as and even more than the implementation of the required functionality for the project itself. This is primarily due to the fact that with traditional project implementation, the interfaces and unit testing all involve proprietary interfaces.

When using a standards based SOA throughout your organization, it is possible to significantly reduce the costs associated with the creation of a fully functional QA suite. This is possible because when services are implemented using SOAP or REST based standards, there are a multitude of tools available freely or at minimal cost on the web.

Many of these tools enable testing of services using a configuration based approach. This facilitates the creation of QA suites without having to use programmers to code the test suites. The tools will import and understand how to call a service and then non programming resources can be used to drive the tests. This in itself represents the potential for massive savings.

Where more obscure tests are required, it is possible to drive services implemented using SOAP and REST using scripting languages like PHP or RUBY. There are many resources available that can program in these languages.

Finally a major issue with QA is that it can sometimes impact on the execution profile of a system because it runs on the same platform as the system. When standards are used, it’s possible to drive services built using these standards from a totally different system thus emulating more accurately what the real users will do to the system.

The SOA Gateway enables the creation of such services from base data access services to complex front end services to be made available to your customers

Using Web Services instead of SQL to access data

Many organizations and projects consider accessing data using SQL or perhaps ODBC without looking at alternatives. But there is now a real alternative to those technologies. It’s now possible to access your data using SOAP or REST based Web Services which can offer distinct advantages over SQL or ODBC.

It’s now possible to access data directly using REST or SOAP based services. These provide CRUD (Create Read Update  Delete) services which allows the addition, reading, updating and deletion of data. This offers many advantages over traditional SQL access to the data some of which are listed here:

• The data will be delivered as XML thus avoiding any code page issues between platforms.
  
   


• Communication uses HTTP over TCP/IP so connectivity is direct and simpler to configure.
  
   


• HTTP over TCP/IP enables easier access to data across firewalls.
  
   


• It’s possible to use standard access and encryption technologies to ensure secure access to the data to authorised users only.

• Due to the standards used, there is no requirement for a software footprint for the data access on the accessing system.

Ultimately it’s really a case of the right tool for the job; how you wish to access the data will depend on what you are trying to achieve. You will find a longer discussion on this topic here which discusses this topic in more detail. The SOA Gateway provides a very simple way to enable access to your data using SOAP and REST based Web Services