Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Template-Driven SOA Topology Definition and Creation

IP.com Disclosure Number: IPCOM000178022D
Original Publication Date: 2009-Jan-13
Included in the Prior Art Database: 2009-Jan-13
Document File: 6 page(s) / 638K

Publishing Venue

IBM

Abstract

A typical SOA or middleware environment involves many services and components which are to be deployed and configured across a distributed computing system. Topology design needs expertises which is hard-to-find. To come up a good topology for the distributed services and components needs deep domain knowledge which common users might not have. Consequently, this impacts the SOA topology consumability and usability. Topology setup is hard even for experts, let alone common users. It is always a challenge to deploy and configure the services and components properly as it has to be done manually and is very time-consuming, tedious, error-prone, non-portable, and replicatable. This greatly hampers the topology consumability and usability as well. To address these issues, this invention provides a way for users (domain experts) to define the common topology use cases and abstract them in topology patterns and document them in topology templates. Also provided is an extensible mechanism and framework to automate the deployment and configuration of the involved services and components.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 26% of the total text.

Page 1 of 6

Template-Driven SOA Topology Definition and Creation

Main Idea

A typical SOA or middleware environment involves many services and components which are to be deployed and configured across a distributed computing system. For example, a service fabric might be made up of many individual loosely coupled services which might have to be deployed and configured independently on an array of hosts. Currently this type of topology creation and setup has to be done manually and ad hoc.

Another more concrete example is to set up WebSphere Process Server (WPS) and Websphere Enterprise Service Bus (WESB) in a Network Deployment (ND) environment. Many topology variations need to be considered, and many WPS services and components need to be deployed and configured. Consequently, the WPS ND environment setup is one of the major pain points identified by the customers and service people as setting up such environment requires tremendous amount of domain knowledge. In addition, even for experienced users, the ND setup is very time-consuming, tedious, error-prone, non-portable, and replicatable.

In summary,
Topology design needs expertises which is hard-to-find. To come up a good topology for the


1.

2.

1.

2.

1.

2.

3.


4.

distributed services and components needs deep domain knowledge which common users might not have. Consequently this impacts the SOA topology consumability and usability.

Topology setup is hard even for experts, let alone common users. It is always a challenge to deploy

and configure the services and components properly as it has to be manually and is very time-consuming, tedious, error-prone, non-portable and replicatable. This greatly hampers the topology consumability and usability as well.

To address these issues, this invention provides:
a way for users (domain experts) to define the common topology use cases and abstract them in

topology patterns and document them in topology templates, and
an extensible mechanism and framework to automate the deployment and configuration of the

involved services and components.

The major benefits are:

With the topology pattern and template definition specification, the template authors (likely domain

experts) can easily abstract and document common use cases as patterns and templates. The abstracted topology patterns and templates will capture the domain knowledge, like the deployment and configuration requirements and constraints, etc.

The template users (likely administrators) are able to create the topology instance based on the

templates and do necessary mapping and provisioning, which are mostly guided and automated. The templates and instances can be ported and reused.

The templates and instances can be easily edited and extended.

1

Page 2 of 6

Figure 1 block diagram shows how the solution works.

Figure 1. the solution overview.

Main concepts -


Deployment Target - A dep...