About

Introduction

In Dream, a web-service is similar to an object in that it gets instantiated and has entry points.  The latter are called service features or features for short.  A feature is an interaction point for another service.  Since all Dream services are RESTful, features interact through standard HTTP verbs such as GET, POST, DELETE, etc.  The design of the Dream runtime allows a service author to assume an idealized world where everything that the service comes into contact with is accessed through web-requests.  At this level, only two forms of data exchange are allowed: XML and binary streams.  The Dream library provides classes with simple interfaces to enable these interactions.  The benefit of the idealized world assumption is that it reduces the number of cases that a developer needs to be aware of.  Note that an idealized world doesn't mean that everything is abstracted away.  Quite the contrary.  Instead, everything fits one view and this view makes the following assumptions:

1. Other services may become unavailable at any time
2. Resources must be managed through timeouts (i.e. time-to-live/TTL)
3. Everything runs concurrently

Here is where the Dream service library comes into play.

Service Library

The Dream service library contains services that address common problems when writing any kind of interesting web-services or web-applications.  Its core services include:

• Storage service: the storage service is a simple file-system abstraction useful for persisting state or caching results.  Lifetime of the stored files is coupled to the lifetime of the associated service unless a file states a different TTL.
• Events service: the events service manages publishing, queuing, and subscribing to messages.  Published messages can have a TTL from 1ms to infinite.
• Directory service: the directory service associates XML documents with names.  It's similar to the Storage service, but has a few fundamental differences:
  • First, directory services can be chained to create a virtual directory.  When an entry is not found in a directory, the request is automatically forwarded to chained directory.
  • Second, any service can subscribe to change notifications in a directory, thus easily tracking updates.  This capability is actually the foundation for state replication.
• Redirect service: this service is a necessity for mash-ups as it enables bypassing the cross-domain scripting limitations.  A redirect service does something similar to a delegate in C#, enabling services to compose themselves of other remote services.

Runtime

The Dream runtime is responsible for orchestrating all interactions.  It is built using the HttpListener class and thus requires no web-server to be pre-installed on the target device.  It is responsible for instantiating services, routing messages to them, and short-circuiting service-to-service communication when both are co-located (meaning they are loaded inside the same AppDomain).  Furthermore, the runtime shields the developer from the nitty-gritty details of the outside world.  The service author can simply assume all messages to be XML documents.  The runtime takes care of converting these into other formats, such as JSON, before sending them back to the requestor.   Similarly, the runtime takes care of forwarding exceptions when they occur and go unhandled.  Eventually, the runtime will take care of swapping services in and out as appropriate.  This is possible, because all services are required to serialize to and from XML.  This is also how services can be upgraded without shutting them down.

Finally, the Dream runtime is the front-end for debugging Dream applications.  Since it is already based on HTTP verbs and XML documents, it is easy to inspect and navigate all active services to determine their state.  In the future, the web-browser will become the premier debugging tool for tracking down service interactions.

Web 2.0 APIs

The goal for Dream is to make it easier to created compelling new Web 2.0 services and APIs.  Many of common cases are taken care of by the runtime implicitly, processing is done concurrently, and interactions with XML and other services is simplified by the Dream library.

We hope that Dream will become the foundation for many exciting new applications and services.  If you like to participate, please read the How to contribute page.