Introduction

Would like to explain the CDS concept in simple terms. Intended for audience who might not have explored CDS in detail.

CDS - Overview

• CDS means Common Directory Service. This is a module ( or a library ) that’s developed and shipped part of Integration Server and My webMethods Server
• CDS acts as a simple Directory Service - a User store - where you can create users, roles, map relationships between them
• In simple term, user and role creation and modification are managed by this module or component
• While CDS by itself is a User store, Enterprises have their own User store maintained in AD or other Directory services. CDS can act as a client and connect to enterprise LDAP such as OUD, or AD
• When you configure multiple Directory services, you can sequence it, so the user role evaluation happens in first DS, if not in second and so on.

CDS - Deep dive

• This component or module is there in Integration server (as a library) and MWS (as a library)
• When you install IS or MWS, you can see this under ‘Common library’. It gets selected as a dependency component when you choose IS or MWS in the list.
• Multiple CDS component connected to same Central user schema forms a cluster ( call it “CDS cluster” )
• Example, if you have 1 IS and 1 MWS and these both point to same Central user schema, the 2 CDS components works like a cluster ( we call this as standalone IS and standalone MWS but the CDS component is a cluster by itself as there are 2 instances of it )
• IS and MWS CDS component read/write data in this schema ( such as a new user or role that’s created or deleted )
• When you add a user or role in IS, it is expected to be reflected in MWS instantly. Same way, when you add it from MWS, it is expected to be reflected in IS instantly.
• Both store the information in database tables instantly but how do they reflect it immediately across all nodes of CDS cluster ( such as IS and MWS )? It uses a JMS Provider
• The moment the term JMS provider comes into picture, some might think about either wM Broker or UM. As documentation says, UM works as JMS provider, some may even assume prior to UM it was Broker. It is not the case.
• In the case of CDS cluster, JMS provider refers to either ‘Database acting as JMS provider’ or ‘UM acting as JMS provider’
• Universal Messaging (UM) is not necessary and not mandatorily required for CDS to synchronously reflect CRUD operations on user, role and its mapping.

CDS - How to achieve?

• By updating a config in cluster.xml file, this can be either DB or UM. This file can be modified using getconfig and putconfig commands respectively.
• ‘useDbJms=“true”’ tag must be added in this cluster.xml to make use of database and avoid install/setup/maintain of Universal Messaging just for this purpose (if your estate doesn’t require UM)
  <Cluster useDbJms=“true” clusterId="…”>
• More details on changing the config is available in MWS guide, under the section “Configuring My webMethods Server to use the database for JMS communication”

CDS cluster - Illustration as example

CDS cluster1247×636 92.1 KB

CDS - Event syncs across all nodes of CDS

Event sync across all nodes of CDS, reflecting the data instantly in each of the IS and MWS that are connected to same central schema using Database as JMS provider. UM setup for CDS functionality is not mandatory but provided as another option.

CDS event sync1274×672 97.1 KB