You are reading The New Programming (Part V): Semantic Units, Security and Debugging. You can leave a comment or trackback this post.
Posted on September 1st, 2006 by Chris.
Categories: Chris, Product Design, Programming, Semantic Unit Architecture.
In this episode we’ll be talking about the crosscutting concerns of security and debugging.
The idea of a crosscutting concern comes from aspect-oriented programming. In object-oriented and other kinds of programming, we often find that certain needs, logging and security being the most notable examples, appear in every object. If you want your program to keep a log, you will likely have logging elements all throughout your program, defying the notion of encapsulation.
In order to solve this problem, some forms of AOP use join points. Throughout the code of a Java program, AspectJ forms what one might call a type of preprocessing; it inserts code into the program, called advice, whenever it appears appropriate (only at join points).
Unlike AOP, we make our abstractions at a high enough level that we can imagine using Units both as encapsulated objects and aspects.
In our case, S-Unit defines security in terms of three major problems:
Under these circumstances, we always begin with the first establishment of trust, just like in the real world. A user may choose to trust a unit. In order to make an informed decision, we must have a way of telling the user, verifiably, what the unit does.
This, in reality, would likely demand that we create signing authorities for units, and act as an authenticator. If we were a central authority, we could act as an independent 3rd party verifier to determine exactly what a unit did (its security risks, etc.). We’ll discuss this more when we talk about the Semantic Nexus, Semantwiki (Part IX).
In general, since we’re not an operating system, we have only a few ways to choose from as far as authenticating users. We can take operating system permissions and translate them as necessary, or we can operate as a user authenticator per machine (in effect, be our own permissions manager).
Unit restriction would be based on the intersection of information provided by these two authentications.
The concern of debugging is generally to figure out when and where a program has failed. The first thing we can do to make sure that debugging is simple is confine error processing to the unit of failure.
This of course, is not always possible. Rigorous S-Unit programming makes two (not necessarily provable) demands that would make this condition at least imaginable:
In order to validate messages coming in and out of a unit, we must know exactly what data we expect and additionally have rules that confirm this data. It’s a challenge to fit this sort of validation into semantic data; if we say, for example, that an IM message can only be under 4096 characters, we need to add this rule and apply it ourselves. The Semantic Web group, for example, is only interested in adding semantic meanings to data–not restricting or validating that data. We’ll discuss how to attach this validation to semantic data in Parts VI and VII.
The only way to guarantee absolutely that a unit can process all possible inputs is to test all possible inputs. Given that this is unlikely, we can still create a Tester unit, which offers to try a series of random inputs and see if a failure is thrown in any case.
A Tester Unit is unique in that we probably can’t imagine attaching it to live applications, which already produce test cases simply by running. Given these conditions, we can limit the number of errors we receive to primarily single-unit errors. How might we diagnose them?
The solution, as you might imagine, is a new unit. The Debugger can attach to every other Unit and can watch variables and keep breakpoints.
This unit, given the architecture of the semantic system, will be unusual in several ways compared to a normal debugger. It will only report breakpoints in its unit; other units will be free to continue operating (unless they are of course attached to the debugger). Another challenge is that, with language-independent units, it will be difficult to develop a true debugger; it will depend very much on compilation techniques, which will receive a more rigorous treatment in Part VI when we discuss languages.
http://www-128.ibm.com/developerworks/web/library/wa-debug.html?ca=dgr-lnxw03Dbug
0 comments.
Comments can contain some xhtml. Names and emails are required (emails aren't displayed), url's are optional.