Return to Homepage Return to SOA Industry Papers
Business Process Management (BPM) Intalio & The SOA Gateway

This document is intended to give business process engineers, technical architects and project managers a detailed view of how the SOA Gateway can help reuse existing business data and logic within their BPM Projects

This document is distributed for information purposes only and does not form part of or constitute an agreement with Risaris Ltd. Although Risaris Ltd. uses reasonable efforts to include accurate and up-to-date information in this document, Risaris makes no warranties or representations as to its accuracy. Risaris Ltd. may also make improvements and/or changes to this document at any time without notice. The various approaches outlined in this document are put forward in good faith, but it remains possible that individual results may vary. For that reason and in accordance with standard practice, readers are encouraged to test any materials developed on the basis of this paper before putting them into productive use.

INDEX

Introduction.............................................................................................................. 3
The Business Case ................................................................................................. 3
Using the Traditional Approach ................................................................ 5
Using the SOA Gateway............................................................................... 7
The Benefits to this and future BPM projects .................................... 8
Implementing and Using the SOA Gateway ................................................ 9
Installation of the SOA Gateway.............................................................. 9
Registering to use the SOA Gateway ........................................... 10
After the download .............................................................................. 11
Installing and Configuring the SOA Gateway Server ............. 11
Windows Installation............................................................................................... 12
Other Platform Installation................................................................................... 13
Common Configuration Steps ............................................................................. 14
Supporting Multiple Platforms and Operating Systems ........ 14
Creating the Services ................................................................................. 14
Creating Database Services ............................................................. 15
Creating Business Logic Services................................................... 16
Registering Services in a UDDI Server........................................ 17
Using the Services in your Intalio BPM project ................................ 18
Using the Services Directly (without a UDDI Server)............ 18
Using the Services from a UDDI Server).................................... 19

1. Introduction

The latest effort to map how a business actually works to an IT process is called Business Process Management (BPM). Finally, there is a set of standards and technologies associated with BPM which has the potential to make this dream a reality. These standards are quickly being adopted and there are now a number of implementations available including the suite of products from Intalio. The Intalio suite includes a designer, for designing the business processes and a BPMS engine for running the business processes once deployed. One of the issues that has not been addressed fully to date is how the BPM technologies can reused existing, and more importantly, working databases and applications that support the business today. The SOA Gateway solves that problem quickly and in a cost effective manner. This paper discusses how the Intalio software suite and the SOA Gateway can help you to implement standard BPM processes fully integrated with your existing IT systems in a cost effective manner.

2. The Business Case

It is clear that the implementation of business processes controlled by an IT infrastructure, such as BPM, can provide many tangible and measurable benefits to a business:

  1. The simple task of mapping existing manual or semi manual business processes using the Intalio Designer tool can highlight issues with existing manual processes that will lead to the streamlining of business processes in general.

  2. Business processes controlled with IT implementations empowers the business to take control of their business processes and implement change in a structured and standard way.

  3. It is possible to measure automatically how effective the business process is, where there are problems in the process and such problem processes can subsequently be improved.

  4. The measurement of the execution of each process can provide a business with real metrics upon which to base assumptions in their business plans going forward which are factual assumptions as against ‘ball park’ figures.

  5. Employees can be compared to each other to determine if specific employees are performing or not. Obviously there will be some variance between different employees but people operating out of the normal variance can be tackled based on real figures. This may help to identify where an employee needs help in the best case and employees that are just not pulling their weight in the worst case scenario.

  6. Business processes implemented correctly can eliminate mistakes which in many cases are more costly to repair than the original task. The employee can be prevented from taking a process forward until such time as they have correctly followed all the required steps.

  7. This further leads to a reduction in the effort to train new people as they can be trained on the job safe in the knowledge that the system will not allow them to make a mistake.

  8. With society unfortunately becoming more litigious, BPM provides the tool to accurately record that an organization is correctly following a process and thus reduces the likelihood of being sued.

  9. BPM gives the business the agility to change its processes based on its priorities and requirements without the requirement to always coordinate with IT. This means that sales campaigns, ad hoc changes can be made quickly and easily to reflect the current market conditions as seen by the business.

  10. BPM implemented properly can almost totally remove the dependency for changes to the system on a central IT Function.

