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.

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.

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.

• 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:

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

• 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.
• Fanins allow for several input connections and only outputs one type.
• Generics can have any number of input or output connections.
• SIM Adapters for Single Instance Messaging communication style.
• Queuing Adapters for Queuing communication style.
• 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.

Connections

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

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:

Composed Block Integration Contexts

The composed block integration context is a special kind of context that can be nested inside another context of any type, treating it as a context node via a composed block instance.

Any high-level context can include a composed block instance to simplify complex modeling and connections. This setup lets viewers understand the overall flow without getting overwhelmed by the modeling details held within the composed block context.

Switching an Integration Context to Composed

A context can be switched from normal to composed from the context tab from within the side panel. Once switched, the context will obtain a blue border and allow access to the composed ports. Composed Block contexts will behave similarly to the

Composed Ports

From within the composed block context, the user may drag in any number of Composed In/Out port nodes. The composed ports nodes have only one respective input/output port and can be connected to the other context nodes. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).

These composed port nodes are identical to the ones utilized by a composed block instance.

Composed Block Context Instances

After the user is finished creating their composed block context and either saves or commits it, the composed block context can be seen in the NavTree and is ready to be dragged in as an instance to another context of any type.

Once dragged in, it behaves like the other context nodes and can be connected to any of the other nodes and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.

Code Generation

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

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

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