iMIS Services Architecture

A diagram of the internal architecture of iMIS SOA can help in understanding how iMIS operates in several layers. While application developers work with the web services and transport clients only, a basic understanding of the underlying implementation will be useful for future topics as SOA becomes integral to the overall application. The ASI services or resources are the same regardless if you access them using the REST or SOAP transport client.

The iMIS database communicates with the ASI services through the ASI Scheduler. iMIS SOA and Process Automation are hosted on ASI Scheduler. You can access the iMIS SOA web services using either the Representational State Transfer (REST) or Simple Object Access Protocol (SOAP) transport client. The client you use will depend on your iMIS edition and the application you are creating.

An entity is a representation of a data model in SOA such as a party or person, an event, or a group. An entity will always be represented in a data contract. No matter how the data is stored, processed or saved in the database, the client and the server will always communicate data using a predefined data contract.

Presentation

The presentation layer represents the client application or UI that interacts with the model through web services. All iMIS dynamic content items (iParts) are an example of the presentation layer.

Client applications work either with the service layer directly or with the client services layer.

Client Services

Client services are a simple remote façade to the service layer. The client application does not see any implementation details below the service layer. The actual API for common operations (such as Find or Add) is at the service layer.

Data Contracts

Data contracts are common between the client services layer and the service layer; they can be used up and down all layers, if needed.

Service

The top-level service implementation (the EntityService) works with the domain layer directly rather than the persistence layer.

Domain

The domain layer provides a consistent interface to the service layer through repositories, and provides high-level unit-of-work in-process object tracking (such as dirty objects, objects that need to be added, and objects already read). Repositories, which are domain-level devices, interface with persistence strategies to do basic input and output operations.

Domain-level objects are those objects retrieved by the persistence level. In some cases, we can use data contract classes for instances of domain objects, but sometimes they are different, unique domain-level classes. That is, domain-level objects might include additional properties and methods that are important to the underlying implementation but are not exposed in the data contract at the service layer.

Therefore, most data moves up from the persistence strategy into intermediate domain-level object instances and are eventually translated to data contracts at the service layer. Of course, it all returns the other way as well. The service layer deals with data contracts on the API side and domain objects on the domain side.

Persistence

The persistence layer contains the persistence strategies, which define how domain objects translate to an underlying data store. Persistence strategies might work with SQL source or other intermediate devices, such as iBO, Intelligent Query Architect (IQA), Business Object Designer (BOD), and even other web services. Persistence strategies, such as LINQ to SQL persistence strategies, can utilize LINQ mapping classes or dynamically generated classes for transient persistence instances.

Data Store

The data store layer represents the underlying device for how data is persisted. In the case of iMIS data, this generally means an SQL database. Multiple implementations can share the code at the domain level.

All code at the domain level and above can be shared, or is identical, for multiple implementations.

Summary

There are usually the following kinds of instance objects:

Manager Helpers — Helper classes in the Client Services layer that simplify common operations
Service-layer instances of data contracts — Translated to domain objects when executing requested service operations
Domain-level objects — Not exposed in the API
Persistence-layer objects — Not exposed in the API

As an example of how objects are instantiated, a typical update occurs as follows:

At the service layer, the current instance of the domain object being updated is retrieved through the persistence layer.
The service layer applies the requested updates from the instance of the client data contract.
The domain object is persisted back. Typically, the service layer cannot update all properties of the domain object directly.