business without boundaries

n

Business without Business without BoundariesBoundaries

by nBoundary Software Inc.

nnTegratorTegrator

n

Viewing InstructionsViewing Instructions• This presentation is partially self-running. No action is

necessary until a “next” button appears in the lower right corner. Then click (or tap the spacebar) to move to the next slide. Some animations will not work correctly if you are using a version of PowerPoint earlier than 2002.

• When the “Sample System” button appears in the lower right corner, click it to view the linked presentation of a sample nTegrator application. Otherwise click anywhere to move to the next slide in this show.

• To review any part of this show, type 99<enter> then select from the list of topics. You can also view the Sample System from that slide.

• Some parts of this presentation may not be self-explanatory. Additional explanation can be found in the White Paper: “nTegrator: An Introduction” available at www.nBoundary.com.

SampleSystem

n

• Rapid application development toolkit.• Simple, reusable components.• Any data, in any form, from any source.• Distributed, secure systems.• Totally top-down applications:

– top-down specification– top-down design– top-down implementation

• Drop-in functionality without recompilation.• Simple in concept and use.

nnTegratorTegrator

Each copy of nTegrator manages specialized nTegrator objects

In an active system, there are a number of objects associated with each copy of nTegrator.

nTegrator is a small piece of software that resides on any Windows computer

NnnTegratorTegrator

N Objects communicate with each other by passing messages.

Extensible Markup Language is a new industry standard structured data description language.

Internally, all nTegrator messages look like XML documents.

<?xml version="1.0" ?> <xmltest> <Source1> <record loc = 14> <Author>Adams, Pat</Author> <Phone>(403) 555-1235</Phone> </record> </Source1> <Source2> <record key = 77> <Name>John Doe </Name> <Phone>(403) 555-6789</Phone> </record> </Source2></xmltest>

XML messages can contain commands or data or both.

One advantage of the use of XML is the system’s ability to interface directly with the outside world.

N

N

Messages can travel between objects across any TCP/IP network – LAN or Internet.

Application systems built using nTegrator can be distributed across as many computers as desired.

nTegrator objects are programs.

Each object is made up of two types of program.

A Data Transport is a program that moves data.

There can also be zero, one, or many “Agents”.

Agents contain actions that are to be performed on the data.

There is always one and only one “Data Transport”.

Later in the presentation we will see how Data Transports and Agents work together.



Later in the presentation we will see how Data Transports and Agents work together.

21 43 5

C3C3

C1C1

C2C2

21 43 5

C3C3

C1C1

C2C2

nTegrator application systems are built by organizing objects into logical hierarchical groupings called Collections.

In this example there are five low-level objects….

… and three collection objects.

Low level objects usually read or write data to and from sources that are external to the nTegrator system.

They are called Interface Objects.

Collection Objects govern the flow of data through the system.

21 43 5

C3C3

C1C1

C2C2

A Collection “contains” the objects below it in the hierarchy.

This Collection Object…

… “contains” these two Interface Objects.

Collection Object C3…

… contains the three Interface Objects: 3, 4, and 5.

Collection Object C1…… contains these two Collection Objects: C2 and C3.

This hierarchy describes a simple nTegrator system.

21 43 5

C3C3

C1C1

C2C2

This hierarchy describes a simple nTegrator system.

A system starts operating when the highest collection issues a command that establishes a “path” through the hierarchy.

The path is usually a way to select an Interface Object.

The high-level object then sends a command to the Interface Object in the form of an XML message.

The object performs whatever actions it has been programmed to do.

And then it sends a response message back up the line.

Any Agents attached to any objects along the path may affect either the routing or the content of messages that pass through them.

21 43 5

C3C3

C1C1

C2C2

A system starts operating when the highest collection issues a command that establishes a “path” through the hierarchy.

The path is usually a way to select an Interface Object.

The high-level object then sends a command to the Interface Object in the form of an XML message.

The object performs whatever actions it has been programmed to do.

And then it sends a response message back up the line.

Any Agents attached to any objects along the path may affect either the routing or the content of messages that pass through them.

It is the grouping of functionality into collections that enables nTegrator systems to be developed.

