We started by identifying the user types involved in creating the service consumer applications we want to focus on with Zero… application assemblers who string together solutions combining information feeds, RESTFul services and activities that require human interaction; component developers who program the building blocks used by those assemblers, making information sources accessible as feeds, offering REST-style access to business services, etc.; and Web interface developers who build that part of the application that deals with interacting with people…

To further refine the analysis, we applied a persona-based approach (for more on personas see, e.g., here )… introducing Rick the component developer, who wants to build reusable components… he is fluent in several programming languages, likes to dig into challenging API specifications and can easily whip up a few hundred lines of code over a weekend… he’s one of a few people amongst his co-workers who actually can do this and they admiringly refer to him as “the gnome” who works in the background to enable them to do their jobs…

And Frank the application assembler, who wants to quickly put together an application that is a good-enough solution to a business problem… he does not much like to write code and prefers an Assemble style programming model where wires existing components together… but he can create some Groovy code or customize Web interface scripts if necessary… he depends on Rick as a source of solution building blocks, but does not interact with him on a daily / per-project basis… people interacting with Frank appreciate his ability to quickly compose a solution to their problems and sometimes refer to him as “the wizard”… which Rick finds rather unfair since it is his work that makes Frank so productive…

The mind works in mysterious ways and this picture of gnomes & wizards collaborating on Zero applications stuck in mine… but that’s not really what I wanted to talk about here… what I waned to talk about is the resulting analysis of real world scenarios where those personas play… two clusters emerged…

One is in the area of line-of-business users building situational applications to solve an immediate business need based on a set of application building blocks they find in their enterprise… here, Frank(1) might be an analyst who wants to quickly aggregate information from a number of sources into reports his department needs… the resulting applications are not made to last… and effort of putting them together must be minimal… here, Rick(1) might be someone in the enterprise’s IT shop responsible for making existing information and services accessible for consumption by business users like Frank…

The other set of scenarios is about Systems Integrators who might, for example, be building solutions for mid-market customers… here, Frank(2) might work for a Regional SI specializing in customization of popular business applications offered by an ISV for mid-market customers, integrating services offered by that system with existing information sources and services already in use and to provide Web-based access to the resulting application to end users of this client… while those SIs would probably not consider what they build to be situational applications (their solutions are actually made to last and have minimal maintenance cost), they have many of the same requirements as the other service consumers … here, Rick(2) could be one of a few experts the SI employs to create assets that can be used in many solution scenarios … or he could be working for the ISV tasked to make they CRM and other capabilities offered digestible by service consumers like Frank(2)…

More on this in another post…

QEDWiki allows mashup assemblers to create a personalized, mashup by assembling a collection of widgets on a page, wiring them together to define the behaviour of the mashup application, and then possibly sharing the mashup with others. Mashup enablers provide QEDWiki with a collection of widgets that provide application domain- or information-specific functionality.

Conceptually there’s a lot of similarity between the QED way of assembling a mashup by wiring widgets found on a palette and the Assemble model for composing a flow from a palette of activities mixing in mediation aspects as required… similar concepts, similar target users… but different focus – QED is geared towards mashing up on the client, Zero Assemble is about building server-side mashups… and there’s a lot of potential for using them in combination – while many mashup applications do most of the assembly of information and RESTful services “on the glass”, users observe that for non-trivial mashups it can be beneficial to delegate aspects of the overall mashup logic to the server side of the application…

The example we implemented with QED and Zero Assemble illustrates the concept: it’s a Mashup that brings together information about stores a company owns, centred around a map showing store locations from which more detailed information can be requested by clicking on a store – things like how much an individual store sold in a week or the aggregate of what all of the stores sold in a month… the way we designed the end-to-end application was to have the client Mashup focus on presenting information feeds and enabling users to explore them in creative ways… while leaving the creation of the feeds to Assemble flows on the server side, e.g., normalizing store input from various countries (think: currency conversion) or aggregating feeds from several stores…

I refer to the design pattern used here as the “perfect feed”: rather than bothering the client side mashup with massaging feeds to get them into shape for consumption by mashup clients, they delegate that to a server side Mashup… a combination of Assemble flows and mediation aspects takes care of accessing the information, transcoding it into the format expected by the client and augmenting it with other information as required – producing one widget that serves up the perfect feed to QED client side mashups…

This pattern mixes two of the mashup styles identified in the still very relevant post by Dion Hinchliffe where he identified 5 mashup styles – presentation mashup, client-side data mashup, client-side software mashup, server-side software mashup and server-side data mashup… the perfect feed pattern combines presentation with server-side data mashup…

There are other design patterns for segmenting the overall mashup into a client and a server side… the basic idea is to push complex or relatively stable aspects of the overall mashup to the server and focus the client side on aspects likely to change and in support of dynamic exploration of information by mashup clients… an example would be a “task flow” pattern mixing presentation mashup with server-side software mashups that realize tasks kicked off on the client by scripting interaction of a set of RESTful services… or, in the “page flow” pattern one would break the mashup script guiding a user through interactions to perform a task (e.g., filling out an order form) into a coarse grained flow that drives the overall process (think milestones like selecting goods, filling in personal details) augmented by client side mashup snippets that allow users to improvise (i.e., freely switch between pages) to perform the individual tasks…

Ideally one would allow users to assemble their mashup without having to make choices which part to run on the client or the server and rather make that a deployment choice… we’ll further explore potential synergies between client-side mashup makers like QED and Zero both from an artifact sharing and from a mashup builder perspective…

