Andrew Doble's Blog

Developing for the Cloud

2012-01-02T13:39:00.000+01:00

I’ve recently come across two apparently unrelated articles that together imply a lot about how development for the cloud should be done.

The first refers to post by Steve Yegge. In this he explains how Amazon embraced service orientation and what that meant for the developers and the company.

The second article is from Simon Wardley in which he laments that current “enterprise” cloud developments have a product rather than a utility mindset, i.e.:

Unfortunately, many applications are designed with the best practice for a product world i.e. scaling is about bigger machines, resilience is about N+1 and in general the focus is on reliable hardware. Best practice for a utility world involves resilience, scaling and failure modes built around software i.e. design for failure, distributed systems and chaos engines such as Netflix's chaos monkey approach. There is an inevitable cost of architectural transition from one set of best practices to another.

Both of these provide lessons in how to develop for the cloud:

Use SOA with clear contracts and a mechanism for handling contract violations.
Loose coupling between sub-systems is essential for business survivability in an unreliable distributed computing environment a.k.a. the cloud.
Develop platforms, and with it the ability to continually extend what’s offered.

What's PaaS?

2011-11-22T17:53:00.001+01:00

One of the models used to explain the cloud computing service offerings - derived from the NIST model - shows the service models arranged as a stack. Implicit in this model is a usage hierarchy (explicitly shown in the diagram below) , that is BPaaS will use SaaS, SaaS uses PaaS to provide an abstraction from underlying computing resources and IaaS provides the basic resources. This seems to make a lot of sense to software architects who recognise a familiar pattern.

However, one of the problems I face when talking about PaaS is that many have different preconceptions as to what it is, usually derived from what is currently being provided by various cloud vendors. These range from:

Provided PaaS Services	Example Provider
A set of services for resource allocation in a IaaS service model.	Amazon EC2, Rackspace
Basic middleware and data storage services.	Amazon Web Services (AWS)
A set of application services.	Goggle App Engine (GAE)
Model driven development platforms in the cloud.	force.com
Application development framework for cloud computing.	vFabric, Heroku
A process development framework in the cloud.	Cordys Process Factory, IBM Blueworks Live
Platforms that provide a set of business functionality that can be built upon.	CRM functionality, platforms that provide document management and process automation etc.. PaaS at this level seems to be a underdeveloped model.

Looking at this suggests that the simple model as proposed by the NIST is, in fact too simplistic. So what should the model look like?

One possibility I like, is to place the PaaS service model to the side of the others and show that they are used by two different roles, i.e.:

PaaS is then a set of functionality that can cover the development needs for the complete spectrum from IaaS to BPaaS, but in practice each cloud service provider will only cover a limited set.

