Hal 9000

Thinking out of the Box

2005-07-16T12:12:00.000-07:00

Don Box has apparently taken the high ground on the BOA acronym. How could I have forgotten Business Oriented Agents? I just hope my previous post on Document Oriented Architectures, doesn't violate any of Don's Other Acronyms (DOAs). Also my apologies to the CORBA crowd, where BOA means Base Object Adapter. I guess there are just not enough TLAs to go around!

SOA is a design philosophy

2005-07-05T07:22:00.000-07:00

SOA is a design philosophy, not a technology or a methodology

John Evdemon

A service oriented design philosophy views an application as a collaboration of more basic core services. A Service Oriented Architecture (SOA) is an ensemble of such services.

Services are best explained as centers of value. (a’la Christopher Alexander). Paraphrasing Alexander, services are building blocks of business capability, not truly bounded entities but are in fact non-bounded centers. Here, “non-bounded” refers to their implementation. From outside its interface, a service is a black box of unknown scope and complexity.

Service interfaces are bound by a platform independent contract. Services protect information and form trust boundaries within an Enterprise Architecture.

I agree with Martin Fowler that Service Oriented design philosophy is often confused with service interface implementations (Martin Fowler)

A service is a program.
A web service is a communication tool.

Clemens Vasters

Business Orient Architecture (BOA?)

2005-06-24T05:32:00.000-07:00

No one knows how to design Service Oriented Architectures from scratch. But that's OK, since no one is really starting from scratch. Perhaps, someday we will have Service Oriented Analysis and Design methodologies. But for now we are all contemplating how to add services to existing legacy systems.

So the important question is how to design a good service. I don’t know the answer to this. But I do know that a good service will be understandable by a business person. If you cannot explain a service to a manager than it is probably a poor choice. That does not necessarily mean that it is a good service. As the enterprise IT architecture evolves and more services are added there will certainly be service re-work and Refactoring

If I had to guess what a service oriented architecture will eventually look like, I would guess that it would reflect the business architecture – Business Oriented Architecture (BOA). Business organizations have evolved over many centuries into a number of common “departments” – sales, accounting, personnel, etc. Perhaps that is a good starting place for services.

Service Layers

2004-12-10T06:13:00.000-08:00

Not all services are the same. Like objects, I think of services being focused on particular concerns within the enterprise architecture. Outer layers are primarily concerned with process and interacting with external actors. Inner layers are concerned with entity management and coordination.

At the innermost layers you have services that maintain what Pat Helland calls resource data. Resource data record the state of essential, long-term enterprise entities – like products, customers, employees, and money. Ideally each entity would be guarded by one service. And that service would support simple interfaces to create, retrieve, update and delete (CRUD) entities. They “guard” the data by enforcing the appropriate security policy and business rules.

Unfortunately, not all of the information about an entity is managed by single service, or located in a central place, or has identical business and security constraints. So in real enterprises we find that data about a single entity is distributed. Take employees, for example, some information about employees is manage by the HR department, and some by payroll department, and some by the security department.

This creates the need for a service layer concerned with managing aggregated entities. These services provide a single interface to enterprise entities, hiding the partitioning from the outer layer of services. They distribute updates and aggregate retrievals, creating the impression of a simple entity. And they coordinate creation and deletion of entities among its partitions. For example, hiring or firing an employee must be coordinated among the HR, payroll, and security departments.

Above the entity layers, we find the workflow layer. The services in this layer manage long-term enterprise processes, like order processing, loan approval, hiring or firing an employee, or month end closing of the accounts. Like entity services, workflow services manage persistent data - the state of the process. But, unlike entities, workflows are expected to terminate eventually. With this layer we transition from the static to the dynamic. It is here that many of the governance and compliance rules are enforced.

If the entity layer dependencies are trees, the workflow layers are graphs. An enterprise’s processes are typically highly interdependent. And so are their services. It may be difficult to manage these interdependencies. If they become sufficiently complex, then some way must be found to layer the workflows between primitive processes and higher–level processes.

Finally, there is the interface layer. This layer is focused on interacting with the outside world. This includes interaction in the form of applications that interact with humans and choreographies that interact with the services in other organizations. I think of these services as implementing “Use Cases” or sessions. They serve as interfaces to the workflow and entity layers.

Documents vs Parameters

2004-11-29T06:14:00.000-08:00

In a Service Oriented Architecture I think of services as departments in an organization. I don’t know how your organization works, but in mine you must fill out the proper form in order to get anything done. Of course, the first step in the process is discovering which department and what form is required. Once the form has been fill out and sent to the proper person, no additional information is necessary. If you have not filled out the form properly, that person will tell you immediately. But, if all goes well, sometime later a document arrives containing the information that you requested or notifying you that some action has been taken.

