SOA Gateway and the Cloud

Having recently seen a number of presentations about Cloud, it has struck me that like SOA, we are seeing the same boxes being placed in a similar pattern and there seems to be an assumption that they will simply communicate with each other. Is it any wonder that people are turned off some of these new advances in technology when the powerpoints make it look so easy. The Cloud offers some fantastic benefits in terms of making resources available easily and 'on demand', however, if the applications that are implemented within the cloud are using proprietary technologies to talk to each other, they will become locked to the one Cloud. One of the dreams of Cloud Computing is an ability to pick the best Cloud based on your most important criteria be that cost, availability etc. Then why should you not be able to roam from Cloud to Cloud as the criteria change. We believe that the usage of standards based interfaces to communicate between applications in the Cloud gives the best of both worlds as discussed here.

Best regards,

John Power - Free Industry Papers Here

Best of Breed Mainframe Integration and SOA Tools

I came across this white paper recently which touched on a number of the confusing aspects about SOA 'terminology' for want of a better word. Statements like '...with the connectivity and accessibillity offered by an SOA offers a great deal of promise....' confuse the issue even more IMHO as implementing a SOA in itself does not help with connectivity, accessibility or integration. When I originally came across SOA, I would have agreed wholeheartedly with the above but as I have said in other postings, the term SOA has now become so abused that it needs to be clarified what is meant. To be fair in this document, as one gets deeper into it, it gets into the standards that are used that do provide the ability to discover and use services available on mainframe. At the end of the day, most mainframe shops are also likely to be running at least one other server platform such as Linux or one of the various flavours of UNIX available. It is clear that getting at resources on both the mainframe and other platforms in a standard way is a base requirement which will ensure an organization can get the key benefits of implementing an SOA with an improved ability to reuse resources. While there are a number of ways to do this, it generally requires different tools for different resources. For example, there is generally one tool to access databases with another to access business logic. It is sometimes also necessary to use different tools on different platforms leading to multiple different interfaces. The SOA Gateway has been designed to provide a single tool to get at data and business logic on any platform thus providing a single, standard way to access core assets on these different platforms.

Best regards,

John - SOA Tools

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.