Standards Based SOA

When I originally came across the term Service Oriented Architecture or SOA, my understanding was that this related to an infrastructure in which standards were used to build services that would become part of a wider architecture. The primary standards in this area from my perspective are:

• TCP/IP as the network infrastructure to connect machines to each other.
• HTTP as the wire transport protocol.
  
• WSDL to describe a service so that it's clear what services are available and how to call them.
• XML as the standard payload to ensure that any system can understand a message
  
• SOAP as the payload standard to deliver requests to a service and to deliver responses from the service.

These standards alone provide a level of inter connectivity between platforms that has not been seen previously. We can also add the UDDI standard to this which provides a database of services that can be searched to find the WSDL following which the service may be called. Risaris Limited built the SOA Gateway technology to reflect these standards which is where the product name came from.

I have since had conversations with people from various organizations, typically the bigger ones like IBM, who talk about their Service Oriented Architecture based around WebSphere MQ. When I point out that this is almost totally a proprietary implementation, they tell me that what they put on the end of an MQ queue acts as a service, therefore their proprietary infrastructure is a SOA. I have heard this argued since by organizations keen to jump on the next hype cylce by reinventing their architecture as a SOA in this case.

At the end of the day, there have been well structured application systems for many years that exposed 'services' which were called by a number of different applications. They were called in a totally proprietary manner but based on the previous rational, we have had SOAs for as long as I can remember.

For me the value that SOA was to bring to the table was the ability to integrate easily between systems no matter what the architecture. It now seems that the term has become a dirty word some what and no wonder we hear the expression 'SOA What ?' because vested interests have taken the original value and corrupted it to meet their needs to join the hype cycle.

Given that SOA has become such a loose term, how can we refer to systems that implement a SOA using open, Web Services standards like WSDL and SOAP. A 'Standards Based SOA' perhaps ?

Best regards,

John - The SOA Gateway

The Cost of Integration Software

Risaris recently was runner up in the Most Innovative Company category at the KIS Partnering Forum. During the presentation the question of the business model was raised. The SOA Gateway model is designed so that an organization only pays for what it uses in a fully featured product suite. As the organization implements more projects with the SOA Gateway they must pay more and obviously when projects are terminated or retired, they pay less. Contrast this with other integration suites which generally require an extermely large up front fee plus yearly maintenance based on this fee. This SOA Gateway approach has the following benefits to the customer:

• It is far easier to measure the return on investment for each individual integration project.
  
  
• Each project must justify only its own integration cost and not the cost of an entire suite.
  
  
• Each project is likely to be paid for by specific parts of an organization. Using usage based licensing, each part of the organization may be charged exactly the cost of their project.
  
  
• The SOA Gateway makes existing data and business logic available as a serice. This means that not only do you get the immediate ROI for the first project but the service may be reused again and again in other projects meaning there is continuing ROI from the integration effort.

The review panel felt that this is not how organizations wished to buy this type of technology which I found very interesting. What would lend an organization to want to spend more money than it must on an integration technology ? There is obviously a degree of trust required that the software will do what is claimed, however, when the benefits are so large and the entry costs are so low (as it is usage based) what would prevent organizations from trying this ? I felt it was an interesting reflection on buiness that they would prefer to be sold an expensively price integration suite for their needs rather than use a product which can turn an integration effort into a form of commodity where you simply buy what you need off the shelf as and when you need it.

John Power - SOA Gateway Usage Based Pricing

BPM and existing IT infrastructure

I was asked last week how BPM solutions can be seamlessly integrated with existing IT infrastructure using the SOA Gateway.

I demonstrated such an implementation at the Intalio Conference in San Francisco last summer.

The demonstration was based on an online insurance company that needed to implement a BPM solution to:

§ Enable brokers create proposals for a company pension scheme

§ Allow key account managers to review proposals

§ Allow brokers to accept or reject proposals

§ Facilitate brokers to drive ad hoc sales campaigns.

All of this, of course, needed to be achieved within a regulatory framework.

The demonstration showed how the insurance company could implement a sales campaign for particular insurance products utilising already existing process models. It highlighted how we can enable the front business line (for example, key account managers) to change and dictate processes without the need to involve the IT department. This can empower the business line to initiate a sales campaign without the need for IT to configure the back-end.

Key to this is the utilisation of standardised technologies, such as web services, BPEL, BPMN, and a code generation approach as opposed to time-consuming manual coding activities. If anyone would like to learn more about this let me know.

John Power – Business Process Management and SOAGateway

Integration problems

When it come to technology projects, there is one stark statistic that is alive and well, organizations are still spending anywhere from 50-70% of project costs is being soaked up by integration, accessing and updating data. As we all know when a project has lots of integration effort, timeliness slip. Here is a paper written on the topic that you might find of use. Would welcome any comments.

John The SOA Gateway.com Integration Industry paper

How does the SOA Gateway work?

The SOA Gateway – An Introduction

The SOA Gateway simplifies integration because:

No custom interface is required No messaging middleware No customer server logic No software installation on client side Standard SSL security protects the data

The steps

1. Install the SOA Gateway software
2. Use the configuration wizard to wrap and make business logic available as a Service in minutes
3. Build client application

The SOA Gateway Explained

Given the SOA Gateway installation is a once-off event on a given platform, the steps required to wrap a single piece of business logic are easy:

1. The structure(s) identifying the inputs and outputs to the business logic is identified and imported into an Eclipse based tool.
2. The fields in the structure are marked for ‘input only’, ‘output only’, or ‘input’ and output’.
3. The definitions are exported to the SOA Gateway Server.
4. The service is published and is now available to the client.

What does SOA Gateway do?

Access legacy data faster

The SOA Gateway is a software tool that will allow you to expose data to new, or existing applications, in minutes as opposed to days. It enables access to data from a wide range of database languages without server side code, or expensive middleware.

…70% of the cost of any software project can be soaked up by integration.’ Gartner

Access business logic easier

The SOA Gateway enables easy access and re-use of valuable business logic written in CICS, COBOL, C, NATURAL and many other languages.