Outside-In Development

An effective approach to development in NetKernel is to start at the edges of the system and works inward.

In resource oriented computing resources and services are located at a logical addresses within an address space. NetKernel supports multiple address spaces which can be related to each other through mappings and imports. Designers can use this to partition a system into separate layers and to locate shared resources and services in shared modules.

The outside-in development approach focuses first on these high-level relationships: the relationships between address spaces and the definition of logical layers. The approach is called "outside-in" because the best way to start defining these relationships is at the edges of a system (both client and information-source facing) and work towards the middle (where the application or business logical is located).

This approach can best be described by following an example.

Example Description

The example we will use is a conference registration system.

Transports First

The first step involves transport configuration and testing to make sure events are detected properly, corresponding root requests are injected into the fulcrum and that requests are routed to the top level application module.

event --> transport --> root request --> imported application module

NetKernel applications are decoupled from transports providing flexibility. The deployed application configuration may use a completely different set of transports from transports that make development easiest. For example a deployed application may use the JMS transport and during development the HTTP transport is used to support browser access.

Because of the rich set of tools that support the HTTP transport, we recommend that the development environment be configured to support at least the HTTP transport initially.

The following steps establish the initial scaffolding:

1. Create a new module to serve as the top-level application module.
   1. Export the address space ffcpl:/registration/.*
   2. Map ffcpl:/registration/(.*) to ffcpl:/$1 in a rewrite rule
   3. Create a subdirectory resources/ in the module.
   4. In the mapping section define a this entry for ffcpl:/resources/.*
   5. Create the resource ffcpl:/resources/index.html and insert a simple HTML page into that file
2. Use the Request Trace Tool to verify that:
   1. An internal request for ffcpl:/resources/index.html succeeds
   2. An external request for ffcpl:/registration/index.html succeeds
3. Import the module into the frontend fulcrum. (And issue a cold restart)
4. Verify that a browser can issue a request and see the HTML page at the address http://localhost:8080/registration/index.html

If you complete these steps and the browser is not displaying the page, use the Request Visualizer Tool using the regular expression ffcpl:/registration/.* to diagnose.

At this point you know that a request issued by the browser is detected and the corresponding root request is routed to you top-level application module.

Resources Second

The second step involves configuring access to the resources used by your application. In NetKernel resources may be accessed in a wide range of technologies - relational databases, LDAP servers, email servers, legacy systems, etc.

For each source of resources configure access (such as the RDBMS module configuration) and expose a sample resource to a portion of the address space allocated to testing. For example, a query issued to a database for the list of conference attendees could be mapped to

ffcpl:/resources/test/attendeelist

Build Towards The Middle

With transports configured and access to resource servers confirmed, the fundamental scaffolding is in place. In the next step the application is built inward, toward the core application logic. The following diagram illustrate this for an application that uses four modules (including the fulcrum). It is important to note that what matters architecturally is the layering, not the modules. In fact the top-level, logic and integration layers could reside in a single module.

To continue with our example, one would define low level services and resources that are layered just above the external servers. For example

ffpcl:/attendee-list
ffpcl:/send-confirmation
ffcpl:/charge-account

might be services that draw on the resources and capabilities of the RDBMS server, email server and the legacy system.

The application logic module might have services such as

ffcpl:/register

which would be implemented as a script that calls on the lower-level services defined in the integration module.

The top-level module might have a service defined as

ffcpl:/register-attendee

that in turns calls on the processing defined by ffcpl:/register.

Final Steps

Once the application logic is in place then constraints may be added to the system. Constraints restrict the processing allowed. It only makes sense to get a system working and only then constrains what it can do. Examples of constraints are security (implemented as a gatekeeper pattern) and form value validation.

Other Stuff

In our example application the HTTP and SMTP transports are used for deployment however only HTTP is used during development. In addition, because it is simple to map multiple transports to an application the choice of a transport may differ during development and deployment. For example, if an application is going to use the JMS transport exclusively during deployment it may be convenient to configure an HTTP transport for development as a web browser is an excellent tool for creating application events and displaying the results.

Following the suggestion to use an HTTP transport during development the most convenient option is to use the frontend fulcrum installed and configured in the default NetKernel installation. The frontend fulcrum uses an HTTP transport listening on TPC/IP port 8080.

A strength of NetKernel and resource-oriented computing is application independence from transports. Application services can be created within an internal address space and later mapped to one or more transports.

Following the outside-in approach

User Request --> Service --> internal services --> resources --> repositories

Talk about "animation of resources and services".

the relationship of the external (client user) address space to inner address spaces and to the sources of information (databases, legacy systems, etc.).

Development in NetKernel occurs at the logical level and the binding between the logical and physical level occurs for each request when the request is processed.