While it is clear that all of the above will be incredibly beneficial to the business, there are still many business challenges:

  1. In any existing business, applications and databases will already exist to run the business from day to day with manual or semi manual processes.

  2. The likelihood is that these systems will continue to support the business for some time to come as it’s not possible to go with a big bang approach. Therefore parallel running for some period of time will be required.

  3. The new processes must implement seamlessly with the existing systems so that a business processes initiated by the BPM process can be completed by the original process and vice versa.

For this reason, reuse of existing data and business logic is the key to a successful BPM implementation:

  1. The BPM implementation must interface with the existing data so that the data upon which the business is built is available to both old and new processes.

  2. it must reuse existing business logic as duplication of this logic in different places is likely to lead to different results depending on which process is used.

  3. The existing system and new BPM implementation must continue to run in parallel at least until personnel are trained and moved across to the new system, but more likely until the parallel running of the systems shows that both systems produce the same result.

  4. Clean interfaces between the new and existing systems will lead to flexibility to change the processes as required and resilience when they are changed.

  5. Reuse enables the process owners (i.e. the business) to work to their priorities and timescales while the technology owners (i.e. the IT department) can work to theirs.

  6. Existing staff can generally move seamless to the new BPM solution due to their familiarity with the back end systems and older processes that were used.

  7. The business owners and IT owners can evolve separately as competing demands allow.

With this reuse in mind, it needs to be noted that very few projects are approved and implemented without a cost benefit analysis and a view of the return on investment (ROI) from the project. This leaves many projects extremely sensitive to the cost of implementation. The Intalio product suite provides an extremely cost effective platform for a BPM implementation, however, reuse of existing data and business logic is still the Achilles heel of most of these projects. Ultimately the challenge is illustrated in the following diagram: how can the new

This section illustrates how the SOA Gateway can now make it possible to use a fully integrated approach for Intalio BPM projects which need limited access to existing data and business logic in a cost effective manner.

2.1. Using the Traditional Approach

It is possible today to use integration infrastructures to get at data and business logic, however, each platform and language generally has its own mechanism to access the core asset. For each different type of database or code, or even different version of these, the mechanism for getting at the data can differ and require different approaches from the application that needs to see the data. We end up with architecture like the following:

This leads to the following issues with this approach:

  1. Each different type of access requires installation and configuration initially along with a maintenance cycle to keep the software up to date.

  2. The format of the data may be different on each database or in different chunks of business logic. For example, a person’s nationality may be marked as ‘IR’, ‘UK’ or ‘DE’ on in one context whereas it will be ‘Ireland’, ‘United Kingdom’ or ‘Germany’ or even ‘1’, ‘2’ or ‘3’ in another context. This means that the application developer must have knowledge about the database being accessed and the schema in use on that database or that being used by the business logic.

  3. Securing architectures such as these is extremely difficult as it adds significant effort to the configuration and maintenance of the systems in order to ensure that only those authorized to access the data or business logic can do so.

  4. Each mechanism is different so the application developers need to learn different ways to access different systems. As the number of different databases or languages grows, the problem to access them grows exponentially as different technologies can give different results for what looks like the same question.

  5. In this case, it is quite clear that having a single, standard technology to access any database or business logic would alleviate all of these problems when it can be done in a cost effective manner.

There is also another issue in that the traditional integration technologies available today to achieve this are prohibitively expensive. It is difficult to justify the cost of purchasing a traditional integration suite just to get at small amounts of data or existing business logic. This sometimes leads to the following approaches to enable such projects to proceed:

