References for Web Architecture

One of the most important principles for web architecture is in the identification of location.  Web architecture is often violated when index expressions are employed where address expressions are appropriate. 

A browser getting a web page employs an address expression when it's not employing a dynamic view in a resource collection scheme.

An address expression is more commonly known as a resource location.

A URL (for HTTP GET) has a query expression employing indeces and possibly describing ranges within collections when it employs the query parameters syntax.  As in "/path?id=0".  This example is an index into a collection. 

An index is a component of a query expression.  An index may be a part of a range expression. 

A query expression in an HTTP GET request expresses a view or perspective on a resource collection. 

A URL (for HTTP GET) is an address expression (location) when it does not employ the query parameters syntax.  As in "path/0".  This example is the address or location of a web resource.

The difference between an index and an address can be illuminated in the context of resource editing.  A view is not employed for resource editing.  The incorrect HTTP statements "DELETE /path?id=0" or "PUT /path?id=0" violate web architecture because the URI components of these statements are not locations.  The URI employed here expresses a view on a collection of resources rather than a resource location.

The distinction resolves compatibility with many issues, both internal and external to a domain's web services.  Edge devices external to web services can readily resolve this distinction.  Client user agents, editors, and automated web services can readily resolve this distinction. 

But most importantly, a web architecture lacking collection- scheme- independent resource locations precludes the long term survivability of its own links, as well as alternative views.  It lacks a structure for its own evolution.  Its links will become broken when its view scheme changes. It is fragile.

An index expression for a single resource should redirect to an address expression (a location).  A collection view containing single resource references should point to address (location) expressions, or of course alternatively, to index expressions that will redirect to locations.

A web architecture should make a best effort to create survivable resource locations, and independent view query schemes, to avoid application silo effects in its choices.

Interaction mechanics

Process algebras are not very useful to me as a Software Engineer working in the interactive server side.  They describe the systemic composition of interaction machines from the remote distance required for a mathematical view of computing.  Unfortunately, current work in the field of Interaction Machine Theory seems to have gone back to the bad old days of new process algebras.  Those funky little scripts that create oh so much prestige.

Illuminating the principles of Interaction Machines requires inspection of the idea, much more than constructions of the idea.  Constructions prove and explore the models proposed for inspection.  Inspection is the thing needed by the world.

Design patterns

The benefit of design patterns is in a facility to communicate a complete idea without changing the course of the conversation to dive into a tangent.  They're touch stones.

One problem with design patterns is in their naming.  We use different names and we forget their names.  It's easy to do.

However, the main problem with design patterns is getting locked into their specification before the correctness of the choice can be validated.  Sometimes the problem and solution are simple enough that the question of applicability can be answered mentally. 

However in most cases, the subject and its containing system are complex enough that some consideration is in order for the benefit of minimizing project risk.

An analysis reviews an interface or library to consider the essential attributes of its fit value. 

An experiment goes down the road of using an interface and library to discover its actual fit value. 

The speed with which the analysis or experiment can be performed, and the quality of their predictions with respect to project success and risk, are elements of experience.  Experience knows that an interface or library that overtly fits the problem may have broader implications for the success or maintainability or interoperability of the system.

It's not because we want to be able to reason about and compose systems in a singular thought process that we can make it so by using the patterns and APIs in mind.  Building software systems simply remains harder work than that these days.

Interface Architecture

An architectural process centered on interfaces has important capabilities and benefits.  The term interfaces relates to one or all of the graphical user interface, the network interface, and the application programming interface in the design and development of interactive network applications.  The graphical user interface is primarily in the domain of Interactive Design (IxD), except to remain aware that it is an integral component of an interactive system.

Design and development focused on network interfaces more than software frameworks and their architecture has the advantage of a crisp computational problem definition and solution.  It has the benefit of implementation independence and in this way it has both broad interoperability and long term durability.  The computational problems of network systems, including the issues of interactive applications as well as the subjects of integration, performance, and data distribution.  The analysis and development in these subjects is traditionally performed in terms of the interfaces inherent in both network services and data (payload / transfer / representation) formats.  For example this is the work of the IETF and W3C, as well as many other organizations.

Design and development focused on application programming interfaces defines a software system as a collection of interfaces.   This process is not so different from that of the network interface.  It has the same capabilities and advantages, translated from the network interaction domain to the host interaction domain.  Analysis, design and development in terms of these interfaces provides crisp problem definition and solution, broad interoperability and long term durability.  For example in multithreading, locking under each interface will not deadlock unless and then certainly when the implementation of one interface employs another interface.

Interface Architecture is a logical razor that cuts problems into solvable units.  In working on interfaces rather than components, the parties to a project have an efficient and effective subject for communication and interoperability.  The discipline of Interface Architecture demands of its participants a simple (and singular) logical view of the interface as the first class citizen of the world of the project, and its various implementations as relatively second class replications or adaptations of the design of the interface.  An interface has a singular purpose that must be rationalized among all participants before design work may commence.  An interface may begin simply and include technically implicit or explicit avenues for its own extension in order to serve its own subsequent evolution.