It is the dynamic establishment of paths through the hierarchy that controls how nTegrator systems operate.

The information you get depends on the path you take.

The information you are allowed to get depends on the paths you are allowed to take.

21 43 5

C3C3

C1C1

C2C2

It is the grouping of functionality into collections that enables nTegrator systems to be developed.

It is the dynamic establishment of paths through the hierarchy that controls how nTegrator systems operate.

The information you get depends on the path you take.

The information you are allowed to get depends on the paths you are allowed to take.




There can also be zero, one, or many “Agents”.

Agents contain actions that are to be performed on the data.

There is always one and only one “Data Transport”.


In an Interface Object, the Data Transport reads or writes data that is external to the nTegrator system.

If it reads external data, it converts it to an XML message.

If its job is to write external data, it first extracts it from an XML message.

After the Data Transport reads data and before it writes data, the XML message is exposed to any attached Agents.

Agents contain the business logic of the system.


In a Collection Object, the Data Transport acts as a router. It directs XML messages through the hierarchy.

On its “high” side, it has one ‘port’ through which XML messages may pass.

On its “low” side, it has one ‘port’ for each subordinate object that it contains.

If the collection looks like this…

… the Data Transport will have three ‘low side’ ports.

This allows messages to be routed along the “path” selected by the top-level collection.



On its “high” side, it has one ‘port’ through which XML messages may pass.

On its “low” side, it has one ‘port’ for each subordinate object that it contains.

This allows messages to be routed along the “path” selected by the top-level collection.

As in every object, all messages passing through the Data Transport are exposed to any attached Agents. These act on the messages in whatever way they have been programmed.



As in every object, all messages passing through the Data Transport are exposed to any attached Agents. These act on the messages in whatever way they have been programmed.

Agents can do anything a program is capable of…… analyze data… change data… make decisions… route data… combine data… perform calculations… format data… etc.

Agents may contain system logic or business rules or both.

Standard Agents to perform common tasks such as merging messages are supplied with nTegrator.

Agents are developed using simple scripts.

Agents have the same format in both object types.

Reuse applies whether the component was supplied with nTegrator or was custom developed by the user.

Every Agent in nTegrator is reusable, either within the same application or by a completely different application.

Similarly, every Data Transport is completely reusable.

Complete objects are also reusable.

If an object is reused, new Agents may be added to it. These Agents are only ‘visible’ to the new system, not to the one that originally used the object.

A very significant feature of nTegrator is its ability to permit new Agents to be ‘dropped in’ to existing objects without recompilation of the object.

This can dramatically lower the complexity and cost of building and maintaining applications.

It is so unique that a patent is pending on the way this feature has been implemented.

A very significant feature of nTegrator is its ability to permit new Agents to be ‘dropped in’ to existing objects without recompilation of the object.

This can dramatically lower the complexity and cost of building and maintaining applications.

It is so unique that a patent is pending on the way this feature has been implemented.

New nTegrator applications can easily combine objects from existing systems with new objects, and can use data that resides in existing data stores.

Four computers.

Each runs nTegrator and has a number of existing Interface Objects.

1 2 3 4 1 2 3 1 2 3 4 1 2

N N N N

C5C5C4C4

1 2 3 4 1 2 3 1 2 3 4 1 2

C2C2

Blue objects 1, 2, and 3 are contained in a collection.

C3C3

So are Red objects 2 and 3.

As are Green 2, 3, and 4…

… and the two Orange objects.

N N N N

1 2 3 4 1 2 3 1 2 3 4 1 2

C2C2 C3C3 C4C4 C5C5

C1C1

Collection C1 in Blue computer contains C2, but it also contains object 1 in Red computer.

nTegrator allows objects in one computer to be contained by a collection in another one.

N N N N

1 2 3 4 1 2 3 1 2 3 4 1 2

C2C2 C3C3 C4C4 C5C5

C1C1

We are going to implement a new system on Red Computer.

It will require the development of one new Interface Object and one new collection. Otherwise it will reuse existing objects.

First, the new object is developed.

4

N N N N

N N N N

1 2 3 4 1 2 3 2 3 4 1 2

C2C2 C3C3 C4C4