Where access to existing data is required, in many cases the data is replicated at regular periods to a database which is easily accessible from the BPM project. In some cases, a simple copy of the data is made and put into a database accessible from the BPM project. While cost effective, it can lead to many problems down the road such as the following:

  1. Even when data is replicated, unless there is 'real time' replication of updates, the data is out of date as soon as it has been replicated. 'Real time' replication software suites are as expensive if not more so than the integration suites which could not be used in the first place for cost reasons.

  2. If data is updated by the new system, it will be necessary to continually sync up the new data with the data in the original system. This type of activity is fraught with danger which can lead to lost data, duplication of data and so on.

  3. When the data format of the existing database is changed, it can have a negative impact on the new system which may be totally dependant on the older format.

  4. It is clear that the preferred solution would be to get to the data directly if this can be done within the budgetary constraints of the project.

Where existing business logic to implement functionality is available but cannot be reused as the language or location of the code is incompatible with the new system, the logic is sometimes rewritten in the newer language. This leads to the following problems:

  1. If the existing code has a dependency on data in a specific database, this data must also be made available to the new code. This causes issues highlighted in the previous discussion.

  2. If the original code is changed, the same change must be implemented in the newly created code so there is more testing required ensuring that both implementations give the same result.

  3. It is likely that different skill sets will be required to maintain both copies of the code thus adding to the cost of this solution over the longer term.

  4. It is clear that the ultimate solution to this problem would be to access the existing business logic if this can be done within the budgetary constraints of the project.

2.2. Using the SOA Gateway

The SOA Gateway can resolve all of the issues outlined in the previous section. The following

By exposing existing data and business logic using proven industry standards, the SOA Gateway provides a cost effective way to go directly to the existing data and business logic as follows:

  1. Once the SOA Gateway is installed, it literally takes minutes to define the services within the SOA Gateway to make your existing data and business logic available as services.

  2. Once the service is available, it can be used as a SOAP based Web Service or via a URL (REST) based access which means that the service can be accessed by Intalio|Server along with any language or technology available today such as Excel, Word, InfoPath, Java, vb.net, c#.net and so on.

  3. The SOA Gateway requires no software installation on the machine that needs access to the database which saves time in terms of installation and maintenance going forward. In other words, Intalio|BPMS and the SOA Gateway may be updated independently.

    1. The Process Designer will use one standard way to get at the data or business logic. Once they have accessed one service, each other service will be identical (except of course for the data) and thus the designer needs to know nothing about what database or structure

    2. has been implemented in the database itself. They will need to know nothing about the language in which a piece of business logic that has been exposed as a service has been written.
  4. The SOA Gateway uses standard technologies and can thus use the most up to date security standards available today. This means that the data and business logic can be secured using the Secure Sockets Layer (SSL) technology which is the standard in this area.

  5. The SOA Gateway interfaces with existing security systems. This ensures that existing security rules, which have been built up over many years, are still enforced for requests coming through the SOA Gateway. In effect, the SOA Gateway maps an ‘internet credential’ to something the local system where the database or business logic is running can understand

  6. The SOA Gateway can map database or language internal types to well defined external types. This means that the data can be normalized so that process designers are dealing with the same type of data no matter what database or language is being accessed. For example, taking the nationality field again, the SOA Gateway can map the internal representation into an agreed external format and ensure that the nationality field from each different core asset uses the same external format no matter how the internal format looks.

  7. Once created, a service may then be registered with a UDDI server. Examples of such servers are CentraSite from Software AG, the Systinet registry from HP and the OpenUDDI server available as open source. This means that a central repository of all available services can be maintained electronically and future requirements for these services may be satisfied using that repository.

  8. Once a service is available, it can be used again and again from any number of systems at no additional cost.

  9. The SOA Gateway license model is based on usage so even though the full power and facilities of the technology are available, you only pay for what you use. It’s possible to pay for units of 5 services per year. For example for a cost of 400 Euro per year, it would be possible to expose 5 database tables, 5 applications programs or a mixture of both as services.

