Common Services of the SAFE Architecture Component

From MIKE2.0 Methodology

(Redirected from Common Services of the SAFE Architecture)

The Services Oriented Architecture is enabled by an underlying set of Foundation Capabilities for Information and Infrastructure and Enabling Technologies and is critical for enabling much of the next-generation of complex Business Solutions.

Services Oriented Architectures have typically been developed more for application integration, and are only now coming to the forefront for data integration. They provide reusable capabilities that are loosely coupled from one another; Web Services are only the most recent form technology that is used to construct Services Oriented Architectures, technologies from the early 90’s such as DCOM and CORBA were the first generation of technologies that supported these functions.

The definition of Services-Oriented Architecture itself can be a little confusing, as the story has changed a bit over the years. Whereas it is now common to use ”loose coupling” as a key principle of SOA, earlier implementations involving DCOM, CORBA and RMI did function in this manner. Many of the principles have stayed the same though, tenets of SOA include:

• Services are capabilities provided through a well-defined, executable piece of software.

• Services are self-contained, e.g. they are “black boxes” providing an encapsulated piece of functionality.

• Services are platform-independent in the manner in which they are invoked by a client.

• Services can be “discovered”, e.g. there exists a Repository which contains information about the available services.

There are different types of services in the SAFE Architecture, these described below.

Interfaces Services

In the SAFE Architecture, Interfaces Services encapsulate discrete application functions and expose them via the Common Messaging Model. Although logically seen as one entity, an Interface Service often contains two physical components when realized in an EAI architecture: an Adapter for interfacing to an application and transformation into the Common Messaging Model by an Integration Broker. Interface Service are implemented as either Service Requesters or Service Providers.

Service Requesters

A Service Requestor instantiates a CMM Message in response to an event notification from an initiating system. Each requestor should correspond to a single, discrete business-level notification. Each Service Requestor conforms to the following requirements: Accept notification from a single source system: A new process should be defined for each source system

notification. In general, notifications will take the form of published messages from a source system adapter, but other channels are also acceptable, based on a thorough analysis of the requirements for the interface.

• Perform Application Specific to CMM mapping: This process is responsible for converting the application specific notification format into the outbound CMM format.

• Publish a single CMM Message: The process must send out a single, well-known CMM in response to the source system notification

• Perform additional system data retrieval, if required: If a particular outbound CMM cannot be fully populated by the notification message from the source system, the process may query the source system only to obtain any additional information required

Service Providers

A Service Provider component responds to a request to perform a discrete, business-level transaction. Each service may be composed of a single source system interaction, or a series of sequential or parallel interactions to the same systems. The service is limited to an action(s) on a particular system. Each Service Provider conforms to the following requirements:

• Accept a single CMM Message: The process must accept a single, defined CMM format for inbound messages

Return a status or a single CMM Message: The process must either return a status of SUCCESS or FAIL, or respond with a single, well-known CMM

• Perform CMM to Application Specific mapping and vice versa: The process is responsible for converting the inbound CMM into a format that can be understood by the source system interface. As part of the response, the process is responsible for converting the system reply into the outbound CMM format, if applicable.

• Interact with the source system: The process may interact with the source system, ideally via an application adapter. Various communications channels are acceptable, based on a thorough analysis of the requirements for the interface

• Interact only with a single system: A single process should not interact with more than one system

Business Services

Business Services invoke Interface Services and are implemented as a open capability of an existing application or a service designed and implemented apart from an application. Business Services for Data Synchronization, for example, provide mediation between systems by invoking Interface Services. Business Services are fully reusable and are exposed via the CMM. Business Services are generally integration components and do not provide connectivity to applications. Business Services drives interactions between applications, exposed via Interface Services.

There are different types of Business Services. Mediator Business Services define an overall workflow control process that corresponds to a single business event. The Mediator is generally started by a Service Requestor, and is composed of a set of one to many Service Provider invocations. The Service Providers may be invoked either in series or parallel, based on the requirements of the business process. Each Mediator must conform to the following requirements:

• Instantiated by a Service Requestor: The process must start upon receiving a notification from a Service Requestor. Different Service Requestors may instantiate the same Mediator, provided they share the same CMM.

• Interact only with Service Providers: A mediator process may not interact directly with a source system. All system-level transactions must be performed by means of a Service Provider process.

• Accept and Publish only CMM messages: The process may only receive and send well-known CMM messages. It is also acceptable to receive SUCCESS or FAIL notifications from Service Providers in response to a non-query transaction.

• Transform CMM messages from one format to another: It is permitted for a mediator to interact with different CMM messages. In order to do this, it may be required for the process to convert the CMM from one format into another.

A CMM may not be converted into an application specific format, or vice versa.

• Publish Error and Complete Messages: The mediator must publish an Error notification message whenever a Service Provider invocation fails. In addition, the mediator must publish a completion notification message when the process terminates successfully.

Data Management Services

Data Management Services are specialized Business Services that facilitate data synchronisation. In the past, the functionality provided by Data Management services has been associated with batch data integration and offline data quality improvements. The need for real-time synchronization of data to distributed systems mandates that these capabilities be available for invocation in an event-based fashion.

Delivering these capabilities through a Services-Oriented Architecture means that the same functionality can be invoked in either a batch or event-based basis. Some examples of Data Management Services include:

• Standardisation Services refers to conditioning of input data to ensure that the data has the same type of content and format. Standardised data is important for effectively matching data, and facilitating a consistent format for output data which can be used (and is sometimes required) for transforming data into a CMM format.

• Matching Services refers to the use of probabilistic matching technology to any relevant attribute – evaluating user-defined full fields, parts of fields, or individual characters. Semantic Matching Services operate by assigning agreement weights and disagreement weights to key data elements, based on a number of factors such as frequency distribution, discriminating value, and reliability.

• De-Duplication Services are a variant of Matching Services in which matched records from systems that apply to the same individual, household, event, etc. are used as basis to remove redundant data.

Services Orchestration

Services Orchestration is a key enabling technology of the SAFE Architecture, which improves the efficiency of a Common Services of the SAFE Architecture#Services Oriented Architecture and facilitates the building of Composite Applications. Services Orchestration provides discovery and scripting capabilities that allow is to find services across the enterprise, link them together with orchestration scripts and run the execution of this process with an orchestration engine. Services Orchestration is supported by open and common standards for the development, integration and operations of an enterprise services environment.