I think of software services the same way. First I locate the appropriate service. I then determine the desired operation. Each operation is characterized by a pair of documents that are sent to and received from the service. I generate an instance of the first document, send it to the service location, and await a response in the form of the second document. The response is often just an acknowledgement that a proper requesting document has been received. The actual effect of the operation may not become known until a later event that is signaled by the arrival of a document from the service.

That’s a little confusing. So lets call the first document a request, the second an acknowledgement, and third a response. If the service can respond immediately then the response serves as an acknowledgement.

My main point is that I view service architectures as Document Oriented Architecture (DOA?). The action is implicit in the kind-of document being sent. To me this is a cleaner view that thinking of services as subroutines that take some set of parameters. What I need to understand is how this view relates to the REST view. Somehow they seem like similar or, at least, sympathetic views.

Server Load

2004-07-16T06:03:00.000-07:00

Maybe I just don't visit enough sites, but I saw something I really appreciated while I was visiting Stock.XCHNG. That was a "Server Load" indicator (progress bar). It allows you the option of coming back later, rather then trying to load something and going away mad.

I've Been Scobleized!

2004-06-07T04:51:00.000-07:00

I’ve been Scobleized! Immortalized! I’m immobilized! Actually, I’m honored to be cited by the most famous blogger of them all. Thanks for the kind words.

Models

2004-05-17T06:40:00.000-07:00

What is a model? The dictionary defines a model to be a miniature representation of something; also: a pattern of something to be made. It is common engineering practice to use models to facilitate the definition and design of a system being built. Booch points out that; unlike theorems, models are neither right nor wrong. Instead, models are judged to be more or less useful to the engineering process.

Why do we model? Models allow us to focus on some aspects of a structure while ignoring others. For example, a schematic lets us focus on the electronic properties of a circuit and ignore the physical layout of the components. When modeling requirements we want to ignore the implementation – concentrate on the “what” and ignore the “how”. In design we focus on the architecture, ignoring the yet to be implemented code.

By suppressing unwanted details, models make a system easier to understand. Because we are humans our models are often expressed in language or as drawings. This facilitated communication and discussion of proposals, which is another reason that we model. Diagrams, especially, make it possible to visualize a system. Simulations and prototypes allow us to experience a system before we have created a complete construction.

But models can do more than focus our attention or allowing us to visualize a system; in some cases the model provides a framework for thinking and reasoning about the system. A heat flow model of an electronic circuit allows quantitative evaluation of the thermal parameters associated with the component. UML Sequence Diagrams can be used to show precise timing among a set of system events.

Should we model the problem space or the solution space? Up to now Computer Aided Software Engineering (CASE) has focused on modeling the solution space. UML is used primarily to model software elements – classes, objects, interactions, states, etc. Model Driven Architecture (MDA) emphasizes transformations from one model to the next, presumably eventually arriving at a source code model. But it is unclear how (or even if) the MDA approach can cross that all-important chasm between models of the problem and models of the solution.

Clemens Vasters: Indigo'ed - Lightweight Transactions - A puzzle (I mean, really..)

2004-05-10T11:06:00.000-07:00

Clemens Vasters: Indigo'ed - Lightweight Transactions - A puzzle (I mean, really..)

Despite the author's claim that writing resource managers is, hey, it's really trivial, I find this code difficult to understand. Though, it might be simple to write; understanding what's going on is hard. Yet, something tells me that his view is profound, since it supports both pessimistic and optimistic locking - or even a mixture.

Nag, nag, nag,...

2004-05-10T08:07:00.000-07:00

Well, my son (devhawk.net) has been nagging me forever to start my own blog. With bolg.com it seems so easy that I guess I had better try. So, here goes...We'll see if I have enough to say to make it worth while.

A little background:

I've been around computing for a long time! My first job after getting my doctorate was at Bell Labs. In the Spring 1971 I installed my first Unix system - with Ken Thompson help. Because my thesis delt with compiler theory I was interested in C from the beginning - static routines was my suggestion.

Over the years I've worked on air traffice controls systems, case and office tools, handwriting recognition algorithms, to name a few. I am one of the authors of the Systems Engineering CMM.

Currently, I teach OO Programming, and OO Analysis & Design at Johns Hopkins University (part-time engineering school)

My current interests include Security & Enterprise Architectures for a large gov't agency; designing Service Orient Architectures; and software development tools.

I guess that's a start...