2.3. The Benefits to this and future BPM projects

It is clear that BPM projects requiring limited access to existing data and business logic benefit through the simple, quick and cost effective ruse of existing assets. This can occur directly with no requirement to make copies of data or business logic.

The services created for an initial project can be reused again and again in later projects no matter what language they are being developed in or what technology is being used. The services are future proofed in that they will interface with any technology on the horizon at the moment.

As the infrastructure is 100% based on standards, your installation will also benefit from run time governance, policy driven processing and standards based security out of the box. As new standards or best practices emerge, these will be added to the SOA Gateway without any changes to your applications.

In addition, the license model ensures that licensed customers are entitled to all of the new developments and improvements that are made in later versions of the SOA Gateway. This means that the full power of the technology is available if you continue to use it with a small number of services or if it is used on an extensive basis in your projects.

3. Implementing and Using the SOA Gateway

The SOA Gateway has been designed to be as simple as possible to license, install and use in your projects. The following steps can generally be completed in a half a day or less at which point, it is possible to continue creating services from your existing core assets in minutes. In general, the following time is required to start working with the SOA Gateway:

  • Registration and download: 30 minutes (depending on the speed of your connection to the Internet)

  • Installation of the SOA Gateway Control Centre and one SOA Gateway Server: 1 hour (depending on target platform and speed of the link to that target platform)

  • Creation of services: <1 Minute per service

3.1. Installation of the SOA Gateway

The SOA Gateway consists of two distinct pieces of software.

  1. The SOA Gateway Control Centre is an Eclipse plug-in that runs in Eclipse. Eclipse and this plug-in are contained in the package downloaded after you register.

  2. The SOA Gateway Server is installed as a stand alone component on the platform where the data or business logic that you wish to expose is running. The server implementation for all available platforms is also included in the package downloaded after you register. The SOA Gateway Server can then be deployed to each target server using the SOA Gateway Control Centre.

The installation of the SOA Gateway requires that you register for a license for the SOA gateway and download the installation materials. There are free licenses available for most uses with some limitations on commercial usage.

3.1.1. Registering to use the SOA Gateway

You must register to use the SOA Gateway here as illustrated by the following screenshot.

Once you have filled the details in on the above screen and hit the ‘Register’ button, a confirmation email will be sent to the email account with which you registered. When you have received that email and confirmed the email address, a second email will be sent with a link to continue the process and a license file attached. This link will give you further information about the installation process and will start the download of the SOA Gateway installation materials to your local PC.

This download is approximately 250 Meg and how quickly this downloads will depend on the speed of your link to the Internet.

3.1.2. After the download

Once you have downloaded the package, you are ready to begin installing the SOA Gateway. The next steps are documented in the email sent to you after you have confirmed your registration. Once you have completed those steps, your configuration will look like the following:

3.1.3. Installing and Configuring the SOA Gateway Server

Once the SOA Gateway Control Centre has been started in Eclipse, you will need to install the SOA Gateway on the target platform. This is a little different depending on your target operating system:

Windows Installation

On Windows, the SOA Gateway Control Centre must be installed on the Windows system where you wish to install the SOA Gateway server. When you select that you wish to install the SOA Gateway server on Windows, the Control Centre will launch the Windows Setup program on the local machine and the SOA Gateway server installation and configuration steps are managed by that setup script.

Once the setup script has completed, you will be returned to the Control Centre Deployment Wizard.

Note that the Eclipse running on the Windows server is only required for installation. This server can subsequently be managed and configured from a remote administrators PC in the same way as other platforms.

On all other platforms, the SOA Gateway Control Centre will FTP the required installation materials to the target system.

Once the FTP has been completed, you must logon to the target system to run a short script or a number of jobs to complete the installation process. These are documented in the installation documentation for the platform where you are installing the SOA Gateway Server. Once this has been completed, return to the control centre to complete the process.

