NextGen Consulting

AIF Overview

Amdocs Integration Framework provides a common, uniform and standards-based integration foundation for implementing integrations between Amdocs applications, and integrations between Amdocs applications and non Amdocs applications. 

AIF Characteristics

• Portable across application servers (WAS & WLS)
• Integrate / interoperate with Enterprise Service Bus (ESB)s/EAIs
• Provide protocol – neutral service invocation API
• Service definition customization and upgrade
• Leverages standards and pervasive technologies
• Uses existing integration foundations as much as possible
• Allows gradual adoption by Amdocs products

 

AIF Architecture

AIF is a cross portfolio foundation platform – there is no UI. It is tightly integrated with other cross portfolio foundations:

• APM  (Amdocs Process Manager) for composite operations
• ASC   (Amdocs System Configuration) for system configuration
• ASM  (Amdocs Security Manager) for security to enable cross portfolio single-sign-on

 

 

AIF Integration with 3rd Party

AIF provides an abstraction layer that enables application code to execute functionality provided by external components or systems in a protocol-independent manner. It supports the following protocols

• Local Java (POJO)
• Local & remote EJB (statefull and stateless)
• SOAP over HTTP (Web services)
• Tuxedo
• Asynchronous one way (JMS)

Services are defined in a central Service Repository and are managed via a service management UI

AIF provides data mapping, logging, auditing and monitoring infrastructure independent of the application code. A simulator is provided to facilitate client unit testing. It is monitored by JMX.

 

 

AIF Components

AIF infrastructure components include:

• Service Repository UI – 
  A central tool for defining, maintaining and storing Amdocs service definitions
       
• Service Repository
  Holds detailed technical descriptions of services. Service definitions are stored on disk files and deployed to the database for access by the consumer API infrastructure
    
• Service Consumer
  A protocol-neutral API for invocation of services
      
• Service Provider
  Code generation tool for exposing services via standard protocols: EJB, JMS, SOAP over HTTP, SOAP over JMS, POJO
      
• AIF can export its service definitions to any UDDI registry using the published UDDI API. However, it does not provide a UDDI compliant registry
    

 

 

 

Service Repository UI Components

Operation
A business operation is a discreet function that performs a single task. Operations are passed input parameters, and may optionally return output parameters, and faults. An operation corresponds to a Java method

Signature
These are the input, output and faults parameters which are defined for an operation. The signature refers to the names and types of these items, but not to any specific order (parameter ordering is typically required only for RMI protocols).

Interface
A logical grouping of operations. An interface corresponds to a Java class or interface.

Service
Published functionality provided either by an Amdocs application or an external system. A service is an implementation of an interface provided by some service providers. It is a  physical implementation of an interface (e.g. EJB service)

Binding

A physical attribute for an operation of a service;. e.g. EJB bindings define the method name and parameter order

 

The Service Consumer

Consumer application code uses the service consumer API to invoke a service operation. The consumer is unaware of who provides the service, where they are located, or how the service is invoked.

The Consumer supports the following protocols: POJO, EJB, JMS, Web Services and Tuxedo. Logging, auditing and monitoring is performed by the infrastructure. Details about the service are read from the service repository. Physical details (server URL etc) are taken from runtime configuration

The Service Repository

The Service repository defines operations, interfaces and services

Service definitions are defined in XML files, and deployed to a database for access by the service consumer API infrastructure (in CRM, the database table is aif_operation)

Service Definitions are edited using an eclipse plug-in. They can be created manually, by importing EJB interfaces or by importing WSDL.

The Service data model is based on WSDL2.0.

The services repository is fully compatible with 3rd party service repositories or registries via WSDL import/export and Java code (EJB interface)

Service Definition

A Service is physical implementation of an Interface. The Service name is unique within an Interface. Each Interface may have several Services, each representing a physical implementation of the Interface

Binding represents physical attributes of an operation within a Service. Each Operation within the Interface has a corresponding Binding within each Service.

Services are defined in two parts:

1. Static design-time definition which define the contract, implementation and protocols.
2. Dynamic run-time deployment configuration, defined in the AIF repository.

The AIF repository stores information such as JNDI names. These names are defined in the central configuration repository (Amdocs System Configurator – ASC)

The run-time configuration data can be changed independently of the AIF repository, giving operational flexibility.

 

AIF Configuration

AIF uses ASC to define its configuration items. AIF configuration includes AIF internal configuration, such as the JDBC connection it requires to access the deployed services, and definition of resources used by services defined in the repository

AIF is typically configured in some common node, and then inherited by the applications that use it:

/amdocsCommon/Aif

/crm/baseConfig/Aif (inherits /amdocsCommon/Aif)

 

 

The AIF Service Lab

The AIF plug-in for Eclipse provides a full blown UI for creating, testing and deploying AIF services.

02/03/2011 - Posted by Yuval R. | Amdocs, Backend, CRM, General, Technology