Presentation is loading. Please wait.

Presentation is loading. Please wait.

Business without Boundaries by nBoundary Software Inc. 

Similar presentations


Presentation on theme: "Business without Boundaries by nBoundary Software Inc. "— Presentation transcript:

1 Business without Boundaries by nBoundary Software Inc. 

2 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 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. Sample System

3 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. 

4 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  

5  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. Adams, Pat (403) 555-1235 John Doe (403) 555-6789 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.

6  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. Adams, Pat (403) 555-1235 John Doe (403) 555-6789 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.

7   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.

8   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.

9

10

11 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.

12 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.

13 21435 C3 C1 C2

14 21435 C3 C1 C2 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.

15 21435 C3 C1 C2 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.

16 21435 C3 C1 C2 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.

17 21435 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. 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.

18 21435 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.

19

20

21 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”.

22 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”.

23 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.

24 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.

25 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. 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.

26 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. 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.

27 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.

28 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.

29 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.

30 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.

31 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.

32 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.

33 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.

34 Four computers. Each runs nTegrator and has a number of existing Interface Objects. 1234123123412 

35 C5 C4 1234123123412 C2 Blue objects 1, 2, and 3 are contained in a collection. C3 So are Red objects 2 and 3. As are Green 2, 3, and 4… … and the two Orange objects. 

36 1234123123412 C2 C3 C4 C5 C1 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. 

37 1234123123412 C2 C3 C4 C5 C1 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 

38  123412323412 C2 C3 C4 Then we design and implement the collection. It will contain: C1 41 C5 Collection C1new object Red 4existing object Green 1and Collection C5. C1 1 C5 4 C0

39 123412323412 C2 C3 C4 C1 1 C5 4 C0  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.

40 423234 C3 C4 1  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. 12312 C2 C1 C5 4 C0 1

41 423234 C3 C4 1  12312 C2 C1 C5 4 C0 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.

42 423234 C3 C4 1  12312 C2 C1 C5 4 C0 1 When the object has done its job, it returns a message back up the hierarchy and the transaction is complete.

43 423234 C3 C4 1  12312 C2 C1 C5 4 C0 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.

44 423234 C3 C4 1  12312 C2 C1 C5 4 C0 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.

45 423234 C3 C4 1  12312 C2 C1 C5 4 C0 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.

46  423234 C3 C4 1  12312 C2 C1 C5 4 C0 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. 56  4671011129123851314

47 C3 C4 C2 C1 C5 C0  4671011129123851314 We call this a “geographically irrelevant” distributed architecture.

48 C3 C4 C2 C1 C5 C0  4671011129123851314 We call this a “geographically irrelevant” distributed architecture. C3 C2 C1 123

49 C3 C2 C1 123 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.

50 C3 C2 C1 123 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.

51 C3 C2 C1 123 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,

52 C3 C2 C1 123 in any form, in any database, anywhere. any data,

53 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.

54 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.

55 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.

56 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.

57 nTegrator has a very small footprint… So nTegrator can operate unobtrusively in any Windows device. Even… And no web server is required.  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. Sample System …and it keeps its objects in a cache. If a data store is present, nTegrator uses it. But none is needed.

58 Recap 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.

59 Recap 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.

60 nTegrator: 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.

61 nTegrator: 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.

62 Business without Boundaries by nBoundary Software Inc. 

63 Introduction Objects (intro) Messages Network Hierarchy Collections Objects (explanation) Reuse Drop-in Agent Architecture Paths Transactions Permissions Encryption System Distribution Top-Down features nTegrator Explorer Any Windows device Features (recap) Vision Possibilities NewTech system


Download ppt "Business without Boundaries by nBoundary Software Inc. "

Similar presentations


Ads by Google