Fixed price contract management

Fixed price software development is a complex subject.  Because software development is a complex subject.  A general conception of the market for software applications has interest in fixed price development, but the history of fixed price contracting is littered with exemplary failures.

Fixed price contracting refers to a contract for a single project cost, in contrast to forms of flexible development contracts that permit cycles of evolution in the development of the project.  Flexible or cyclic development contracts are necessary to monolithic projects that encompass broad scope, and projects that involve an element of novelty (not well known).  The contractor's ability to predict the future of a development project is inversely proportional to the complexity and novelty of the deliverable product.

The region for success with fixed pricing is in products that are unambitiously sized to, and well known to the contractor.  In this case, the development work to be done requires only a few build, test, release cycles in the scope of project -- and these cycles may be opaque to the terms of the agreement.  This is a small region in the world of software development, but it exists. 

In the abstract, success in fixed pricing depends on technical project management, first contractor selection and second the definition of work.  A "successful failure" is a delivered software product that performs poorly, is hard to maintain, is awkward in use, or is inflexible.  It is this scenario of the overt success but practical failure that is the principal opposition to fixed price contracts.  With evolutionary development cycles, issues in performance and usability can be ironed out subsequent to an initial delivery.

There is always an argument in favor of fixed pricing.  It should be possible to arrive at a market place wherein contractor technical capabilities are better known than not.  And it should be possible to manage large projects as a set of smaller ones, sized for their most practical development.   The allure of this possibility has resonance, because software projects are best organized as a composition of parts, and the ultimate product qualities of usability and flexibility are proportional to the technical independence of a product's component parts.

Unfortunately the subject of software project management is a messy one, principally described for its difficulties, and the tactics and strategies for dealing with and managing these problems.  A problem with a solution is no longer a risk to success.  The solution is to employ an evolutionary development process, as there's always an element of the unknown, including the necessity for competitive business evolution. 

If project management were cyclic, development units could be fixed.  This would work if the contractor could be rehired in a predictable and suitable way, and this contracting scheme becomes an open subject for a solution.  Perhaps the contract is an open cycle of fixed units.

Generally, however, practical contracting will tend toward the cyclic.  Each role, manager and developer, has limits to its capacity, and effective repeatable annual results depend on a practical work flow.

Open Commerce for Syntelos

The Syntelos business model is based on the principle of open commerce.

• Open partnership
• Open source
• Open service

This is open commerce.  An open company includes as partners all contributors, both product and marketing.  Likewise an open business provides an open set of alternatives with competitive market value for its consumers.  It is an open facility with fair economic cost and rent that competes in the whole market among all producers.  Strictly minimizing economic costs and rents is critical to whole market competition.

A competitive market puts pressure against producer margins, while a competitive producer pursues differentiation to support positive margins in its effort to maximize profit.  An open commercial producer works no differently. 

A company founded on open commercial principles is organized differently from a volunteer open source community like Mozilla.  It is chartered commercially, and the contributions of its participants are recognized as economic and commercial.  The free open source product is there, and the commercial product is there.

These are founding constraints from which a variety of open problems require solutions.  The solutions in this case are not entirely decided.


Knock on wood.

Is Java Dumb?

Slashdot reported an essay on Computer Science education that bemoans the average quality of their graduates.  Of course the first most obvious points are not in tools.  But is there something wrong with Java?  Well, actually, yes there is.  It's not in the syntax of the Java Programming Language, and it's not in the Java Virtual Machine, it's in the style of the design and implementation of the class libraries. 

The syntax of the Java Programming Language provides a high level, systemic or architectural layer for reasoning about the organization of application systems. 

The Java Virtual Machine delivers a general, high performance facility which in recent years has seen the performance of its runtime outstrip the performance of source equivalent applications written in C and C++.   This fact alone is the first best honor for the JVM.   As a machine interface or Instruction Set Architecture (ISA), one can compare the JVM to other machine abstractions like the more recent development of the Dis virtual machine.  The JVM is pretty good.  Its weaknesses are best illustrated by the difficulty that's been had in a handful of cases implementing the JVM in hardware.  These efforts require pointers, machine addresses for memory and devices, and in this and other issues the JVM has been proved to be at crossed purposes -- unlike remarks circa 1995 that the JVM was designed to be compatible with its implementation in hardware.  This idea is proved correct in the syntax and semantics of its ISA, but not in a very precise sense including the implications of its ISA.  The JVM is great because it has been and remains an independent and reasonable Instruction Set Architecture (no bad, messy or unpredictable instructions).  It is independent from the kind of issues prevalent in the Java class libraries.

