Data flows = AssemblyLines
Each data flow in the solution is implemented as an Security Directory Integrator AssemblyLine, also abbreviated as 'AL' in this and other literature.
ALs are ordered lists of components forming a single, continuous
path from input sources to targets. Built-in behavior provided by
the kernel ties the components together and passes data carried in
the Work Entry from one to the next.
It's said that a picture is worth a thousand words, and the diagram
above is no exception. The three puzzle pieces represent Connectors
linked together to form an AssemblyLine. The darker 'stem' of each
puzzle piece highlights the data source specific part of the Connector
– that is, the interface to the connected system – known
as the Connector Interface (abbreviated as 'CI'). The lighter colored remainder of each puzzle piece depicts the generic
functionality of the kernel that makes all components work in a similar
and predictable fashion, enabling them to be linked together and providing
automated patterns of behaviors with control points for customization1.
This picture illustrates a few more important concepts. For example,
in addition to the Work Entry shown above flowing from component to
component down the AssemblyLine, there is an additional Java "bucket" nestled in each of the Connector
Interfaces. Each local Entry object is used to cache data during read
and write operations performed by that CI, and is called its Conn
Entry.
Now notice the curved arrows illustrating data flowing between
the various Conn Entries and the AL's Work Entry. These are Attribute
Maps and each one represents a set of rules for data movement
and transformation on its way either in or out of the AL. Those that lift data from a Conn Entry into the Work Entry are named Input
Maps since they determine what data is brought into the AssemblyLine.
The arrow in the rightmost puzzle piece that shows data moving in
the other direction – from the Work Entry to the Conn Entry – is called
an Output Map.
Since there is only one Work Entry at any time, we can deduce
that AssemblyLines process one item at a time: for example, one database
row, directory entry, MQ message, and so forth. This is another important
aspect of SDI, and although an AssemblyLine
can cycle hundreds or even thousands of Entries per second2, it's an important
consideration when designing the solution. It is of course possible
to spread work across multiple AssemblyLines, and you will find this
and other techniques for optimizing AL performance in other SDI literature.
1 As
we can see, every AssemblyLine component reflects the kernel/component
architecture of SDI. If you decide
to make our own component, it is only its interface that you have
to implement. The AL "wrapper" and its wealth of built-in functionality
are available automatically, courtesy of the SDI kernel.2 Performance
will depend on the design and complexity of the AssemblyLine and the
configuration of the machine running the Server.
Parent topic:
The basics of solution design