Integration Model Editor

The Integration Model (IM) Editor is a groundbreaking new region of PHENOM that combines visualizations with direct model editing.

The Integration Model is perhaps the most important model of them all. It provides a representation of how your UoPs and communication channels are laid out in the physical world.

A well-designed IM is what allows us to generate a fully configured CinC transport layer.

UoP Instances

UoP Instances are, as the name suggests, instantiated Units of Portability. They can be created from the IM Editor or from the 'Create' dropdown in regular Navigate mode.

Each one is given a name and a Configuration URI. You are also expected to select some subset of the UoP's Connections to use as Endpoints in the UoP Instance.

IMAGE

Transport Channels

A Transport Channel holds information required to transmit across some outside channel.

Currently UDP channels are supported.

At the moment, you are expected to use the description field to populate the following comma-seperated values: ip, local port, destination ip, destination port, ttl.

Integration Contexts

This is where we find the real meat and potatoes of your integration situation. A Context is a graph representing the flow of DataTypes, or Views, amongst UoP Instances.

A given context can pull in the items discussed above. In fact, a given UoP Instance might be used in multiple Contexts. The different Contexts simply illustrate different aspects of the layout.

The IM Editor lets you work on one Context at a time. First, drag and drop to insert a UoP Instance. (Technically, the UoP Instance exists outside the Context, but since it's connected to things inside, it will be useful to have it here).

Transport Nodes

Transport nodes come in several flavors which can be created by dragging and dropping from the Stencil tool on the left-hand side.

IMAGE

Once placed in the Context, the Node Inspector on the right-hand side is used to give the nodes names, descriptions, and other data specific to its type.

IMAGE

• Sources / Sinks have only one port. These represent elements that simply produce or consume Views.
• Transforms consume one type of View and produce another. The Node Inspector is used to adjust settings. Notably, the Transform type is used to change from A) an Automatic transform that draws on semantic and measurement information to mediate between the two Views:

IMAGE

, and B) manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code:

IMAGE

• Filters require a 'Test' field that will filter out Views for which the test evaluates to False.
• Transporters allow you to select a Transport Channel to transmit across.
• Data Pumps periodically poll the previous block to move messages forward.

  The Adapter blocks allow interoperability when the UoP Message Port is expecting a certain kind of communication style.

• SIMAdapters for Single Instance Messaging communication style.
• QueuingAdapters for Queuing communication style.

Connections

Connections are created by dragging from an output port to an input port:

IMAGE

If the data types are inconsistent then the connection will turn red and you won't be allowed to save. In this situation, we have a Transform node outputting ComplexTypes, and sending it to an Endpoint expecting BasicTypes:

IMAGE

Code Generation

CinC generation targets a different type of element called a Main Program. These are created from the main 'CREATE' dropdown.

IMAGE

Once your Main Program exists, you can associate UoP Instances to it so they become part of the generated code.

IMAGE

Similarly, Main Programs can be placed in Processing Elements - but these are not incorporated into generation yet.