SOA Gateway 'Ready IBM DB2 data server software'

We are pleased to announce that Risaris is the first IBM Business partner Worldwide to complete the validation requirements for IBM's "Ready for IBM DB2 data server software" program on their flagship zOS operating system for the SOA Gateway product. This, along with our recent completion of the validation on Linux Unix Windows (LUW) means that we are the only IBM Business Partner Worldwide currently to be validated on all platforms available in the program.

Here you can find a list of IBM's technical partners who have completed this validation and you can see that the SOA Gateway has some illustrius stable companions. You can find the IBM Solutions Directory entry for the software here.

This means that users of the SOA Gateway can now develop, test and run applications on LUW platforms safe in the knowledge that the same software may be run with the SOA Gateway on IBM's flagship zOS operating system. You can find usage scenarios for the solution here while you can find detailed tutorials on how to access DB2 data from many clients such as C#, Java, Excel, Internet Explorer etc. here. Finally you can find details of why you might wish to use Web Services and REST to access your DB2 data instead of SQL in a comparison which you can find here.

Again, we're very proud of this achievement and if we can provide further information on this topic, please don't hesitate to get in touch.

Best regards,

John

CEO
Risaris Limited
Unit 6 The Mill Building
The Maltings
Bray
Co. Wicklow
Ireland


Tel: +353 (1) 2768048
Mob: +353 (86) 2490683
Fax: +353 (1) 2765774

SOA Gateway
SOA Gateway Blog

Using REST or SOAP to access data

When talking with many prospective users of SOA Gateway, many people find it unusual that we use a SOAP and REST based approach to make data available to applications. Many people see SQL as the standard and only way to get at data. SQL has been a great workhorse over the years and will continue to be in the years to come. However, with the ever changing face of computing, particularly in the light of firewalls, business to business processing and so forth, it may not always be the most appropriate choice.

There are many powerful things that programmers may do with SQL but in the vast majority of cases, the requirement is to either update or to retrieve specific data. When the power of SQL is needed, there is no better way to do it but for simpler applications, the SOAP and REST approach works well and can offer many advantages over SQL. This is particularly the case where data needs to be delivered quickly and easily either to or from a desktop environment, or from remote users via multiple firewalls. We have produced a document comparing both approaches which can be found here.

I'd be interested in hearing your ideas or comments on this as it does seem to cause a lot of discussion with our customers and prospective customers !

Best regards,

John


SOA Gateway
SOA Gateway Blog

IBM DB2 Data in action

I was recently invited by IBM to paricipate in a virtual conference called Data in Action essentially about their DB2 product. This was an interesting experiment as it had a number of virtual booths that were 'manned' by IBM personnel and then there was a solutions area where we presented. There were approximately 800 non IBM personnel and 100 people from IBM personnel registered. At one point when I checked, it appeared that there were over 400 people in attendance.

It was quite an interesting experience as it was possible to see who was entering each area. It was then possible to engage people in a chat or they could start a chat with the 'expert' for the solution that they wished to have answers to. While not perfect by any means (what conference format is ?), it meant that people could attend at no travel cost while potentially still sitting at their desks available to participate in any crisis that may occur in their organizations.

Register for the event here and have a look at the presention from Risaris. We did the slides and IBM did the voiceover. Essentially our pitch was the ability to access DB2 from various clients. You can find more specific information in accessing DB2 Data from Excel , VB, JAVA or PHP as an example. You can also download the software for a Free trial.

Best regards,

John

Accessing Existing Data and Business Logic from new Business Process

Intalio and Risaris have teamed up to show how new Business Process Managment (BPM) implementations written using Intalio's BPM suite, and the SOA Gateway from Risaris, can access existing data or business logic. This ensures that new BPM implementations can work side by side with existing manual processes such that they can be used interchangeably until the eventual phasing out of the manual processes which provides many advantages. Learn more here.

The first results of this effort is a tutorial which uses community editions of both Intalio and the SOA Gateway to make existing COBOL business logic available to a new process. This is available on the Intalio Community site here (registration required). In addition, a paper describing this may be found here.

Future tutorials will show how to access CICS, Natural or other business logic or databases such as DB2, Oracle, VSAM, ADABAS and so on from the Intalio Suite. If you wish to see advance notice of such tutorials, please contact us on info@soagateway.com.

This illustrates how standards ensure that best of breed products in their class can work together through the use of open standards.

Best regards,

John - BPM Access to Existing Data

Lifecycle Governance of your core assets

The SOA Gateway enables your core software assets, including data and business logic, to be exposed as standards based services that can be used from multiple client technologies. Once a service has been deployed and is in use from one or more systems, there are reasons why it may change:

1. In order to improve the functionality available to the users.
2. In order to improve the business process with which it was associated
3. Users asked for something and didn't like what they got
4. ...and so on

The problem with this is when a service is deployed, how does one control change to this service ? Many organizations implement multiple versions of a similar service when a well designed single service will do. The SOA Gateway is being modified to provide the facility to ensure that the lifecycle of a service can be controlled such that a single service and its clients may be enchanced in a controlled fashion as described here.

This is still a work in progress so we're always interested in ideas or feedback to the direction we plan to take.

Best regards,

John

Want sub second response times with Rich Gui Interfaces ?

Those of us who have been around for more than a decade can remember the concept of sub second response times. A single 'second' was considered the maximum time between when a user hit 'enter' on their dump terminal and when they got a response from the system. This wasn't just a rule of thumb or some geeky idea of how a system works, there are many reports available which illustrate quite clearly that as response time gets longer, there is an increased reduction in transaction rates and essentially throughput falls. In other words, less work is done. Some might consider that this is just because of the longer response times but it has been illustrated that lapses in concentration add additional delays to the completion of a business process.

Since the advent of the PC and more so the Internet, we are being treated to vastly superior GUI displays which make like much simpler in terms of the usage and understanding of applications. However, this has been mirrored by a commensurate reduction in response times as GUI screens build and one must wait until this build process completes. This is probably quite acceptable for occasional users or those in Internet land prepared to wait. However, it leads to loss of productivity within organizations where employees are expected to plough through as much work as possible which is severely impacted by slow GUI response times.

The Enterprise Application Infrastructure described here provides an architecture that can deliver significant benefits and sub second response times while still delivering a rich user front end GUI. This is achieved through the use of the SOA Gateway and CaptainCasa tool sets which in turn achieve the result through a simple adherence to and usage of industry standards.

Check it out if you would like to reduce your user response times !

Best regards,

John

SOA Gateway now 'Ready for IBM DB2 data server software'

The SOA Gateway has now just achieved the 'Ready for IBM DB2 data server software' award from IBM. This means that the SOA Gateway has now proven itself while running with IBM's DB2 Database which is guaranteed by IBM themselves. More information on this award can be found here.

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.

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.