SOA Gateway Concepts and Facilities


Introduction to SOA Gateway

SOA Gateway will enable an organization to save a large percentage of their integration budgets by using a productized approach to what has, until now, been an expensive, people intensive, repetitive process to get at existing data and business logic. SOA Gateway enables access to these assets from all of the most popular languages, products and Enterprise Service Buses (ESBs) available today. This capability has been promised a number of times over the years and has not been delivered, however, with the advent of W3C standards such as WSDL and SOAP, and specifications such as the REST architecture, this promise can now be delivered. If you are a little skeptical because you have heard all this before, read on to see how the SOA Gateway achieves this.

The Integration Problem

All projects in already existing IT installations involve some level of integration with existing databases to access data. The traditional approach used today involved an effort to build logic to make this available to the project via middleware messaging systems such as MQ Series, TIBCO, EntireX or Orbix. This approach works well but involves a lot of people intensive processes such as the design of the interfaces, building of complex services to access the information and service multiple clients as illustrated in the following diagram:

This approach has a number of drawbacks:

  1. It is people intensive and thus expensive to implement and maintain into the future.

  2. It takes weeks or months before the functionality is available and can cause significant delays to projects.

  3. It involves managing people with different disciplines as the languages or databases used on the existing platform are likely to require different skillsets to those of the developers building the new application.

  4. Unit testing of the individual pieces involves more expensive custom coding.

  5. Reuse can be difficult to impossible as generally the implementation is designed for one particular client system.

By installing and using SOA Gateway, all of the complexity, time, effort and cost can be saved by using a configuration approach to make the data available to your clients as per the following diagram:

graphics/conc0101S.png

So what are the benefits of this approach ?

  1. Resources are configured and available for use in minutes instead of weeks or months.

  2. No programming effort is required to access the data or business logic so programmers can focus on the business application.

  3. Unit testing can be achieved with standard, off the shelf packages.

  4. Reusability is guaranteed as the same service can be accessed from all the different technologies.

  5. No software is required on the client system so there is no installation, configuration or maintenance of software on the client systems.

This is possible through the use of the W3C standards in the SOA Gateway as described in the subsequent sections.

Why a Standards Based Service Oriented Architecture ?

A Service Oriented Architecture (SOA) can mean different things to different people. Ultimately, in its loosest form, if a program can be called in some way and give a result, it is providing a service and thus the infrastructure could be called ‘Service Oriented’. At the end of the day, many organizations have been doing this for a long time by implementing the business logic and screen logic separately so that the business logic may be called from multiple places so a SOA is nothing new apart from the terminology.

The nirvana that most organizations wish to get to is where their products and applications can interface seamlessly with each other on multiple platforms. This is sometimes achieved by what are called ‘Web Services’. However, this term is often also applied loosely on the basis that if a service is delivered via the Web it is a ‘Web Service’. These are generally proprietary, non standard Web Services which can only be integrated once you know the proprietary mechanism they are used.

What does offer the integration that organizations desire are Web Services that are implemented using W3C standards like WSDL and SOAP or specifications such as the REST architecture. The implementation of interfaces using these standards will enable applications to seamlessly interface with each other without any programming requirement. SOA Gateway specifically only offers access to data and business logic using recognized standards to enable simpler integration. Any reference to Web Services in SOA Gateway documentation set will mean standards based Web Services implementing using WSDL and SOAP or using the REST Architecture.

The Standards Used

The Simple Object Access Protocol or SOAP emerged as a mechanism to enable applications to access objects on any platform without any knowledge of the platform. Along with the Web Services Definition Language or WSDL, it forms the basis for the provision of standards based Web Services. It has been accepted as the best protocol available for accessing data and applications on heterogeneous platforms without any knowledge of the platform or the operating system where the accessed object resides. It is emerging as the agreed standard for future application development and integration efforts. In addition, SOA Gateway enables access to data and business logic using the REpresentational State Transfer or REST architecture which enables access to resources using a simple URL based approach.

Open and Simple Protocol

The protocol is open and thus is not controlled or owned by any vested interest. It has been designed to work with any software or hardware. Its greatest asset, like TCP/IP and HTTP before it, is its simplicity. It is possible to read SOAP requests and responses with the human eye and understand what they are trying to achieve. The SOAP Standard itself is extremely light particularly when compared to other standards for linking programs together such as CORBA, COM, COM+ and so on.

Platform and Operating System Agnostic

The test for any standard that claims to link software together is how easily it can be run on new platforms. In the case of SOAP, it is already in use on all of the leading platforms and operating systems available today. While there is a large amount of code available today that uses or implements SOAP in some way, it is the standard itself and not necessarily a set of code that is important. The SOAP standard can be used to solve each problem in the best possible way instead of relying on lots of infrastructure to enable SOAP. This flexibility enables the standard to be used on any platform or operating system.

No Client Foot Print Required

As all of the leading technologies have an integrated understanding of how to call SOAP Services, there is absolutely no software footprint for the SOAP Service on the client platform. This leads to easier deployment and maintenance of SOAP based clients.