(Update: I've been having some problems with the images displaying. Reloaded them so hopefully it works now.)

Architectural Decisions

2011-06-26T17:57:00.009+02:00

If you are trying to implement any kind of architecture management you have to start documenting the architectural decisions you have made to keep future developers aware of the problems that were faced and why they where solved that way. But what information should be kept? One model I have used in the past is the Tyree-Akermann model (published in IEEE Software March/April 2005). This captures the issue, the alternative solutions considered and, of course, the decision itself. In addition, the model is extended with information that supports the decision (e.g. architectural principles, business factors).

This isn’t the only model that can be used. IBM have developed one in some detail and the ARC42 project has, as part of a software documentation template, developed an implicit model (only in German).

Now, one way to go, would be to consolidate the models to derive a "universal" architectural decision. However, since reading "Architectural Design Decisions as Reusable Design Assets” by Olaf Zimmermann (originally published in IEEE Software Jan/Feb 2001, but now available here), my thinking has been pushed into concentrating on using the decisions to provide a knowledge base for other architects, i.e. reference architectures.

Zimmermann’s paper proposes, that when creating a reference architecture, not only the component, connector, patterns etc. are documented, but also the issues that the architect has to solve together with the design alternatives available in applying the reference architecture to a real situation. These issues - complete with alternatives and recommendations - form a guidance model. This guidance model is then tailored to the project situation to produce a decision model and extended with the actual outcomes.The beauty of this simple scheme is that the guidance and decision models have the same structure making it easier to extract best practices from completed architectural documentation. Zimmermann goes into a lot of detail about this, but I have tried to summarize it with the following two diagrams:

1. The structure of the models. Although Zimmerman uses a SOA reference architecture as an example, the principle can be applied to any reference architecture as I’ve tried to show in the diagram.

2. A (simplified) process showing how the guidance and decision models are used in architectural design.

Two main challenges still remain though - getting your architects to document their decisions and setting up an organisation and processes that can actually extract and propagate architectural best practices.

Quantum computers - a commercially viable option?

2011-06-12T16:38:00.003+02:00

Way back at the beginning of 2007 I posted a minimalist comment expressing some incredulity that a company - D-Wave - had been founded to develop and sell quantum computers. I've now just seen that they have sold one to Lockheed Martin for undisclosed purposes.

So when can we expect a quantum computing service in the cloud (a.k.a. QaaS)?

It's Alive

2010-11-10T17:16:00.004+01:00

This seems to be the analyst's reaction to the Burton Group's claim, that despite previous doubts, SOA is alive (see David Linthicum's coverage on this).

In talking to clients there does seem to be a tacit acceptance that SOA principles (rather than the technology) are the way forward. However, many do not want to mention the SOA word, perhaps out of fear that the idea will be seen as another (expensive) technology fix, rather than as a partial solution to some of the problems (high costs, unresponsiveness to business demands, lack of innovation) that currently plague enterprise IT.

The SOA Roller Coaster

2010-07-12T14:54:00.002+02:00

Joe McKendrick thinks that the SOA roller coaster has moved on and is now moving along the plateau of productivity.

The Internal Cloud

2010-07-03T15:33:00.001+02:00

A few years ago we lived trough the rise of the web. For those working in enterprise computing this new world used a set of exotic technologies such as HTTP, HTML, Browser, web servers that had no place in the IT landscapes that existed then. As the business advantages of "e-business" started became clear, many companies started embracing these technologies so that they too could compete in this space. Whilst this was happening, another, more subtle, revolution was taking place within the walls of traditional IT. The very technologies that powered a company's web presence started finding there way into the design of internal applications. IT managers started demanding that applications became available over a browser; the cost savings in not having to deploy to each client providing a powerful argument for this. Business departments started demanding portals for their own staff and web based interfaces for the growing number of homeworkers. In the mean time these technologies have become commonplace in most companies and in the area of WS* based technologies have found their own niche.

We now faced with the next new thing - cloud computing. Although many are focusing on the advantages of "moving out to the cloud", are there already "weak signals" that cloud technologies will become as commonplace in enterprise IT as e-business technologies have already become.

Let's have a look at some of these starting off with virtualisation. OK, this is no brainer as many are already adopting this today. However, virtulisation also leads to having large images for each virtualised application - a obvious cost factor when you consider storage. One way around this, and an idea taken from SaaS providers, is to have a strong form of multi-tenancy. In this model, core functionality remains the same (and is virtualised) but specific processes, rules and screens for different user groups are developed by configuring the core functionality, rather than developing new applications.

Cloud providers have also changed the way we think about databases. Many are under the impression that there is only one type of database and it's relational. However the rise of the NoSQL database has shown that other types of databases have properties that can be attractive for different types of application.

In order to achieve the levels of performance and scalability that cloud providers need, they seem to have totally abandoned the three tier architectures that predominate in post year 2000 enterprise systems. Instead, other architectures that either cache the data or provide ways of directly manipulating objects as if in memory are standard. This has lead to a new class of application server that performs the heavy lifting of handling the distributed processing and data behind the scenes - examples include Terracotta, Gigaspaces, and Coherance. These types of application servers have already stated making in-roads into the financial services sector, due to the extreme performance requirements there. From an architectural viewpoint however, there seems to be a grey zone here between NoSQL databases and these "in-memory" techniques.

The humble batch job can also expect a work-over, with techniques such as MapReduce and systems such as Hadroop gaining ground.

Bringing this all together on the consumer side there is the architectural technique previously known as SOA coupled up with mash-up frameworks and associated standards.

I'm pretty sure that eventually these kinds of technologies will become so pervasive in the typical IT shop that we will forget the cloud hype and just get on building systems with them.

The Virtual Enterprise - Updated

2010-01-21T21:15:00.001+01:00

Around 2005 I wrote a series of blog entries (starting here) asking if an enterprise IT could be completely covered by SaaS applications (the word cloud wasn't used then so I talked about a "virtual enterprise"). Gartner now predict that "By 2012, 20 percent of businesses will own no IT assets".

Disregarding if 2012 is the right time-frame, what type of enterprise could dispense with all of their IT assets. I can only assume one in which IT offers no competitive advantage.

Looking back on those old blog posts, I also noticed that a lot of the SaaS companies I mentioned either don't exist anymore or have morphed into something else. If you believed in 2005 that you could dispense with IT assets, then by now you would have realised that you need to be capable of moving your information assets to different SaaS providers and adapting your business processes accordingly. This is probably still true in 2010 and will be something to consider by the 20% of "IT free" companies in 2012.

Coding the architecture or architecting the code

2009-04-03T13:48:00.002+02:00

Many have asked the rhetorical question „Should software architects code?” In my experience if you ask that question directly to an architect who does code you get a resounding “yes” and a look that suggests heretical attitudes in just thinking of asking. Ask the same question to an architect who does not code, you get a resounding “No” and are left with the impression that coding is somehow a menial task that real architects don’t need to get involved in.

Sometimes though, if I listen carefully or reflect on what I do or have done, I get glimpses of what software architects hope to achieve by coding. This leaves me with the impression that the question should be rephrased to “Why should software architects code?”

Let’s list some answers:

A software architect has to communicate with the developers in order to guide them in implementing the architecture. Writing code is the only way to communicate the intent of the architecture. Ultimately this comes down to the fact that no “language” exists to communicate architectural intent that is both understood by developers (who read it) and architects (who write it). Although UML goes someway to fulfill this need, judging by the number of architects who feel they should code, it doesn’t seem to go far enough in explaining architectural intent.

The architect has to ensure that the system being developed actually implements the proposed architecture. As documentation is suspect and may even not be there, the architect has to read the code. But wouldn’t it be more efficient to have a tool that extracted the architecture from the code so that the architect only needed to make a comparison? Unfortunately tools to visualize the architecture based on the code do not seem be mainstream, especially in the context of modern distributed software systems (i.e. the type of system we really would like to see the architecture for!).

Architects need to code to understand new components, frameworks, ways of doing things etc. Most artifacts that are intended for general use in the software world are, from the viewpoint of an architect, terribly documented. Instead of providing clear advice on where a component (or framework or library) can be used, what problem it solves and in what context it solves that, most documentation forces the reader to go through page after page of coding examples which only show how it can be used. In short, the how, why and where are not there.

And some just like coding. The problem with this is that the architect can find themselves very quickly on the critical path for development leaving little time for architecting the rest of the system.

Most of the above are about one thing - communication of the architecture - be it from architect to developer, developer to architect (via the implemented system) or supplier/vendor etc. to the architect. Software architects seem to be trapped like the prisoner in Plato’s cave. They cannot see the architecture, but only the shadows of it in the code.

Isn’t about time to change that?

Architecture that learns

2009-03-19T20:58:00.002+01:00

I recently came across a rather old (1997) BBC series on architecture - buildings rather than software. The series - "How Buildings Learn " - concentrated on what makes a building adaptable to the continually changing needs of those who live in them. The parallels to software architecture are astonishing. There is even an interview with Christopher Alexander - that's right, the man who inspired the patterns movement.

The Pentagon Model of Service Contracts

2008-12-05T16:46:00.003+01:00

Many have stressed the importance of an service contract model in specifying services in an SOA. But what should a service contract contain and what is its structure?

One model I have been using is what I call the the "Pentagon Model". No, this does not have any thing to do with the US Department of Defence, but comes from the broad shape of the relationships between parts of the contract (see the diagram).

The model starts with the premise that any contract is between a consumer and provider and is not directly associated with the thing that is the subject of the contract. Secondly the subject of the contract is the service operation rather than the whole service.

Let's illustrate this with an example. If you were implementing a CRM service then this may have operations such GetCustomer, FindCustomer. It stands to reason that each of these operations has a different contract due to the different interface and that they may well have different SLAs (searching for a customer probably takes longer that just returning one specified by a key value). However you may want to specify different SLAs for the service operations when they are called from the corporate network than when called over a mobile phone connection by a mobile sales force. Most definitely the security policies would be different in each case.

Changing the consumer is one thing, but why also have the contract depending on the provider? Well, you may have a number of providers for the same service interface. For example, the CRM service in Europe may have different response times and access policies associated with it than when accessing the same service interface, but using the CRM provider in the US branch. This is even more important when accessing sensitive information that may be subject to the laws of different jurisdictions.

This model is, of course, a simplification of a complete service contracts model. It starts to get complex when you have to model the policy structure and also have to take into the account that providers can be consumers. But it provides a simple framework to start thinking about service contracts.

Think about the arrows

2008-12-02T20:14:00.003+01:00

When doing architecture reviews. I'll often point at one of the arrows on the architecture diagram and ask "what is this?". Depressingly I often get an answer similar to " Well, component A talks to component B". Rarely do I get an answer will actually explains:

Why the components need to communicate
What information is communicated
What the arrow indicates (e.g. flow of information)
What component initiates the communication
How the information is represented
What protocols are used
What is physically used to transmit the information

In designing an software architecture I've always found it useful to think about what the arrowed lines actually mean as this often provides insights into how the design will actually behave. I was therefore happy to see that at least somebody else also thinks the same way and have submitted a software axiom ("Architects focus is on the boundaries and interfaces" by Einar Landre) to Richard Monson-Haefel's 97 Things. If you haven't come across this before, 97 Things is a set of "axioms for software architects by software architects" and should be published by O'Reilly next year.

Trough of disillusionment

2008-12-01T15:17:00.003+01:00

Mr. Gartner had built a new roller coaster based on his, now famous, principles which ensured that every ride was indeed a heady experience which one would not easily forget. His previous rides, often simply named with combinations of letters, were indeed exhilarating experiences. I was eager to ride this one, famously called SOA, and was lucky enough to be now sitting in the front carriage, which was slowly taking me up the steep incline. As the carriage ascended I was able to take in the magnificent vista of the landscape lying below me, revealing a hitherto unknown complexity. But then, looking forward again, I realized I could not see the track in front of me. In fact I seemed to be poised on a great void. It was then that I realized that I was heading into the trough of disillusionment.

BPMN Again

2008-03-14T12:40:00.002+01:00

I've posted in the past about trying to find good online introductions to BPMN. Recently Bruce Silver has released some excellent e-learning material on SAP's Business Process Expert community site (registration is required).

Bruce uses some as yet unreleased software to diagram the BPMN examples he uses. I've taken the cheap route in the past and have been using some of the free Visio stencils I mentioned in the last post. Recently though I've been using a elegant stencil from Orbus software. Unfortunately it doesn't cover all of the features (e.g. catching and throwing events) and symbols in version 1.1 of BPMN.

Application Servers - The Next Generation?

2008-02-22T13:44:00.004+01:00

I recently came across this in an InfoQ post (my highlighting):

Paremus recently released version 1.2 of Infiniflow, a next-generation distributed application server based on OSGi and SCA.

What is interesting is the tacit acceptance that there is now a "next generation" of application servers.

SOA in Cloud Cuckoo Land

2008-02-20T21:03:00.002+01:00

There seems to be a general feeling that SOA services will somehow just exist out there in a cloud. The nitty gritty of their implementation, of who is actually responsible for them and how they are managed is hidden behind the service interface and the consumer doesn't have to worry about it.

If you had that point of view and you'd been using Amazon's S3 services you would have been hit when the S3 service went down last week. If you boil down Amazon's explanation to it's essence it seems that the number of "consumers" increased unexpectedly and overloaded the security system. Now Amazon's up-time statistics are maybe very good, but systems still go down.

Now say that you're implementing a SOA in your company. The services provided are going to be mission critical (just like your applications are). But one day, they will go down. And when they do you better make sure that you know who is responsible for them, what the implementation is so that you can fix things and that the management is so set up that the right people are brought to the problem as soon as possible (and while you're at make sure that you've defined the SLAs for the services, governance processes are in place to ensure that usage profiles are known in advance and that the services are monitored so that you can spot possible problems before they become serious).

ESBs again

2007-09-29T16:55:00.001+02:00

I've posted in the past about what ESBs really are (and why we need them). As evidenced by this entry in InfoQ the discussion seems to be widespread in the industry. I sense that we are entering one of these "grand" debates like SOAP vs. REST. This time it's the question "do we need an ESB or are WS standards enough".

BPEL4People - The Architecture

2007-09-25T16:44:00.000+02:00

As I explained in my last post, the new BPEL4People draft standards are intended to integrate people into those business processes that are being controlled by a “requesting application” ( I think it’s pretty safe to assume that in most SOA implementations this would be a process engine running BPEL). The draft spec itself is split into two parts. The first (WS-BPEL Extension for People) explains how BPEL can be extended with specific process constructs to deal with human interactions and lists a number of ways (called constellations) that the management of these tasks can be implemented. From an architectural point of view the most interesting one is when the task infrastructure is decoupled from the process infrastructure and a separate spec (WS-Human Task) has also been released to cover this. I’ve tried to convert this last “constellation” into a more detailed architecture diagram:

How does this all go together? Let’s start off at the simpler end. The basic assumption is that people provide services by acting on tasks which have been assigned to them. To see and handle the tasks which have been assigned to them is done using a task client. This is not specified by the specification, but it is a relatively safe bet that will take the form of a user interface with some kind of task list which the user can interact with (for instance, in a SAP environment this could be a universal work list). The user interface interacts with a task management component which stores the tasks assigned to the users. Again, it’s pretty likely that the task manager will be a central component that can hold the tasks for a number of users each of who has their own user interface. The spec defines the services which the task manager component exposes to a user interface. I’ve grouped them into three categories:

Life Cycle, i.e. claiming a task (i.e. saying you’ll do it), starting, suspending and stopping tasks etc.
Query, i.e. finding tasks based on certain criteria. The most important one here is getMyTasks.
Administration services such as explicitly nominating someone to a task

To do this the task manager needs to access some information regarding the people. The spec assumes a people directory with an interface for queries, but doesn’t actually fix what this looks like.

So how do the tasks get into the task manager? Conceptually this is very simple. The task manager exposes a service for the business function (or functions) which need to be performed by a human. The service can then be called from another application or a process engine. Once the service has been invoked, the task manager creates a task which, as far the users are concerned, appears in a task list and can be dealt with over the task client. The user can then decide to act on the task until it’s completed. I’ve sketched a simplified scenario (using as an example a credit approval service) in a UML sequence diagram:

I must admit, I find the interface between the requesting application (the process engine in our scenario) and the task manager rather specific to the business logic required. The task manager has to expose specific services such as ApproveCredit rather than use a more general approach with services such as TaskCreate. This implies that any service developer will have to use an API which is specific (i.e. proprietary) to the task management component being used.

The above only sketches some of the main features found in the draft specification. Other features (such as notifications and placing service calls in a context) I haven’t included. The spec also defines in detail the messages between the main components. I look forward to more articles detailing what the specs actually mean for architects.

SOA: The Human Angle

2007-07-21T15:20:00.001+02:00

Most discussions on SOAs assume an architectural model in which services are provided by software and these services are in turn consumed by clients (e.g. user interfaces) or are orchestrated by a process engine. A good example of this type of thinking has been recently published by a set of authors from IBM in IEEE IT Pro. In their article, “S3: A Service-Oriented Reference Architecture” they describe a metamodel which:

“ … captures architectural building blocks … as well as the relations among these blocks and among layers, interaction patterns, options, and architectural decisions.”.

However , although most of these SOA models talks about business processes they give scant attention to the role of humans within those process. For instance, at one stage in a credit process we might need someone to approve the loan. Effectively this means that the approver is providing a service – deciding on loans using their experience and intelligence. In the IT Pro article we come across this statement:

“An SOA ... would support that process by creating a composite service that choreographs the information flow among a set of services and human actors”

But that’s it. How the human actors are actually integrated into the SOA is not explained. This is fairly typically for most of the literature in this area which assumes an architectural model such as:

I was therefore interested to see that the BPEL4People draft specification has been recently published by a consortium of companies with the intent of getting this ratified by OASIS as a WS-* specification. BPEL4People is a set of extensions to the BPEL specification that address scenarios in which humans are involved in business processes. How it does this from an architectural point of view I’d like to explore in my next entry.

German government specifies SOA

2007-07-10T15:55:00.001+02:00

The German federal government has released an IT Architecture for the administration. Surprisingly (or perhaps not, depending on your PoV) it's service oriented.

Currently it is only in German, but often such documents are translated into English and published on the same web site later.

More on ESBs

2007-07-09T21:13:00.001+02:00

Just to muddy the waters in trying to explain what an ESB is (and why we need one) I came across this (dated 2005) presentation from Jim Webber (you have to display it in presentation mode to see it all). Jim doesn't hold much with ESB vendors and believes that the "bus" should just be SOAP and WS-Addressing.

The slide set reminds of a colleague (I wish I could remember his name) who once said "it is almost criminal to let a vendor determine your architecture".

Point-Point, Hub-and-Spoke, ESB

2007-06-28T21:46:00.000+02:00

My colleague Mark Masterson asks in his blog about the “fitness of the classical "hub and spoke" architecture in a modern enterprise systems landscape” and “what, exactly, is the purpose of an enterprise service bus (ESB)?”

As he points out there is a lot written about this, but nothing seems to be conclusive. When confronted by such situations I attack them by asking “want do we really want” and then work backwards to “what have we got”.

So, the first question is; do we want a “hub and spoke” architecture? Well, this was proposed as an answer to the point-to-point interconnection style. Continuing on with this ruthless analysis (so beloved of Dr. House) let’s ask the seemingly dumb question; do we need a point to point interconnection style?

Point to point came about because people needed to transfer data between applications. As time went on, more and more applications were written and, with them, more and more point to point interconnections were produced. This lead to a nightmare IT landscape which nobody could understand, let alone maintain (I once did an application inventory for a client in which the interfaces were also documented – the result filled four sheets of DIN A0 and made for interesting wallpaper!).

To solve this the hub-and-spoke architecture was proposed, which lead to EAI tools etc. etc.. But that was then and this is now and I think we have to ask again: why point-to-point?

In the brave new world of SOA we don’t have applications which need to pass data between themselves. Instead we have autonomous services. These are arranged in a hierarchy (although not a strict one) . Services are consumed by other services (e.g. composite services call atomic services) or, at the top nodes, by service consumers such as user interfaces. If we start building systems to implement this architectural style, we soon start to realize that certain functionality is required time and time again. We need to implement small processes which call services in predefined sequences, data needs to be aggregated from many sources or needs to be distributed to other services. The data needs to be transformed, enriched, split up. In addition we need build low level coordination between the services, so that we can implement concepts such as transactions and security. We also need to ensure that data is really transfered to the services (i.e. reliable delivery) etc..

All of this is what we really need to implement an SOA. But instead of implementing this all ourselves, we buy these things from somebody who has packaged it all together and given it a name - ESB.

Using this analysis means that the original question of fitness of a hub-and-spoke system is a question that does not need to be answered as a hub-and-spoke architecture is irrelevant for a modern systems landscape if an SOA style is used.

Designing Interfaces and REST

2007-06-19T17:49:00.000+02:00

I've blogged in the past about how the design of interfaces in distributed systems is an important, but often overlooked topic. Instead the current debate seems to be around the technology used - SOAP, REST - rather that the interface design itself.

I was therefore interested to come across this blog entry from Joe Gregorio in which he applies REST technology to the design of the Apache DayTrader benchmark. What I find striking about this entry is how much care he has given to the interface design, reducing the original, and somewhat ad-hoc interface specification, to simpler principles based on a few entities and operations.

Tools for Globally Distributed Development (GDD)

2007-06-12T17:39:00.000+02:00

Working for a company that routinely spreads its development out through the world I was interested to come across this report from Ryan Bagueros on how a small software development company can set up the tool support for GDD on the cheap by using tools available on the web. As he says:

"With some careful setup, any group of developers can compete with the budgets used by multinational software development firms to distribute their application engineering ..."

Of course, these tools do not need to be used on the scale of global development, but can be used on smaller scale developments where the developers do not all sit together.

Using BPMN

2007-06-07T08:16:00.000+02:00

As an architect I often have to sketch the processes to see how everything goes together. Over the last year I been increasingly using BPMN to do this, either on paper or with Visio. Unfortunately there doesn't seem to be much out there in the way of books which explain how BPMN should be used . Instead, I use a couple of tutorials written by Stephen White from IBM. Those with patience can use the textual version, for the impatient the slide show is the best.

As to sketching processes in Visio a number of stencils (with various levels of completeness and features) are available on the bpmn.org site.

Developing rich internet apps - what to use

2007-02-17T15:48:00.000+01:00

A quick round up of what seem to be the current major development libraries and/or environments for developing RIAs.

Flash is the well-known browser plug-in from Adobe as well as the development platform. Adobe have also announced in the mean time - but not released - Apollo as a cross platform run-time that handles Flash, Flex, PDF, plain HTML or Ajax based user interface. Effectively a type of universal client instead of the browser.

DoJo is an open source javascript library. As well as the usual UI components, one feature I find interesting are components to store data on the local drive. I first saw this feature used in TiddlyWiki.

script.aculo.us is also a javascript library. It is based on the Prototype javascript library.

Google Web Toolkit (GWT). The GWT lets developers write code in Java which is then converted to JavaScript apparently apparently freeing the developer for learning JavaScript (Java developers are assumed here, not a bad assumption for most enterprise development work). This has been nicely written up in a IBM developer world article.

Are there any more?

Loosely coupled interfaces

2007-02-14T17:24:00.001+01:00

I posted a short while back an entry about designing generic service interfaces. By chance I happened to come across this (rather old) blog entry by Carlos E. Perez in which he proposes extending speech acts to define loosely couple interfaces. He bases it on a paper by researchers at Stockholm University in which they try to provide a universal framework for human communication in an economic domain, i.e. the business world (the paper is still marked as work-in-progress, so I guess it hasn't been peer reviewed). To do this they use a a triple:

(intention, action, object).

The values each element can take on are:

	Intention		Action
	propose		create
	accept		change
	reject		cancel
	declare		none
	query
	reply
	assert

So, to create a new customer record the triple could be:

(propose, create, aCustomer)

the service could then return with:

(accept, create, aCustomer)

or, in the case of an error could return:

(reject, create, aCustomer)

You can have a lot of fun thinking up new combinations. One thing to notice is that services themselves don't seem to have names. Instead, one could envision a dispatcher which takes each received triple and then finds the correct service implementation.

If this would work out in practice, I do not know. But it seems to aid support to my argument that the REST vs SOAP debate is about which technology should be used, and not about designing interfaces to achieve loosely coupled services. How to achieve this should be the real debate.

Quantum Computers

2007-02-13T20:32:00.000+01:00

Really?

The next n-tier architecture

2007-02-09T15:55:00.000+01:00

It seems that the now traditional three tier architecture may well be slowly coming to an end. For specialised high performance applications, the bottlenecks between the tiers have already been pushing developers in this area to turn to specialised data caching platforms such as Tangosol, or to unified application platforms such as Intersystems Ensemble. In the data caching area the architecture seems to be consolidating to a cached data pool which is accessible from many machines in a cluster. This trend is now being followed by vendors of "traditional" application servers such as BEA and IBM. For SOAs this has the advantage that each service accesses the same data in the data pool, rather than having to aggregate data from different data sources (see diagram). The application platform deals with all the hard problems of data caching such as data consistency, cache actualization etc.

Not so long ago I saw a presentation from GigaSpaces who also provided a cached data pool. What is interesting about the product architecture is that they have revived the old, and hardly adopted, JavaSpaces concept. The data pool (or space) is a set of Java objects which are effectively in a shared memory accessable from each machine in a cluster. Each object can be accessed by providing a "template" which matches the contents of the objects and returns one of more of the matching objects. Templates can also be set as triggers, so that creation of new objects with particular data characteristics can notify another Java object. If you're still interested, a good tutorial on Java Spaces can be found here.

Building Virtual SOAs

2007-02-08T19:34:00.000+01:00

Doug Kaye has written about how he used Amazon web services to build the infrastructure for his application, i.e.

elastic compute cloud to run the apps
simple storage services to store the content
simple queue services to connect the apps.

And talking about building applications, Coghead (which has recently gone into limited beta) lets users define screens which can trigger user defined orchestration processes and data mappings. Just about what every ESB/EAI/SOA tool can do except that this uses a SaaS model.

Using these tools, what stops you defining a "virtual" SOA, in which the Coghead defined UI triggers the orchestration which calls up web services implemented using the Amazon virtual infrastructure?

On Generic Interfaces

2007-01-13T17:26:00.000+01:00

In his comment on my last post , Steve Vinoski warns against getting into “pseudo-religious technical debates like "REST vs. SOAP”. I agree.

However, for an enterprise architect implementing (or planning to implement) an SOA, the decision still has to be made as to what technology should be used – a decision which could have a considerable influence on the costs and success of any SOA initiative. Such a decision needs to be based on arguments which corporate management understands, rather than hearsay about what apparently works or does not.

The difficulty in making such architectural decisions is not on seeing what simply works. SOAP works, so does REST. Way back in the mists of time (i.e 1999) I worked on a project which used a REST style of communication between the client (an applet - remember those) and the server. I made the decision to use a simple HTTP interface as no other alternative existed then (according to Don Box, the SOAP spec only shipped in 4Q1999). It actually worked surprisingly well (and is still working to this day). REST can work in an enterprise environment.

The problems start when we come to architecture in the large. In large architectures other factors come into play, such as how to manage the interfaces in the face of changing requirements. As Steve mentions in his article "... some of the architects and developers I know who work on large SOA systems ... figured out the uniform interface constraint on their own, without ever hearing of REST". Developing generic interfaces does help, but how generic does an interface need to be?

In the REST model the generic interface supports the four interaction verbs described in the HTTP spec, i.e. GET, POST (equivalent to create), PUT (equivalent to update) and DELETE. However, taking one extreme it is possible to reduce POST, PUT and DELETE to one verb - MAINTAIN - and split the data payload into a before image (BI) and an after image (AI). Specifying the BI and leaving the AI empty is equivalent to a DELETE. Specifying the AI and leaving the BI empty acts like a create. Specifying both is an update, with the advantage that the system can check if the data has changed in the meantime by looking at the BI. Apart from database interfaces I haven't seen anything written about this technique in creating SOAs. I have, however, seen one system which implemented it in a web service context and with SOAP.

As the above example shows, you can still provide generic interfaces with the SOAP/WSDL combination as well as with REST. It seems to me that the SOAP vs. REST debate is arguing about the wrong things. It should about how to design interfaces rather than the technology used for their implementation.

REST vs. SOAP Reloaded

2007-01-10T18:32:00.000+01:00

It seems that Google have decided to drop its SOAP interface in favour of a REST style interface. This again raises the REST vs. SOAP debate. I was therefore interested in reading this article from Steve Vinoski of IONA Technologies. Although he tries to "explain REST from the viewpoint of someone steeped in SOA..." I had the sneaking feeling that he came down on the side of REST, which is even more surprising when you realise that IONA was one of the original exponents of CORBA and has been heavily pushing SOAP over the past years.

Where are the composite app standards?

2006-12-15T13:41:00.000+01:00

In reading about composite applications, I was surprised to see how little work in terms of open source and open standards is being done in this area. I found the following standards:

XForms for web based forms
BPEL for orchestration
WS-CAF from OASIS has only released one part of 3 planned standards.
and of course the whole raft of web services standards

Missing are standards for:

Screen flow, i.e. controlling the order of screens presented to the user.
Work flow in terms of transferring work between people (the so called BPEL4People standard has yet to be published and maybe is not what we want.
Screen layout.
Packing all the bits of a composite app together so that it can be shipped (similar to web apps today).

All this is available in propriety products, which makes me surprised to find that nobody is working on standards in this area and even more surprised that nobody is working on an open source version of a composite application framework.

Will the real composite app please stand up

2006-12-12T11:05:00.000+01:00

In trying to get to grips with what is meant by a composite application I came across this blog entry from Jeff Calow of IBM. He writes that the usual definitions of composite applications all deal with automation, but then asks about the user interface aspects. I would like to extend this and assert that a composite application consists of three optional aspects:

A user interface which brings together in one place everything the user needs to carry out a task. This could be a portal or a scripted front end as found in many mashups . Rich clients are another possibility.
A business process execution environment that not only handles the automation of processes, but also deals with user centric aspects such as workflow and screenflow.
An integration infrastructure that allows data to be transformed from one format to another.

IMHO any self respecting composite application framework should support all three aspects.

More on BPM and OO

2006-11-12T12:40:00.000+01:00

Keith Harrison-Broninski starts to ask in his blog why process modelling is based on a series of activities rather than business objects. He believes that we need an additional object based modelling layer for high level objects and their interactions.

I’ve tried to show in a previous post that BPM and object orientation are, at a deep level, conceptually similar. Rather than yet another layer which represents yet another set of concepts, we really need a unified model which lets modellers (and the underlying software) do what the business wants without having to constantly bamboozle them with different representations.

Reuse and SOA

2006-10-01T13:31:00.000+02:00

In the last week I have heard and read the usual lament that software reuse is hard and has been a dismal failure. As many claim that the main value preposition for SOA is based on reuse, the argument is that it also will be a dismal failure.

Here I have to take a heretical POV and contend that software reuse is maybe hard, but that it exists, has been an enormous success and forms the mainstay of software development today.

Let’s look at UIs. Nobody would develop a UI today without a set of reusable components. What about basic programming. One only needs to look at how rich and extensive the J2EE or .NET class libraries are and how much their (re)use is part of standard software development practices is to see that reusability is the norm rather than the exception.

But what about the bit in the middle, the so called business logic? The enormous success of ERP companies such as SAP is surely adequate proof that reusable business logic is a reality.

The only thing that stands out here is that reusable components are not developed in-house by IT-Shops (as David Chappell pointed out when he asked about in-house reuse programs), but are developed by vendors who:

a) invest heavily into their products and

b) have an industry wide view point instead of a restricted company view point.

Perhaps this is clear indicator to where we can expect the majority of reusable business services to come from.

Difference between OO and BPM Part II - Inheritance

2006-06-10T02:12:00.000+02:00

I tried to show in a previous post that the difference between the brave new world of BPM and the old traditional world of object orientation is really not so different. I left off wondering about inheritance and how that manifests itself in the BPM world.

Now every OO programmer knows what inheritance is. Or do they? It seems that inheritance is a slippery concept. Way back in 1996, Bertrand Meyer (the inventor of Eiffel) published an article in IEEE Computer in which he listed 12 different types of inheritance. It's no wonder that the usual advice given to an OO developer is to keep the inheritance hierarchy shallow – if you don’t, you’ll get swallowed up in the complexity.

Judging by the amount of academic papers written on this theme, it seems that process inheritance is also a complex topic. One which caught my eye, was a paper by Guangxin Yang as part of his Ph.D.. In it, he models process as a set of activities, each of which can trigger events which, in turn, cause messages to flow to other activities. In this way he can allow inherited processes to add new activities, add events, enable/disable triggers and also to change the semantics of the activities so they fit more closely to the business requirements. Although these seem to be powerful ideas, Yang’s paper doesn’t seem to have attracted much attention, only getting 2 citations according to Google Scholar.

So far, process inheritance does not seem to have reached commercial products, although this would seem to be a very useful feature to have. For instance, a typical business process could be defined and customer specific extensions could then be made to the inherited process in the same way that specific features are added to inherited classes in the OO paradigm. Some readers may recognise this. It is how most ERP systems are implemented today, only the “inheritance” mechanism is implemented by programming user exits and/or adding new customer build activities. The disadvantage here is that these changes are specific and propriety to the ERP system being implemented. If we want to implement processes over a heterogeneous environment (i.e. a lot of different applications or over the web) then inheriting from a process running in an external process engine would be an obvious solution. And with the rise of web services, composite apps a.k.a mashups, it wouldn’t surprise me if we start to see inheritance mechanisms creeping into the feature sets of process engine vendors.

Speeding up SOAP requests in a SOA

2006-05-27T08:42:00.000+02:00

In a previous post I mentioned how efforts are under way to inprove the speed of XML processing. Another approach is taken in this article I came across in which the author shows how SOAP requests in a SOA can be cached in a middle tier.

My very own homepage

2006-05-25T10:15:00.001+02:00

I finally got around to creating my own home page. It is extremely simplistic, but still does not reach the minimalist heights demonstrated by this web site.

I was keen to write the HTML by hand, so I have been using SelfHTML which is an excellent web based and downloadable guide to HTML. An English version doesn’t exist as yet, but they’re looking for volunteers to do the translation.

Update: Reread this old blog post and clicked on the minimalist web page link (actually from Creative Artists Agency). Previously this was was just the equivalent of a business card - company name and contact details. It's now been updated with a more dynamic javascript enabled interface. Only it doesn't do much more than before.

I guess their message is very simple - You have to talk to us.

What is the difference between OO and BPM?

2006-03-12T18:15:00.001+01:00

The answer is … none!

I know that this is a heretical viewpoint, BPM (and in particular the use of a process engine or BPMS) being regarded as the next great step. I’m not disputing that, I just saying that at a fundamental level OO and BPM are just the same.

To justify my viewpoint lets take at look at what was regarded as OO when people were first thinking about it (Xerox PARC and all that). Objects were considered as things which had the following properties:

Each object could receive messages and change their internal state accordingly.
Each object could send messages to collaborating objects
Many instances of an object could exist at the same time, each having their own state.Objects could inherit parts of their behavior from other objects.

It was a lovely idea, but over the years it just got more and more watered down due to limitations in how technology could support it, market forces and misunderstanding. Look at message transfer between objects. This became nothing more than a (synchronous) procedure call. Look at the idea of state. If more than one user is involved then our objects have to be “stateless” if we want to achieve anything like a decent response time. Inheritance became something to treat very carefully if we want to avoid building brittle, difficult to change, programs. Over time, objects degenerated more and more into simple data objects and the functionality happened someplace else, in modules which had names such as “session beans”.

What about BPM? The BPM paradigm talks about processes, and each process has the following properties:

A process can receive messages and change their internal state accordingly. For example, a user can fill in a credit application and sent this (as a message) to the credit acceptance process. The process changes its state to reflect that the credit application has been received.
A process can send messages to collaborating processes. Continuing with the following example, the process now sends a message to another process, which checks the credit worthiness of the applicant.
Many process instances can exists at the same time, each having their own state, e.g. different credit applications.

Replace process with object and you get the point.

But, I hear you say, an important part of the OO paradigm is inheritance. Where is that in the BPM paradigm? Currently, the idea of process inheritance does seem to be getting much attention, but does that mean it that it is an idea without value?

That is something that I’d like to explore in a later entry.

AJAX goes mainstream

2006-01-24T12:40:00.000+01:00

It seems that AJAX is finally making it to mainstream (in the sense that traditional IT is starting to see its potential). Integration product vendors are starting to provide tools - see, for instance, the TIBCO General Interface - and even Microsoft are getting into the act with the Atlas project.

Design Pattern Books

2006-01-19T14:54:00.000+01:00

After a long hiatus due to project and personal commitments, I thought I should start posting here again.

I was asked today, do I know any good books on patterns. So, for future reference, here is my list, stating off with the classic:

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Patterns of Enterprise Application Architecture
by Martin Fowler

Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions
by Gregor Hohpe, Bobby Woolf

Pattern-Oriented Software Architecture, Volume 1: A System of Patterns
by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Peter Sommerlad, Michael Stal

Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects
by Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann

Analysis Patterns : Reusable Object Models (Addison-Wesley Object Technology: Addison-Wesley Object Technology Series)
by Martin Fowler

The lost BPM links

2005-10-18T21:11:00.000+02:00

Towards the end of last year I came across an entry for business process management in Wikipedia. It wasn’t very good so, in the true spirit of Wikipedia, I rewrote it and tried to get some structure in it. Since then it has evolved with many people each making different contributions, although the original structure seems to have remained. Although I do have a few gripes with the current version of the entry, I guess I have to bow to the fact that my POV is not necessarily the POV of everybody else.

One section I added was a set of links to vendors currently offering BPM products. This has recently be removed by another Wikipedian with the comment that “it’s not a web directory”. Well, maybe. I have to admit that the section was troublesome in that everybody wanted to add their favorite vendor, even if their products had nothing to do with BPM. But I still found the section useful. However, rather than lamenting its demise, I have moved it here so what follows is the last link list from Wikipedia (edited to remove a number of spurious entries):

Action Technologies

Adeptia

ADONIS

Apache Agila (Open Source)

Appian Corporation

Cordys

COSA BPM

Chordiant

Documentum

Workflow.Cubes

FileNet

FlowCentric

Fuego

Fujitsu
HandySoft

IDS Scheer AG

Intalio

JBoss jBPM(Open Source)

jCOM1

K2.net Enterprise Workflow

Lombardi

Metastorm

Microsoft

Newgen Software

Open Text

OpenWFE (Open Source)

Oracle

Pegasystems

Pikos' Bonapart

SAP NetWeaver

Savvion

Sun / SeeBeyond

Skelta Workflow Software

TIBCO

Ultimus

Virtuoso Universal Server

Vitria

webMethods

My criteria for selection are rather loose, basically that each vendor states on their web site that they support business process management rather than just supporting particular processes (such as CRM , SCM etc.). The list is, of course, incomplete.

Rich Clients in a Browser - More about AJAX

2005-10-03T21:05:00.000+02:00

I’ve been pretty busy over the last months (new project in another city) so this is my first post for a number of months.

However, since posting about AJAX and rich clients back in March a lot seems to be happening in trying to ease the burden of providing rich client functionally in a browser, i.e. people are creating JavaScript libraries. The following caught my eye:

script.aculo.us has a JavaScript library for creating user interfaces elements and functionality, such as drag and drop and auto-completing text fields.

Rico who as well as offering a number of visual effects also has a data grid which allows a HTML table to be connected to a data source.

Both of these are based on the Prototype framework which is a JavaScript framework which claims “to ease the development of dynamic web applications” and has functionality to ease the handling of XMLHttpRequest (one of the fundamental building blocks of AJAX).

Virtual Enterprise and the SOA - What Reardon are doing

2005-06-08T14:34:00.000+02:00

Another InfoWorld article about Rearden Commerce's plans. What's interesting is not only that they offer a set of business services, but also a platform which lets the end user assemble composite apps (including their own processes).

Versioning Sevices - The last word?

2005-04-30T15:03:00.000+02:00

My article (written with my colleague Andreas Elting) on service versioning has been published in ObjektSpektrum, one of Germany’s leading technical magazines (the means of course that it’s in German!). As I have tried to show in this blog the idea of just using web services does NOT mean that the services and their consumers are fully decoupled from each other. Changes in the XML are unavoidable if the architecture has to adapt to changing business requirements, but these very changes can render a message unreadable for either the service provider of consumer. Service versioning is one way of managing this problem.

Previous ruminations on this topic can be found here.

Ajax - Rich Clients in a Browser

2005-03-19T18:08:00.000+01:00

A lot of buzz is starting to develop around the Ajax architectural technique. Indeed, before giving up, I counted 200 links in del.icio.us with Ajax as tag. This really is a buzz when you consider that the technique was only coined in February this year by Jesse James Garrett in an excellent article. As this describes Ajax so well, I’ll just try to condense it into two sentences: Ajax is about using the inherent rich client functionality of a standard browser to provide responsive user interfaces using standard web technologies. These are:

Rendering with XHTML and CSS

Client logic with Javascript and the document object model.

Communication using asynchronous calls to get XML data with XMLHttpRequest.

Although the technique has just been given a name it seems quite a lot of UIs have already been produced which use this technique. Having a name though, allows people to say “yes, we’ve done that” or “yes we’re doing that”, in a manner similar to the naming of design patterns. Indeed I’m sure that some of my colleagues who have produced rich UIs for various companies using JavaScript will say just that.

Although the hype is just starting, I need to sound a note of caution. If the amount of JavaScript increases above a certain point, then the perceived performance of the UI can degrade significantly. This is mainly due to the load time of the page. Certain commercial products (who will remain nameless) that rely heavily on large quantities of JavaScript are hitting this problem. It’s nothing new, anybody who once tried to bring rich client functionality to the browser using Java Applets (remember those?) knows what I am talking about.

More Services for the Virtual Enterprise

2005-03-08T15:49:00.000+01:00

Two more hosted apps for the virtual enterprise:

Rearden Commerce - Employee Business Services. What Rearden are really doing is explained in this Infoworld article.

JRG - Supply Chain Planning.

And an interesting article in CIO Online.

Building a Virtual Enterprise IV

2005-02-28T13:00:00.000+01:00

The following InformationWeek article describes how GrandCentral (mentioned before in this blog) have added a raft of new partners, each offering different business services. I've included the following quote from the article and linked the references:

"In addition to NetSuite and NSite [note: NSite offer business automation services], Grand Central's partners include ServiceObjects, a customer-data-validation service; Demandware's E-commerce system; RecruitForce.com, an online system for managing job applicants and the application process; SPS Commerce, an EDI hosting service; StrikeIron, which provides tools to simplify publishing, finding, and utilizing Web services; and Xignite, a supplier of online financial services components.
Additional partners are: Moreover Technologies, a supplier of online news service systems; Advanous, a division of EnterBridge Technologies, supplier of an online distribution-management system; ExpediteBiz, an automated shipping-service supplier; OpenAir, an automated professional-services-management system; Intellibank, an online relationship-management system; and Advanced Data Exchange, an online EDI document-exchange service."

Versioning Service II

2005-02-19T13:41:00.000+01:00

In a previous blog, I started to explore the idea of how services could be versioned in a SOA. Although versioning the WSDL seemed to be an alternative for web services using SOAP the question remained on how to version services which use a queuing mechanism (e.g. with a JMS interface). If a service is invoked over a queue then the queue becomes synonymous with the service. All that has to happen is that new versions of a service are connected to new queues (appropriately named) . Old clients just stay connected to the old queues or are migrated to use the new services over the new queues. Seems easy, but I suspect that in a large system with many services it would be a nightmare to administer, especially as there is no lookup information for the queue. Indeed, this seems to depart from two of the main tenets of SOA, i.e. services are loosely coupled and that they can be discovered.

However, having previously discussed that versioning is possible in web services, can web services be combined with a queuing system and the advantages of web service versioning kept? New standards in the web services space seem to point to a possible solution (as web service management vendors - such as Systinet - are keen to point out). The basic architecture seems to look like this:

SOAP Messages are sent to a MOM gateway, which extracts the messages, finds the queue and sends the message (maybe using JMS if it’s a J2EE implemetation) to a service provider. Messages sent back from the service provider are picked up by the gateway and send as a SOAP response back to the consumer. All the issues concerned with message correlation etc. are handled by the MOM gateway.

Not shown in this diagram is how to deal with an asynchronous style of communication. To solve this comes a small, and apparently unassuming, specification called WS-Addressing. This provides a uniform way of supplying the endpoint of a web service within the SOAP message rather than just using a URL. Although it seems to add complexity, the standard ends up providing extra flexibility and may well be the answer to dealing with versioning of services, but more about that later. In the case of asynchronous messaging, WS-Addressing defines a "ReplyTo" SOAP header block and this could be the endpoint for the return message from the provider.

I have, for the time being, ignored the handling of publish/subscribe mechanisms. Within an SOA one would typically also architect an eventing mechanism, e.g. to notify that a change has happened to some data. WS-Eventing is maybe the right standard to use, but I not going into that now.

Having seen how to use web services with MOMs, lets get back to the versioning problem. In order to find the correct version of a web service an additional degree of layering is required. I’ve tried to show this in the following diagram:

Now the usual parole is to say that the namespaces of the XML messages are versioned and that the version resolution layer checks the name space and directs the message to appropriate service. However, WS-Addressing offers another possibility. Instead of specifying the endpoint of the service provider the corresponding endpoint of the version resolution system is specified plus versioning information. Based on this, the version resolution finds the correct endpoint, modifies the endpoint in the WS-Addressing part of the SOAP header and directs the message to this.

Nobody seems to be actually offering anything in this area, although application platform vendors such as BEA seem to be active in terms of XML versioning, but if they are going to use WS-Addressing in their products to implement versioning , remains open. Web services management vendors such as AmberPoint , also seem to offer support for service versioning with their products, although how far this goes and if it is based on open standards is unclear.

Extending XML Schemas

2005-02-18T15:35:00.000+01:00

Interesting article about how to write XML Schemas which can be extended. Extending the schema doesn't remove the need for versioning, but it goes some way in preserving loose coupling.

For the Web Service Challenged

2005-02-17T11:46:00.000+01:00

Having problems keeping a track on all those web service standards.? Maybe these 3 help:

IBM keep a list of web service standards as well as their current status. Unfortunately these only seem to be those which IBM was involved in (including organisations such as OASIS and w3C).
Microsoft also keep a list, but in a more verbose fashion and, like IBM, it seems to be focused on Microsoft efforts.
Wikipedia also has a list of web service standards, but currently does not show the status.

Business Process Handbook

2005-02-10T13:40:00.000+01:00

The MIT Process Handbook is a catalog of processes, arranged in a hierarchical structure. Rather than just letting you examine the processes it also lets you generate ideas (based on related processes), which could be used to improve them.

A book is also available that explains the concepts behind it: Organizing Business Knowledge: The MIT Process Handbook
by Thomas W. Malone, Kevin Crowston and George A. Herman - ISBN:0262134292

Building an Enterprise using Hosted Services III

2005-02-08T10:42:00.000+01:00

In previous blogs I have talked about building a virtual IT, i. e. having all apps and data hosted by someone else. In my travels I've found three more providers. Salesnet and Rightnow offer CRM. Netsuite also offers financials and ERP support.

Building an Enterprise using Hosted Services II

2005-01-27T17:27:00.000+01:00

A couple of blogs back I wrote about the idea of how far a company can go in terms of virtualising it's IT, i.e. having somebody else hosting it, but wondered how all the external services could work together. It seems the idea has not escaped others. I first came across this blog on the Loosely Coupled web site. Although the author was trying to make another point (i.e. what is the ratio between objects, components and services in an enterprise) he trys to envisage a company which has no IT but uses services from, for example, salesforce.com and brings everything together using Grand Central and maybe the Amazon Simple Queue Service.

Searching further I found this infoworld article which also extols on Grand Central's capabilities and focuses on their use of a hosted BPEL engine which lets developers define their own processes and have them hosted.

Now that we have some of the business services/processes hosted and something like GrandCentral/Amazon to integrate them, what remains? Well first of all we need a lot more business services. GrandCentral's web site seems to offer a lot of the "informational" web services as hosted by organizations such as XMethods. Difficult to see how a meaningful chunk of business functionality could be implemented with those. (Maybe I doing an injustice to GrandCentral as I'm not a member of them and couldn't log in, plus the fact that their web site reminds me of a maze.) Secondly we need user interfaces - can they be hosted? Thirdly we need lots of data storage, which is properly managed and can also be used to host data warehouses. And fourthly we need alternate sourcing for this stuff.

Fast XML

2005-01-27T17:17:00.000+01:00

Many, many years ago I picked up a book about a standard used in the telecommunication industry for describing and encoding data. The standard was called Abstract Syntax Notation 1 or ASN.1. Using this, data structures could be described and encoded in a standard way for transmission. This should sound familiar - if not you only have to click here.

This was so long ago that I can't remember who wrote it and also seem to have lost my only copy.

Then in the January 2004 issue of IEEEPro, I was surprised to read an article by Darren Mundy and David Chadwick ("An XML Alternative for Performance and Security: ASN.1") in which they showed that using ASN.1 binary encoding is significantly faster than using XML encoding. Using this the data can be described using ASN.1 (analog to XML Schema) and encoded using a standard ASN.1 binary encoding . (Unfortunately only the abstract is publicly available.)

This seemed a Good Idea, especially in enterprise environments were performance is important. However, the idea has not escaped others, as I found out when I came across this news article about speeding up XML. This references the Fast Infoset project which (you've guessed it!) uses the ASN.1 standards and encodings.

Building an Enterprise using Hosted Services I

2005-01-10T14:07:00.000+01:00

Hopefully I'll get back to the service versioning problem later. But in the mean time I keep hitting against the idea of running a enterprise just by using hosted services. This seems very attractive - no software to install and manage, cut down on the amout of hardware you need etc.. So I thought it would be interesting to find out what types of business processes can be supported in this way. First one I found was Talaris who deal with procurement. Next was Salesforce.com - they deal with, obviously enough, sales processes (incuding CRM). One in Germany, Acinum who deals with various SCM procesess (careful, when I tried, the english version was not working).

I'm sure there are more and when I find them I'll blog them. Maybe you can run all your companies business processes just by using hosted services from different suppliers. But how will they all work together?

Versioning Services

2005-01-06T15:19:00.000+01:00

I becoming interested in how services can be versioned in a serviced orientated architecture. Doing a google shows quite a lot of activity in the area, only every one seems to think that the problem is restricted to web services, but a more about that later.

One article - Best practices for Web services versioning - from a couple of IBMers proposes versioning the XML namespaces of the messages schema (as defined in the WSDL) and then either issuing errors for requesters using the old schema of using some kind of routing mechanism which picks up on the namespace and directs to the correct version. The authors do, however, go on to say that products to do this type of routing for you are rare on the ground (they mention TalkingBlocks, but this seems to have been taken over by HP and, at a first glance, I couldn't find any explicit mention of how such routing is achieved). They then go on to show how the versioned service definitions can be stored in a UDDI compliant directory.

One consensus which seems to have formed is that you're on your own when it comes to service versioning.

As I mentioned before, the terms services and SOA seem to be synonymous with web services. But what about SOAs which use MOM or use REST styles of communication or mix them all together. Is there a general mechanism or architecture which can bring these all under the umbrella of one versioning scheme?

Java Development

2005-01-05T18:19:00.000+01:00

Developers seem to be getting tired of the complexity associated with the J2EE architecture and as such are developing and using lightweight frameworks which use POJOs. A combination which seems to becoming popular is Struts for the (web) user interface, Spring for the code container and Hibernate for object/relational mapping.

The Beginning

2004-08-24T20:26:00.000+02:00

Decided to start a blog under my own name.This is partly a continuation from my previous blog.

Stay tuned.