Supermarket to the Software
A regular reader of my blog (yes, there is at least one) pointed out an interesting perspective on MDA that I have to share. While in general agreement with the statements in my "Software Suburbia" post, he pointed that rather than MDB, perhaps we should consider ADM.

MDB, in that context, refers to Model Driven Business. ADM refers to Architecture Driven Modelling. The difference between ADM and MDA, I think, is clear, but worthy of some discussion.

ADM is more pattern based. It relies on some of the underlying assumptions in the "Software Suburbia" post to refocus design and development efforts toward integration of the various underlying component architectures into the functional requirements of the system.

This, it seems, is the way software development is going to have to proceed to adapt to the new level of abstraction. Rather than trying to figure out how to IMPLEMENT the architectural requirements, we attempt to identify COTS components with well aligned, or realignable, architectural aspects that correspond to our needs. The realignment aspect is where the patterns come into play.

What are the patterns that govern this realignment? That's a question worthy of more thought....
- posted by Terry Cowart @ 4:43 AM 0 comments

 
Software Suburbia
Science, like life, evolves with the environment, or dies. In the field of Computer Science, this evolution resulted in creation of the role of architect. The architect was responsible for maintaining the vision of a system throughout its development lifecycle. In practical terms, this meant designing an application infrastructure that supported both the functional and nonfunctional requirements. Thus, a higher level of organization was achieved.

The trend amongst man-made systems is toward increasing levels of organization-- it is as if the whole of humanity is fighting a holy war against the forces of entropy. In terms of the role of architects, this means that the inherent architecture of infrastructure components is steadily increasing. This does beg a question, which must soon be answered if architects are to avoid the fate of the dodo bird (insert favorite architect joke here): what does this imply about the future role of the architect?

If the role of architect is to survive, it must continue to climb the levels of abstraction. As COTS components continue to resolve (in a more or less optimized fashion) the nonfunctional requirements of enterprise systems, the need for formal designs, at the enterprise level, for the resolution of such concerns must necessarily diminish. Instead, focus should be placed on the needs at the enterprise level: business processes, information flow, and context management.

There is still plenty of system work to be accomplished at this level. BPEL is moving forward quickly, as is MDA. MDA. Now there's an interesting dilemma. If what I have said is true, then MDA is not really what we should be looking for. MDB, anyone?
- posted by Terry Cowart @ 6:49 AM 0 comments

 
Who are you?
As previously mentioned, the concept of trust is inextricably dependent on the concept of identity. If the statement concerning the probabilistic nature of authentication is accurate, how can we ever hope to move past it to the more valuable concept of trust?

Authentication mechanisms are often described along a number of perspectives. The first perspective is upon what basis the authentication is claimed. It is traditionally accepted that the valid bases are what a claimant knows, (knowledge), what a claimant has, (possession), and what a claimant is, (being). Generally, the more of these that can be authenticated, the higher the level of confidence we place in the claimed identity. There are two other perspectives that are less often acknowledged, but that have significant impact on the ability to authenticate a claimed identity.

The first is the channel across which the authentication occurs. For example, confirming that a person knows a password both by requesting that they enter it into a computer, and then speak it into a voice recognition system via telephone greatly improves authentication, even ignoring the possibility that the voice recognition system could also serve as a basis for authenticating “being”.

The second is the possessor of the authentication claim. There is no requirement that the claimant and validator are the only participants in the process of authentication-other participants could be used to provide indirect evidence of the claim. For example, a coworker could be called by a validator to verify that the claimant was indeed at their specified location and attempting to make a claim to the validator.

This hierarchical authentication could continue an arbitrary number of levels as required to satisfy the level of authentication required. Collectively, these three vectors form a space in which a mathematical model can be applied that determines a quantifiable “trust” of the identity via the collection of authentication mechanisms.

Hmm. It seems the word “trust” has slipped into the concept of authentication. Now that we have created a tangled hierarchy, it just might be interesting to see how far down this spiral we can go….
- posted by Terry Cowart @ 4:22 AM 0 comments

 
Trust Whom?
A great deal of interest is placed these days on the mechanisms whereby trust can be conveyed in a distributed system. I must admit that this problem is one of great interest to me personally, as well as a number of friends of mine. I cannot help but notice, however, that the concept seems much clearer in our daily lives than in the world of the internet. What exactly causes this dichotomy?

One answer is the mathemechanical nature of such systems on the internet. It would a very different world indeed if, when speaking to our friends, we first had to do a number of calculations involving such things as products of prime numbers prior to knowing who was in front of us. This perspective does create another possibility of the nature of the dichotomy that I believe warrants further investigation.

In our daily activities, the subject of trust doesn’t even arise until we know the identity of the recipient. A sentence such as "I trust you, though I have no idea who you are" simply makes no sense. Therefore, it seems that identity is the precondition of trust-- and a precondition we have yet to settle in the world of distributed systems.

The process of ensuring that the identity of an entity in a distributed system is valid is called authentication. This, it seems to me, is the real problem we face in establishing trust. While we have a number of ways by which we can establish credible authentication, they are all subject to probability-- either within the mechanism itself, or within their context outside the system. For example, authentication via the verification of created information that would only be possible with the possession of a private key is, from a mathemechanical perspective, nearly foolproof. From a contextual perspective, however, the issues of key compromise and identity management cloud the issue.

There are a number of things that can be done to mitigate these concerns, though the question of whether they can be eliminated entirely is unclear (and, in my opinion, unlikely). I will discuss these mitigation strategies, and other aspects of the problem that I believe are of interest to the creation of a distributed trust model, in future posts. For now, having framed the problem will have to do.
- posted by Terry Cowart @ 5:38 AM 0 comments