WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

Application and system development on a resource oriented computing platform can be broadly categorized in three stages: Construct, Compose and Constrain, known as the "Three Cs".


The construct stage is focused on building physical level components implemented with the NKF API. Construct includes adding new services, tools and resource models. The details needed for constructing new components is covered in the Physical Reference Guide.

Typically less than 20% of development time is dedicated to this form of work.


The composition stage is focused on co-ordinating resource requests. In this stage one uses logical level tools and services to transform and compose resources from other resources.

Composition can be orchestrated with DPML or by using any other supported language to make requests with the NKF API. The details needed for composition is covered in the Logical Reference Guide and the Resource Model Guide.

Typically about 70% of development time is associated with composition.


Unlike with strongly typed, statically linked software, in ROC the constraint stage is often the final stage of development.

Once a system is working, one can apply business and information constraints to provide contractual and semantic boundaries within your application architecture.

Since in ROC all software is late-bound and dynamically resolved each time it is requested there is complete decoupling between a requestor and the invoked endpoint. It is therefore very simple to insert transparent boundary layers into your architecture after they have been composed together and without disturbing the established relationships. Constraints may be applied (and removed) by simply overlaying a boundary around your ROC system and sub-systems.

Typical types of constraint including structural and syntactic constraint (using, for example, Schema languages) but also includes the ability to perform semantic constraint (asserting that the information values of resources are meaningful in the context of the current state of the application). In addition, it is very simple to apply security trust boundaries and audit layers within and between parts of your architecture.

In addition to the conventional constraints discussed above, ROC offers a new degree of freedom in its ability to apply performance and system integrity constraints. For example the throttle overlay is able to transparently manage the concurrency of requests and can be wrapped around a single service endpoint, or just as easily, around an entire address space. So spacial decoupling allows the ROC architect to create balanced and fail-safe system configurations entirely decoupled from the physical level details of the actual application.

Typically about 10% of development time is associated with applying constraints.