Then we design and implement the collection. It will contain:

C1C1 4 1 C5C5Collection C1new object Red 4existing object Green 1and Collection C5.

C1C1

1

C5C5

4

C0C0

1 2 3 4 1 2 3 2 3 4 1 2

C2C2 C3C3 C4C4

C1C1

1

C5C5

4

C0C0N N N N

The new collection is C0.

It has reused two existing collections – C1 and C5 – and one existing object – Green 1. It required the development of one new object: Red 4.

When an existing object of either type is reused, there is the option of adding additional functionality to it by dropping in new Agents. These new agents are only ‘visible’ to the new system.

4 2 3 2 3 4

C3C3 C4C4

1

N N N N

There are different paths that may be taken through a collection.

Each path leads to an object that performs some task on behalf of the user.

There are eight possible paths through our new system. They all start at C0 and terminate at a low-level object.

1 2 3 1 2

C2C2

C1C1

C5C5

4

C0C0

1

4 2 3 2 3 4

C3C3 C4C4

1

N N N N

1 2 3 1 2

C2C2

C1C1

C5C5

4

C0C0

1

A typical nTegrator transaction occurs in two phases:

1. The highest level collection object sets up the appropriate path.

2. It sends a message.

When the message reaches the target object, the command is executed. In this example, the object performs credit card verification.

4 2 3 2 3 4

C3C3 C4C4

1

N N N N

1 2 3 1 2

C2C2

C1C1

C5C5

4

C0C0

1

When the object has done its job, it returns a message back up the hierarchy

and the transaction is complete.

4 2 3 2 3 4

C3C3 C4C4

1

N N N N

1 2 3 1 2

C2C2

C1C1

C5C5

4

C0C0

1

Every nTegrator object has ‘permissions’ associated with it.

Each object has ten separate functions for which permission may be granted or denied: read, write, add/remove agents, etc.

These permissions are matched against the user’s authorities to determine what actions may be taken when a message arrives.

4 2 3 2 3 4

C3C3 C4C4

1

N N N N

1 2 3 1 2

C2C2

C1C1

C5C5

4

C0C0

1

For additional security, all computer-to-computer communications are encrypted.

Every copy of nTegrator has its own digital certificate. Any message sent to Blue Computer would be encrypted using Blue nTegrator’s public key. That message could then only be decrypted by Blue nTegrator using its own private key.

This combination of sophisticated ten-level permission-based access to every object and PKI encryption of messages sent over networks ensures a very high level of security for applications built using nTegrator.

NN

4 2 3 2 3 4

C3C3 C4C4

1

N N N

1 2 3 1 2

C2C2

C1C1

C5C5

4

C0C0

1

The architecture you see here would exist in exactly the same form if it were distributed across three computers instead of four.

Or even if it were all on one computer.

nTegrator permits exceptional flexibility in how applications are distributed.

5 6

N

4 6 7 10 11 1291 2 3 85 13 14

C3C3 C4C4C2C2

C1C1

C5C5

C0C0N

4 6 7 10 11 1291 2 3 85 13 14

We call this a “geographically irrelevant” distributed architecture.

C3C3 C4C4C2C2

C1C1

C5C5

C0C0N

4 6 7 10 11 1291 2 3 85 13 14

We call this a “geographically irrelevant” distributed architecture.

C3C3

C2C2

C1C1

1 2 3

C3C3

C2C2

C1C1

1 2 3

This is a hierarchy of collections and objects organized into a simple application system. It gets external data, consolidates it, performs some computations on it, then presents it to the user.

C3C3

C2C2

C1C1

1 2 3

This is a hierarchy of collections and objects organized into a simple application system. It gets external data, consolidates it, performs some computations on it, then presents it to the user.

In this system, the highest-level collection requests data from a ‘subordinate’ collection.

The subordinate collection may not have the data but it knows to ask its subordinates for components of the required data.

Collection 3, in turn, asks its subordinates.

They read external data and convert it to XML.

An Agent in C3 combines the two messages and sends the data up.

First C3…

…then object 1.

It is programmed to get data from the Internet.

An Agent in C2 combines both messages.

Another Agent performs the required calculations on the data.

A new message is then sent to C1.

An Agent in C1 formats the data into HTML for display by the user on his web browser.

C3C3

C2C2

C1C1

1 2 3

An Agent in C1 formats the data into HTML for display by the user on his web browser.

nTegrator applications are specified from the top down, starting with the highest-level function.

System design is the same: top down, starting with the highest-level function and working downwards.

Uniquely, construction and implementation are also top down, in exactly the same way.

Data access is delegated to the lowest level. nTegrator is packaged with standard Data Handlers to access SQL and COM-aware databases.

Because of this, and because custom Data Handlers are simple scripts, nTegrator applications can use

in any form, in any database,anywhere.

any data,

C3C3

C2C2

C1C1

1 2 3

in any form, in any database,anywhere.

any data,

Systems are developed using nTegrator Explorer.

nTegrator Explorer is in some ways similar to Windows Explorer. Everything is organized hierarchically.

Windows folders contain other folders and/or files. In nTegator Explorer, collections contain other collections, objects, Data Transports, and Agents.

Unlike in Windows Explorer, any item can be a part of more than one collection.

The highest level collection is the computer this is on – in this case “Akamina2”.

This collection contains several other collections, among them:

“Data Items”, which is the programmer’s name for Data Transports.

“Method Groups”, which is the programmer’s name for Agents.

“Login”, which is the default collection for any user entering this computer.

“Network”, which is the collection that contains nTegrator objects that point to other nTegrator engines.

Explorer is used to administer an nTegrator site.

It is used to set permissions, import new Data Transports and Agents, change object names, and edit object scripts.

The Help command is used to document the operation of nTegrator.

The right-hand panel is used for debugging whichever item is selected in the left-hand panel.

This is an example of setting access control.

Right click object

Select from drop-down menu

Check off permissions

Click OK

… and it’s done.

nTegrator Explorer is intended to be a complete development and system management workbench.

nTegrator has a very small footprint…

So nTegrator can operate unobtrusively in any Windows device.

Even…

And no web server is required.

N Less than 200K

Compact code improves performance as the program is less likely to be paged in and out of memory by the operating system.

SampleSystem

…and it keeps its objects in a cache. If a data store is present, nTegrator uses it. But none is needed.

n

Recap of FeaturesRecap of Features

• RAD toolkit.• Objects contain a Data Transport to move data, optional

Agents to apply system and business rules.• Objects, Data Transports, and Agents reusable.• New Agents can be added to reused objects, visible only to

new system.• Agents can be ‘dropped in’ to object without recompilation.• Commands and data always in XML messages.• Data Transports in Interface Objects read any data, in any

form, anywhere, any time.• Standard Data Transports and Agents for common tasks.• Truly distributed systems – ‘geographically irrelevant’

across TCP/IP networks.

n

Recap of FeaturesRecap of Features

• Application systems built by organizing objects into hierarchical collections.

• Highest level collection controls system operation.• Transactions in two steps: establish path, exchange

message(s).• 10-level permission-based access to each object.• PKI encryption across networks.• Top-down specification, design, implementation.• System development using nTegrator Explorer – drag

and drop objects and components.• Small, efficient code runs anywhere, avoids paging.

n

nTegrator: The VisionnTegrator: The Vision

• “Exactly the information wanted, only the information wanted, in the form wanted”.

• Any information available to any qualified user.• Easy control of access by information’s owner.• Data kept private over Internet.• Minimal infrastructure for data supply (no web server).• Data always in standard format.• User’s use of data does not affect others’ use of it.• Small footprint for unobtrusive presence.• Top-down development with minimal technical skills.

n

nTegrator: The PossibilitiesnTegrator: The Possibilities

• More standard Data Transports: SAP, PowerSoft, SOAP, etc.

• More standard Agents.• Data discovery mechanism: indexing capability.• Autogeneration of solutions: “Visual nTegrator”.• Estimating and tracking tools.• Application to roles other than business

systems.• nTegrator Explorer into a true workbench.• AI applications.

n

Business without Business without BoundariesBoundaries

by nBoundary Software Inc.

nnTegratorTegrator

business without boundaries

Documents