Skip to main content

OASIS Service Oriented Architecture Reference Architecture Face to Face

And if you make it past the title ...

This week we had a face-to-face meeting of the RA group. About 10-12 people popped in at some time during the meeting, with a hard core of 7 or 8.

I think that the work is still not at the Jello stage, but we are beginning to get there.

This is not yet reflected in the written work, but there will be three main sections, each of which represents a major viewpoint on the reference architecture:

  1. Business as Service view
  2. Realizing Service Oriented Architecture
  3. Owning Service Oriented Architecture
The first view focuses on the how people fit into the SOA; the second focuses on how you put one together, and the third focuses on keeping one going.

I am particularly happy with this kind of breakdown, as I believe it reflects customers' true concerns.
Labels:

Popular posts from this blog

Comments Should be Meaningless

This is something of a counterintuitive idea: Comments should be meaningless What, I hear you ask, are you talking about? Comments should communicate to the reader! At least that is the received conventional wisdom handed does over the last few centuries (decades at least). Well, certainly, if you are programming in Assembler, or C, then yes, comments should convey meaning because the programming language cannot So, conversely, as a comment on the programming language itself, anytime the programmer feels the imperative to write a meaningful comment it is because the language is not able to convey the intent of the programmer. I have already noticed that I write far fewer comments in my Java programs than in my C programs.  That is because Java is able to capture more of my meaning and comments would be superfluous. So, if a language were able to capture all of my intentions, I would never need to write a comment. Hence the title of this blog.
Read more

In Praise of Crappy Code

Not all code needs to be perfect! This is pretty heretical thinking for a software engineer. The issue is simple: how do you go about developing software for a small fixed budget. Imagine that you have $500 to implement a solution to a problem. If you spend more than that you will never recoup the extra that you spent. This comes up a lot in systems integration scenarios and also in customization efforts. Someone wants you to 'tweak' an application that they are using; you know that no-one else would want that feature and that if you spend more than what the customer will pay you will end up losing money. From the customer's perspective, the common 'time and materials' approach to quoting for software development is a nightmare. Being able to offer a fixed price contract for a task is a big benefit for the customer. But, how much do you quote for? Too much and you scare the customer away. Too little and you lose money. This is where 'crappy code' com...
Read more

Existential Types are the flip side of generics

Generic types, as can now be seen in all the major programming languages have a flip side that has yet to be widely appreciated: existential types. Variables whose types are generic may not be modified within a generic function (or class): they can be kept in variables, they can be passed to other functions (provided they too have been supplied to the generic function), but other than that they are opaque. Again, when a generic function (or class) is used, then the actual type binding for the generic must be provided – although that type may also be generic, in which case the enclosing entity must also be generic. Existential types are often motivated by modules. A module can be seen to be equivalent to a record with its included functions: except that modules also typically encapsulate types too. Abstract data types are a closely related topic that also naturally connect to existential types (there is an old but still very relevant and readable article on the topic Abstract types have...
Read more