Common Configuration Steps

Once the SOA Gateway Server is running, it is possible to test if the Control Centre can communicate with it from the current screen in the deployment wizard. Once this communication is ok, you just need to hit the configure button. This will install and configure each of the licensed SOA Gateway data source drivers in your server environment. Where additional installation specific information is required, this will be requested during this process. Please refer to the documentation for more details on what may be required for each of the data source drivers.

Once the configuration step has been completed, you are ready to start creating services.

3.1.4. Supporting Multiple Platforms and Operating Systems

It is possible to deploy and install the SOA Gateway server on multiple machines where access is required while monitoring these from the one administrators PC as per the following architecture:

3.2. Creating the Services

The creation of services is achieved from the SOA Gateway Control Centre and is a 3 step process.

  1. The SOA Gateway can discover what resources are available for a specific data source for which services can be created.

  2. The Meta data for those resources is identified and used to create what is required by the SOA Gateway.

  3. The service definition is deployed to the SOA Gateway Server and is ready for use.

Risaris Limited also recommend an additional step which is the registration of the WSDL in a UDDI server such as CentraSite from Software AG, the Systinet registry from HP or the OpenUDDI server available as open source, however, this is not required to use the service.

3.2.1. Creating Database Services

Database services are created by simply following these steps:

  1. Identify the database from which you wish to create services.

  2. Provide the database name.

  3. The SOA Gateway Server will return a list of tables or files available on that database as per the following:

  4. Select the tables for which you wish services to be created and hit the continue button.

  5. The wizard will create services for each of the tables you selected and deploy these services to the SOA Gateway Server. These services are now available for use.

3.2.2. Creating Business Logic Services

Business logic services are created by simply following these steps:

  1. Identify where the application which provides the business logic is implemented (e.g. Natural program, CICS application, Windows DLL etc.)

  2. Provide the location of the application.

  3. The SOA Gateway Server will return a list of applications available at that location.

  4. Select the applications for which you wish services to be created and hit the continue button.

  5. Provide the source file for each service to be created.

  6. The wizard will create services for each of the applications you selected and deploy them to the SOA Gateway Server.

  7. Risaris recommend that you review and modify the input only, output only and input/output fields for each service based on your knowledge of the application requirements.

  8. These services are now available.

3.2.3. Registering Services in a UDDI Server

The services you have been created can be registered with a UDDI server as follows:

  1. Define your UDDI server to the SOA Gateway Control Centre (must only be done once).

  2. Select the SOA Gateway services to be registered.

  3. Provide the information required by the control centre Wizard until the registration is complete.

3.3. Using the Services in your Intalio BPM project

How the services are used will depend on whether you have used a UDDI server or not.

3.3.1. Using the Services Directly (without a UDDI Server)

  1. The Intalio Designer is provided with a WSDL location.

  2. The process engineer will use the service in one or more of their new business processes.

  3. The Intalio Designer will deploy the business process.

  4. The new or updated business process is available for use.

3.3.2. Using the Services from a UDDI Server)

  1. The Intalio Designer is provided with the location of the UDDI server.

  2. The Intalio Designer selects from the UDDI Server the service that they wish to use.

  3. The UDDI server provides the location of the WSDL.

  4. The Intalio Designer will import the WSDL from the SOA Gateway server into their project.

  5. The process engineer will use the service in one or more of their new business processes.

  6. The Intalio Designer will deploy the business process.

  7. The new or updated business process is available for use.

    For more information visit: www.risaris.com or email john.power@risaris.com

    © Risaris 2008
    Soagateway.com - Soa Gateway is a software tool used in soa projects, data application, soa gateway projects, data application, web applications, php applications, legacy migration, legacy data, legacy systems and data access integration.
    www.soagateway.com

    Return to Homepage Return to SOA Industry Papers