The general style of programming in the class libraries, on the other hand, has been what it is since the first alpha source dump.  In having classes where there could have been interfaces, the java class libraries obviously espouse a singular usage pattern -- a vision of Java programming as beany scripting.  When the java core APIs don't make an example of good style in using interfaces where applicable, the example is poor by any standard.  Evidently there exists an argument in favor of document driven, code generating IDEs.   The Java platform is many things to many people, and would have been best served in 1995 with an independent script language in which the beany platform was realized.  Everyone was too busy to realize the best possible future for us all, and JavaScript emerged as altogether something else.

The Java 1.0 classes java.io.OutputStream and java.io.InputStream are classes that should have been interfaces.  The classes do nothing an implementor wouldn't just assume doing anyway -- implementing skip(int) bytes in the input stream, or throwing an exception for a bad call to write(byte[],int,int) in the output stream.  Their reason for existance isn't providing functionality, or at least the benefit of that functionality is far outweighed by the benefit of their being interfaces.  Arguments in favor of their being classes aren't in the domain of their best engineering.  One can imagine that they're classes in the beany argument, so that programmers working from documentation can subclass in the singular usage model.  And one can imagine that if as much of the core classes were interfaces as would have been best in terms of their own engineering, then that core could be perceived as an open invitation to alternative implementations.   If Input Stream and Output Stream were interfaces, then implementors like my own bbi and bbo would instantiate one class instead of two at runtime.

What if the 1.0 AWT classes had been interfaces?   The AWT is a well known problem child, with more quirks to hack around than predictable behavior.  The class based implementation as it stands writes these problems into compatibility cement.  As intended, in that the point of the Java platform is to have identical (write once run anywhere) behavior everywhere.  But for Sun's internal engineering, had the AWT been interfaces, they would have been in a better place to solve their problems as bugs rather than cement them into the history of the platform.

There are many problem cases among the Java class libraries, including my own most recent favorite, java.nio.ByteBuffer, which should have been an interface.  Like all good examples of classes that should have been interfaces, the class implementation is shallow and poor.  (Shallow but good has the favor of formalizing particular semantics, for example with respect to what exceptions are thrown and in which cases).  The NIO Byte Buffer has three fields, implementing an in- memory readable and writeable byte buffer.  My own gnu.iou.bbuf is more interesting (in counterpoint here), implementing following read writeable and following write readable semantics.  This read/write buffer is illustrated in the bbuf streams, bbi and bbo.  Plainly the author of the NIO Byte Buffer was not interested in diving into writing a read/write byte buffer.  And rightly so, the package is for exposing the kernel primitive "sendfile" operator present in most operating system kernels for five years or more.  And that's where an interface would have been A Good Thing.  Or at least a class that could be subclassed. 

The aggressive possessiveness inherent in the definition of the NIO package makes in inutile.  And here's why.  To expose native I/O primitives in an extensible way, the author of NIO has constructed an extensive framework for reading and writing files and bytes.  Most of the architecture of the NIO framework is oriented to reading and writing individual data values like numbers, for example the following list of classes.

java.nio.ByteBufferAsDoubleBufferB
java.nio.ByteBufferAsDoubleBufferL
java.nio.ByteBufferAsDoubleBufferRB
java.nio.ByteBufferAsDoubleBufferRL
java.nio.DirectDoubleBufferRS
java.nio.DirectDoubleBufferRU
java.nio.DirectDoubleBufferS
java.nio.DirectDoubleBufferU
java.nio.DoubleBuffer
java.nio.HeapDoubleBuffer
java.nio.HeapDoubleBufferR

These classes are representations of the 64bit IEEE754 "double" floating point value in the NIO framework.  The NIO package requires the creation of new objects containing new buffers for the I/O of each individual data value.  Any operation between NIO an in- memory data requires a new NIO buffer to interface to the NIO package.  This is not A Good Thing, because the objective of a high performance system is to cut the number of buffers in the total process pipeline.  Ideally to one.  Using NIO, achieving one in memory data buffer is not possible -- except possibly in the case of copying files to sockets.

So NIO is yet another problem case in the Java class libraries.  Not because it's not good at copying files to sockets, it excels at that.  But because an "SE" core framework was released that no one but a JRE/JDK can reach into.  There are many, many cases among the large number of Java APIs of a strange separation between abstraction for APIs and implementation (for API Vendors).  Which makes too little sense, as generally useful API implementations become commodities anyway.

For reasons like these and so many more of the same, this writer would say that there's a distinct lack of serious engineering discipline in the development of the JDK.  Everything's personal, and far too little is rational.  Discussion of the further implications of the example made by "Java" in its libraries are beyond the scope of this essay.  But certainly alternative languages and libraries have emerged and continue to emerge to redress the subject.

A new medium for the study of REST & HTTP

I've started a Google group named "comp-protocols-http" as an experimental medium for exploring REST and HTTP. 

It's RESTful in more ways than one.


Happy new year