IBM, Microsoft, BEA, SAP and others agree

All the leading software manufacturers believe that standards based Web Services are the way of the future. All new and upcoming releases of software will include some support for SOAP. For applications that run on the desktop, this generally means that they can issue SOAP requests. For heavier duty 'server' applications, they will generally have the ability to issue SOAP requests and to service SOAP requests in some form or another.

The SOA Gateway Approach

SOA Gateway adopts the view that data and business logic can be exposed in a simple, open and logical fashion that requires no coding on the platform where the data and business logic resides. This leads to the point where access to existing data and business logic on any existing platforms can be achieved by installing software and configuring it. This task can be undertaken by the system administrators who are normally available on site. Looking to the future, later projects can then continue to reuse the software with only a configuration requirement to make additional data available for other application development or integration projects.

Overview

graphics/conc0200S.png

Less Points of Failure Leads to a More Resilient Solution

With this architecture, there are less points of failure. The application talks directly to the software that accesses the database or the program containing the business logic, thus the additional hop from client to middleware and middleware to server is avoided. Less points of failure leads to a more stable and reliable implementation.

Only Configuration - No Programming Effort

Once SOA Gateway has been installed on a platform, the only additional effort that must be made to make data or business logic available is to configure the product to access the data or business logic. This can be done by the administrator or systems programmer for the existing platform instead of having to get programmers with the appropriate knowledge to develop code on that platform. SOA Gateway provides a discovery interface for each supported database or programming language to automatically create the Web Services for you. This means that your programmers or users can focus on the business issue in hand instead of spending time on getting to the data or business logic.

Knowledge Only Required in New Programming Logic

No knowledge of different platforms and software is required apart from that which will be used for the new application or integration effort. This will lead to a less complex project as all programmers are working in the same environment and there is no coordination required with programmers on different platforms.

New Technologies Use Web Services

The Web Services technology has simplified the way program to program communication can occur. All new technologies can use Web Services and existing technologies that are being further developed will all ultimately be able to use Web Services. The Web Services standards in use are hardware, operating system and data agnostic and as such can be used from any programming language or paradigm and from any platform.

Uses Less Hardware Resources

There is less software installed on the existing system and less hops for each message backwards and forwards. This leads to a smaller footprint on the system and less usage of valuable memory and CPU resources during execution.

Specialized Service - Only Does What You Need

SOA Gateway is a specialized service to access your data and thus does exactly what is required. There is no large body of code and functionality that is not used and must be installed as part of the product as can be the case with standard middleware solutions. This saves on time, resources and complexity leading to a more performant solution which is extremely robust.

Totally Reusable Web Services

Once data or business logic has been configured once as a Web Service, it can be reused again and again by further application development or integration projects. No further configuration or programming is required as the data or business logic is available in a standard fashion that all technologies can use.

Support Only Required for New Platform Code and Implementation

Once the system is implemented, continuing support is only required for the new client code on the platform where it has been installed. This saves the cost of having support on hand for the code and middleware that runs on the existing platform for the user.

One Simple API to access Data or Business Logic

Once programmers have learned to manipulate one database or application program with SOA Gateway Web Services requests, any other Web Service configured in SOA Gateway can be accessed using the same technique. This saves on training and enables programmers to be more productive with what they know instead of having to continually learn and understand different technologies.

How does SOA Gateway work ?

Depending on the amount of meta data available for a given Adabas file, the SOA Gateway Resource Discovery interface can automatically define the components required to wrap the file as a Web Service. The following outlines the steps required to create Web Services for an Adabas file:

  1. For Adabas, the database is queried to determine what files are defined. The user may then select from the list of defined files and the Web Service will be built based on the field names for the selected files. Again if all fields are not to be shown for a given ADABAS file, the view may be edited and the unwanted fields deleted.

  2. The SOA Gateway control Center can also build views from SYSOBJH offloaded data which, in the case of ADABAS, will result in views with long names.

  3. If there is no meta data available for a given database file, it is possible to build views for a given Web Service with the DataView editor. The physical Adabas file can then be created from the SOA Gateway DataView.

Refer to the Resource Discovery documentation for more information about the above.

Once the Web Services is defined, it may be invoked using the URL based REST approach or it may be invoked using SOAP. SOA Gateway can deliver the WSDL directly to the application or the WSDL may be registered with a UDDI server such as CentraSite from Software AG

Conclusions

SOA Gateway can enable your new generation of Java, .NET and MONO programmers to be instantly productive accessing existing data in other languages. These programmers can get access to existing data in minutes rather than weeks or months as is the case when the traditional approach is taken. No knowledge of the database is required and no footprint is required on the client system. They are simply provided with the URL for the WSDL of the Web Service that they need to access and then have everything needed to work with this data from any Web Service enabled environment.

Recommended reading

The following documentation is provided with SOA Gateway and gives examples and tutorials about how to use SOA Gateway once it has been installed:

Basic:

Intermediate:

Advanced: