620 likes | 728 Views
n Tegrator. by nBoundary Software Inc. Business without Boundaries. Viewing Instructions.
E N D
nTegrator by nBoundary Software Inc. Business without Boundaries
Viewing 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
nTegrator • 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.
nTegrator N nTegrator is a small piece of software that resides on any Windows computer Each copy of nTegrator manages specialized nTegrator objects In an active system, there are a number of objects associated with each copy of nTegrator.
N Objects communicate with each other by passing messages. Internally, all nTegrator messages look like XML documents. Extensible Markup Language is a new industry standard structured data description language. <?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 Objects communicate with each other by passing messages. Internally, all nTegrator messages look like XML documents. Extensible Markup Language is a new industry standard structured data description language. <?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.
Messages can travel between objects across any TCP/IP network – LAN or Internet. N Application systems built using nTegrator can be distributed across as many computers as desired. N
Messages can travel between objects across any TCP/IP network – LAN or Internet. N Application systems built using nTegrator can be distributed across as many computers as desired. N
nTegrator objects are programs. Each object is made up of two types of program. There can also be zero, one, or many “Agents”. Agents contain actions that are to be performed on the data. Later in the presentation we will see how Data Transports and Agents work together. There is always one and only one “Data Transport”. A Data Transport is a program that moves data.
nTegrator objects are programs. Each object is made up of two types of program. Later in the presentation we will see how Data Transports and Agents work together.
2 1 4 3 5 C3 C1 C2
2 1 4 3 5 C3 C1 C2 nTegrator application systems are built by organizing objects into logical hierarchical groupings called Collections. Low level objects usually read or write data to and from sources that are external to the nTegrator system. In this example there are five low-level objects…. They are called Interface Objects. Collection Objects govern the flow of data through the system. … and three collection objects.
2 1 4 3 5 C3 C1 C2 A Collection “contains” the objects below it in the hierarchy. Collection Object C1… … contains these two Collection Objects: C2 and C3. This Collection Object… This hierarchy describes a simple nTegrator system. … “contains” these two Interface Objects. Collection Object C3… … contains the three Interface Objects: 3, 4, and 5.
2 1 4 3 5 C3 C1 C2 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. This hierarchy describes a simple nTegrator system. Any Agents attached to any objects along the path may affect either the routing or the content of messages that pass through them. 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.
2 1 4 3 5 C3 C1 C2 A system starts operating when the highest collection issues a command that establishes a “path” through the hierarchy. It is the grouping of functionality into collections that enables nTegrator systems to be developed. The path is usually a way to select an Interface Object. It is the dynamic establishment of paths through the hierarchy that controls how nTegrator systems operate. Any Agents attached to any objects along the path may affect either the routing or the content of messages that pass through them. The high-level object then sends a command to the Interface Object in the form of an XML message. 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. The object performs whatever actions it has been programmed to do. And then it sends a response message back up the line.
2 1 4 3 5 C3 C1 C2 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.
nTegrator objects are programs. Each object is made up of two types of program. 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”. A Data Transport is a program that moves data.
nTegrator objects are programs. Each object is made up of two types of program. 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”. A Data Transport is a program that moves data.
A Data Transport is a program that moves data. 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.
A Data Transport is a program that moves data. 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.
A Data Transport is a program that moves data. 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. … the Data Transport will have three ‘low side’ ports. This allows messages to be routed along the “path” selected by the top-level collection. If the collection looks like this…
A Data Transport is a program that moves data. 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. 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. 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.
A Data Transport is a program that moves data. In a Collection Object, the Data Transport acts as a router. It directs XML messages through the hierarchy. 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. Agents are developed using simple scripts. Agents have the same format in both object types. Standard Agents to perform common tasks such as merging messages are supplied with nTegrator.
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. Agents are developed using simple scripts. Agents have the same format in both object types. Standard Agents to perform common tasks such as merging messages are supplied with nTegrator.
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. 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. Reuse applies whether the component was supplied with nTegrator or was custom developed by the user.
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. New nTegrator applications can easily combine objects from existing systems with new objects, and can use data that resides in existing data stores. It is so unique that a patent is pending on the way this feature has been implemented.
1 4 3 2 3 2 1 4 3 2 1 2 1 Four computers. Each runs nTegrator and has a number of existing Interface Objects. N N N N
4 1 3 2 1 3 2 1 4 3 2 1 2 C4 C5 C3 C2 Blue objects 1, 2, and 3 are contained in a collection. So are Red objects 2 and 3. As are Green 2, 3, and 4… … and the two Orange objects. N N N N
1 3 3 4 1 2 2 1 2 3 4 2 1 C3 C2 C4 C1 C5 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 3 3 4 1 2 2 2 2 3 4 1 4 1 C4 C2 C3 C1 C5 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. N N N N
2 1 1 1 2 3 4 1 4 2 3 4 1 2 4 3 C4 C1 C3 C0 C1 C5 C5 C2 Then we design and implement the collection. It will contain: Collection C1 new object Red 4 existing object Green 1 and Collection C5. N N N N
1 1 2 1 4 3 2 4 2 1 4 3 2 3 C1 C3 C4 C2 C0 C5 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. N N N N
4 3 3 2 4 1 1 2 2 3 1 2 4 1 C4 C3 C2 C1 C5 C0 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. N N N N
4 2 3 4 2 1 1 3 3 1 2 4 1 2 C0 C5 C1 C3 C2 C4 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. N N N N
4 2 3 4 1 1 1 1 4 3 2 3 2 2 C5 C3 C4 C1 C2 C0 When the object has done its job, it returns a message back up the hierarchy and the transaction is complete. N N N N
4 3 4 2 2 1 1 3 3 1 2 4 1 2 C5 C1 C2 C3 C0 C4 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. N N N N
4 3 4 2 2 1 1 3 3 1 2 4 1 2 C5 C1 C2 C3 C0 C4 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. N N N N
4 4 3 2 2 1 1 3 3 1 2 4 1 2 C5 C1 C2 C3 C0 C4 For additional security, all computer-to-computer communications are encrypted. 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. 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. N N N N
4 3 2 2 1 3 1 1 3 2 4 14 2 13 5 4 3 8 1 5 6 4 6 7 11 12 9 1 2 10 C1 C2 C5 C0 C4 C3 nTegrator permits exceptional flexibility in how applications are distributed. 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. N N N N N N
10 9 12 11 7 6 4 14 2 3 8 5 13 1 C3 C0 C5 C1 C2 C4 We call this a “geographically irrelevant” distributed architecture. N
9 11 4 6 10 3 12 2 7 2 3 8 5 13 14 1 1 C3 C4 C1 C2 C5 C2 C1 C0 C3 We call this a “geographically irrelevant” distributed architecture. N
1 2 3 C3 C2 C1 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.
1 2 3 C3 C2 C1 In this system, the highest-level collection requests data from a ‘subordinate’ collection. An Agent in C1 formats the data into HTML for display by the user on his web browser. An Agent in C2 combines both messages. The subordinate collection may not have the data but it knows to ask its subordinates for components of the required data. 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. Another Agent performs the required calculations on the data. A new message is then sent to C1. First C3… An Agent in C3 combines the two messages and sends the data up. …then object 1. Collection 3, in turn, asks its subordinates. It is programmed to get data from the Internet. They read external data and convert it to XML.