This is the sixth in series of related architectural patterns. The others, in order, are :
- Information Models
- Policy
- Capabilities and Requirements
- Control and Notification Channels
- Context
Intent
Provide an explicit description of the relationships between entities.
Problem
The relationship between entities in a system is often implicit. That is: knowledge about a relationship is often localized to the entities that have a relationship and is not visible outside of those entities. This makes it difficult to change the relationships and difficult for an outside entity to use the relationship for its own purposes.
One way in which this could be solved would be for each entity to expose its relationships, but this is not usually the reason for the entities existence and thus should not form part of that entities interface.
In addition, in any given problem domain there may be multiple ways of categorizing and grouping the same entities to achieve different business ends. Clearly it would be infeasible to expect entities to be able to model any possible set of relationships.
Read the rest of this entry »
Posted in architecture | No Comments »
This is the fifth in a series of related architectural patterns. The others, in order, are :
- Information Models
- Policy
- Capabilities and Requirements
- Control and Notification Channels
Intent
Provide a common and efficient mechanism for the storage and retrieval of ad-hoc and arbitrary data that allows loosely-coupled entities to exchange information without the explicit cooperation of any other entities in the process flow.
Problem
There are many places where information has to be exchanged between two or more entities that are separated from each other by at least one intermediary. A problem arises when that intermediary does not provide a mechanism for the information to be transferred. The problem can arise wherever there is a well-defined and constrained boundary between two extensible systems.
One possible solution would be to modify the intermediary to accommodate the exchange of every new data item. This would lead to a combinatorial explosion in the complexity of the intermediary (or its interface) and would also provide a maintenance nightmare.
Another solution is to provide a direct link between the entities that need to exchange data. This would reduce the complexity but still leave each individual entity with the responsibility of implementing each new exchange requirement as it arose. In addition it would violate the isolation that the intermediary is providing and it would quickly become untenable if multiple entities were involved in the data exchange – each one having to communicate with every other one.
Read the rest of this entry »
Posted in architecture | No Comments »
Entities in any system – be they software objects, logical constructs or physical entities – communicate with each other to achieve their purpose. In addition to their main topic of conversation – if you will – they often need to communicate information about other things, i.e. they need to communicate meta information. For example they need to initiate and end a conversation and they may need to pause and restart a conversation. Furthermore some other aspect of the system may need to monitor the health of the entities to ensure their availability.
Intent
Define a mechanism to propagate control messages and notifications in a manner that does not interfere with and is not affected by the main channel.
Problem
It is often necessary to issue control requests, or send notifications to or about an entity – be that a local component, a remote component or a communications stream. An obvious way to do this is to implement the control/notification mechanism directly on the component or directly in the datastream protocol. There are several problems with this:
- The topic of the control and notifications may be orthogonal to the purpose of the entity or datastream. For example record keeping of the traffic in a datastream is not the purpose of the datastream itself. Controlling the initiation of a session to implement CAC (Connection Admission Conrtol) is not a core concern of the session itself. Writing the values of an object to persistent store is not a core concern of the object being persisted.
- The control/notification channel may require a different quality of service. For example the latency requirement of a video stream control channel is different than that of the video stream itself.
- The control/notification channel may need to be unaffected by the functionality of the entity or stream. For example recording that a process has crashed can't be done by the process. Aborting a locked datastream can't be done by inserting a message into the datastream.
Read the rest of this entry »
Posted in architecture | No Comments »
This is the third pattern in an architectural pattern set. The first (Information Models) can be found here, the second (Policy) can be found here .
Intent
Provide a mechanism to reconcile the capabilities of a service with the requirements of a client. This in turn means that there must a mechanism to describe the capabilities of a service and the requirements of a client.
Problem
In any given environment there will be a population of entities that provide a similar but not identical service. For example different routers in a network may have different limits on the number of VPs they can provide. Some may be running different versions of an O/S with subtly different characteristics. Not all routers are made by Cisco(!). Different versions of a service may expose additional interfaces or use slightly different information models.
In the worst case clients would be hard-coded to expect specific variants. A slightly better solution is to summarize the capabilities of a service using a version number – in this case the actual capabilities are implicit in the version number. However this has the following problems:
- A client has to be coded to understand the full set of version numbers that it may encounter in a service now or in the future.
- Some features of a service may change in incompatible ways whilst others don't.
- A client would not be able to communicate with a new service that happened to provide the capabilities that it required.
Posted in architecture | 1 Comment »
This is the second in an architectural pattern set. The first (Information Models) can be found here.
Intent
Provide a controlled environment in which decisions can be made and enforced.
Problem
Whilst it is obviously possible to make and enforce any arbitrary decision in any arbitrary programming language it is difficult to control, manage, deploy, modify, inspect and verify those policies.
The policy pattern provides a way of adding those characteristics to the basic requirement of decision and enforcement.
Read the rest of this entry »
Posted in architecture | No Comments »
This is the first in a set of related architectural patterns for software architects. Most software patterns are very specialized – for example the GoF patterns are aimed at fixing shortcomings in the C++ family of languages (in which I include Java) that other languages may or may not suffer from. The POSA patterns are aimed very specifically at the implementation of efficient server architectures. An architectural pattern, on the other hand, ought to provide a higher level of abstraction that could find applicability in many languages and/or physical architectures.
This first pattern is a keystone for patterns that follow and is directly referenced by several of them. The others (so far) are:
- Policy
- Capabilities and Requirements
- Control and Notification Channels
- Context
- Relationships
Read the rest of this entry »
Posted in software development, architecture | Comments Off
Why haven't developers of web user interface frameworks got the unit testing bug yet? I was just given a demo of a work-in-progress written using JSF. The person giving the demo selected an item from a pull-down menu and we were treated to a nice little exception explaining that #{someObject.someProperty} did not, in fact, reference an actual property on an actual object. Well, I'm sorry, but that is precisely the kind of issue that should be caught by a unit test. Read the rest of this entry »
Posted in software development, unit testing | No Comments »
A while back I discovered JWChat - a browser-based IM client that uses only HTTP to communicate with a server - in other words very friendly to restricted environments where you are behind a firewall and you can't install software.
JWChat uses a standard binding of XMPP (aka Jabber) over HTTP - in other words it speaks HTTP to a Jabber server. Now the good thing about many Jabber servers is that they can talk to MSN, Yahoo and AIM as well as other Jabber servers. This standard is defined in XEP-0124 and is implemented directly by some Jabber servers. Unfortunately not by the Jabber server that my ISP (dreamhost ) allows me to run. But wait! I can run a rails server on dreamhost, so it was just a simple matter of writing a gateway in Ruby that implemented XEP-0124. Of course, nothing in software development is ever simple (don't believe anyone who tries to tell you otherwise). Read the rest of this entry »
Posted in ruby, jabber, xmpp | 12 Comments »
If you've read any of my other posts, you might have gathered that I've been writing a portal . One of the things I wanted for this portal was the ability to have pages with a different number of columns of various sizes. Initially I wrote it to have three columns. By the way there are many articles on the web devoted to how to implement a three column layout using CSS. Well actually it isn't that hard, but the solution presented here uses JavaScript for reasons that should become obvious.
To me, the most obvious way to achieve this was to allow the columns to be resized. If I provided three columns then the user could resize those columns however they liked - including resizing a column to zero (which would then make it a two column layout) or resizing all but one column to zero (which would make it a one column layout!). So anyway I implemented this in a JavaScript class. The class uses some facilities from prototype , so you need to include prototype.js in any page that uses this splitpane too. Read the rest of this entry »
Posted in javascript, prototype, script.aculo.us | No Comments »