So, we need building blocks… lots of them, obviously… but they also have to be “Assemble consumable”… we want to enable users to assemble an interesting application in 10 minutes… check out the Assemble flow demo movies to see this done in real time… and while generic RESTful APIs with many options are great for mash-up builders who write programs using those options and don’t mind studying the docs, this won’t work for service consumers building apps Assemble-style…

Building blocks must be intuitive with a few basic configuration options for tweaking their behavior… we use a design pattern for Zero apps that implement those building blocks: they declare [input]s they expect to receive and configuration [attribute]s used to configure their behavior and are accesed via the Zero global context… example: a [findBook] component based on the Amazon Ecommerce Services could offer configuration [attribute]s identifying the requester plus book category & search key (e.g., author, title) – and map this onto the more generic ECS query API…

We offer a basic set of building blocks with Assemble today, but we need a lot more… we’re working on a set of feed processing components… we’ll offer a set of mediation templates supporting popular interaction patterns… and we’ll present publicly available RESTful services (think: Yahoo, Amazon, UPS, FedEx, etc.) on the Assemble palette (simplifying their rich configuration options to an Assemble-consumable set of PoVs)…

But at the end of the day there’s only so much we can do here… and in a way Assemble is a bet on the Power of Communities…

Communities that create the vocabulary of the Assemble flow domain-specific language (DSL) – Assemble-consumable building blocks… I think we will see communities establishing their specific vocabulary matching the domain they are interested in… communities of different shapes and sizes… from broad ones like the Web 2.0 crowd that might use a vocabulary reflecting their REST / feed style programming model… to industry-specific communities that might introduce vocabularies inspired by industry standards such as OAGIS BODs … to intra-enterprise communities that make their existing intra-enterprise assets consumable as Assemble building blocks…

And if we are as successful as I hope in inspiring communities to build their Assemble vocabulary, we will have to help in organizing the large set of building blocks… but that’s a nice problem to have… tagging, classification, semantic annotations will be part of that… more on that in another post…

This is to support scenarios where Zero developers wish to use a service or resource that is not quite what they want it to be… they might want to POST a request to an endpoint that speaks SMTP rather than HTTP; information they want to GET from a Customer resource has to be transformed before they can use it; they wish to log all interactions with their Account resource; or they want to choose from a set of Stock feeds when issuing a GET for stock info…

The basic idea here is to allow service consumers to register resources they wish to interact with and configure those interactions by choosing from an extensible library of services that implement interaction aspects.

We support various access styles to resources (HTTP obviously, but also SMTP, Java methods, or Files) and offers an extensible library of mediation aspects that can be inserted into the interaction between a service consumer (e.g., using the Assemble Call API ) and registered endpoints… for example a [Log] capability, variations on [Route] (ranging from basic URL rewrite to table-based routing), variations on [Transform] (for different request encoding styles, e.g., XSLT for XML payloads), etc. We provide a basic set of mediation aspects with the Assemble core, but we encourage Zero users to add their own.

Users declare fabric managed interactions in a Zero config file that serves as the “registry” for resources the Assemble integration fabric knows about (integration_fabric.xml); they can pick an access style and define a pipeline of interaction aspect steps to be applied when processing requests against the resource (e.g., [Log] followed by [Transform]).

The Assemble tool provides a graphical editor that supports definition of mediation aspects for a resource via drag& drop from a palette of mediation building blocks.

The basic idea is to allow users to quickly string together a set of existing building blocks (e.g., a few information feeds, RESTful services or web-based user interactions) into a Web-oriented application; to avoid any confusion – this is about server-side scripting… borrowing concepts used in construction of client-side mashups…

We chose a flow paradigm as the underpinnings of this model. Examples include: mashing a few news feeds by aggregating them into a new feed and then further manipulating that feed… or conversational applications that coordinate interactions between a set of users… or applications that access & manipulate a set of resources via RESTful services…

We offer a minimalist model for describing interactions between components that are to be mashed… one way to think about this is as a simple domain-specific language (DSL) for mashup flows describing the interactions between a set of application building blocks or activities – what information flows between them, how results of one component trigger another one; there’s a bit more than that (e.g., to utilize Zero global context variables and additional control flow concepts), but in a nutshell it’s that simple…

For example for a feed flow one could have activities like [GET] feeds, [Aggregate] those feeds, [Sort] the resulting aggregated feed; for a conversational flow one would use would use activities such as [receivePOST] to obtain input form a user or other requester, [replyPOST] to go back to that requester or [sendMail] to get others involved; and for a resource mashup one might use activities like [GET], [POST], [PUT], [DELETE] to retrieve state of a set of resources, manipulate it and then update state of these or other resources… we offer a starter set of activities as part of the Assemble core, but we encourage users to add their own language elements for activity types that are very relevant for their specific assembly scenarios and domain-specific tasks.

The beauty of having one mashup flow model for all of those assemble patterns is that one can mix them – I can create a mashup that starts by aggregating a few feeds, sprinkling in interactions with some RESTFul services and then drive a conversation between users processing the resulting information.

There are several ways to render this assembly model for consumption by Zero users… the one most Zero Assemblers will probably use is the graphical UI in the Zero Assemble tool where users compose flows by dragging activities from a palette onto a canvas, configure them and draw the flow between them…

Another rendering of the model is the XML dialect we’ve implemented in the initial version of the Assemble model… and we’re looking into other renderings, e.g., as a DSL in Groovy…