Hi,

In the section NetKernel Development: Constrain, there is stated that:

"In NetKernel development, constraints may be considered quite late in the development cycle and may be easily lifted when changes to a systems features are required during a projects lifespan. This is quite different from e.g. OO development where constraints on interfaces and types are surfaced early. For example, simply defining classes in an OO environment is an early constraint which can lead to later inflexibility."

Please elaborate on "simply defining classes in an OO environment is an early constraint which can lead to later inflexibility." Please explain what's the process underlying "defining classes in an OO environment" so that I can make sense of the "early constraint" mentioned above.

Thanks a lot,
Mircea

Hi Mircea,

When you define a class in e.g. Java you declare a new language "type":

public class Customer   {   ...   }

Instances of this new type can only have certain relationships with other type instances (objects) in a running program. At a very low level the Class definition also defines the in-memory layout of instance variables, method entry points and signatures, etc. If a change is made to the class Customer to add a method, an instance variable, etc. then all existing code that is compiled, loaded and running is incompatible with the new definition of Customer. Tom Hicks and I talk about this in the first article in our series on TheServerSide.com: http://www.theserverside.com/tt/articles/article.tss?l=ARESTfulCorePart1

In NetKernel, resources are abstract ideas about information. So "ffcpl:/customer/3384" is the identifier for information about customer number 3384. There is no constraint related to the type of this information. It could be a Java object of type Customer, it could be an XML document, it could be an Excel spreadsheet.

In NetKernel if physical level code does need the information in a specific type so that it can manipulate it, it can specify the type when it issues a SOURCE request. NetKernel will automatically convert the type to the specified type (transparently using a transreptor). The key point here is that an application can be coded at the logical level and have the runtime types change without requiring the system to be recompiled. If fact, it probably can change while the system is running without any disruption. This is in stark contrast with an object-oriented system that would require a recompile, reload, etc.

The point in the documentation about applying constraints late in the process relates to the fact that you can always intercept requests at the logical level, apply processing logic and then issue a sub-request related to the request or not. For example, the interceptor could be a GateKeeper which applies security constraints. In NetKernel the GateKeeper is applied to a working system by the addition of one mapping defintion:

<rewrite>   <match>(ffcpl:.*)</match>   <to>active:gk+uri@$1</to> </rewrite>

You could also imagine a validator that checks each piece of information sent in from an external client. These constraint can be added as a final step in application construction. Furthermore, they can be lifted (simply remove the rewrite rule) if testing of the application requires unconstrained flows of information.

I hope this response helps clarify things. To summarize, in OO design constraints are surface early - essentially as soon as you define your first class. In ROC constraints can be applied at the logical level late in the development process.

-- Randy

Thanks a lot, Randy! Your answer definitely clarified my understanding of OO enforcing early constraints. New questions are starting to take shape in my mind, but I cannot enunciate them yet.