1
2
3
4
5
6
7
8
9
10
11

@Path("/stat")
public class StatusResource {
    @GET
    @Produces(MediaType.TEXT_PLAIN)
      public String getStatus() {
        if (checkStatus())
            return "Ok";
         else
            return "Not so good";
    }
}

Then we tried to connect a silverlight client to this server (don’t ask me why).  The first hurdle was a security one. Silverlight doesn’t like to communicate with a server it didn’t launch from. To resolve that you need to add a ClientAccessPolicy.xml to the root of your domainto allow cross-domain access. Here’s a simple all-permissive version of it:

1
2
3
4
5
6
7
8
9
10
11

@Path("clientaccesspolicy.xml")
public class ClientAccessPolicyResource {
    @GET
    @Produces(MediaType.APPLICATION_XML)
    public String getStatus() {
        return "<?xml version=\"1.0\" encoding=\"utf-8\"?><access-policy><cross-domain-access><policy> <allow-from http-request-headers=\"*\"><domain uri=\"*\"/></allow-from> <grant-to> <resource path=\"/\" include-subpaths=\"true\"/>"+
     " </grant-to></policy><policy ><allow-from http-methods=\"*\"><domain uri=\"*\"/></allow-from><grant-to>"+
      "<resource path=\"/\" include-subpaths=\"true\"/> </grant-to></policy></cross-domain-access></access-policy>";
    }
 
}

By the way – since silverlight is entirely a client technology you can also serve it from the Java web server (as long as you emit the right mime-type ) in which case you don’t need the cross-domain policy mentioned above.

Another interesting phenomena we saw was that the client only got the response once. no matter how many times we polled the server. We ran fiddler and saw that no request are in fact going out to the server – it was the browser’s (IE8) cache that was holding us back. It took me some head scratching as to how to solve this – but the solution is pretty simple – return an ‘expires” http header from the server to make sure the browser will only cache the result for a limited time. To do that with jersey you need to return a Response object instead of the text (or JSON/HTML etc.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Path("stat")
public class StatusResource {
 
    @GET @Produces(MediaType.TEXT_PLAIN)
    public Response getStatus() {
 
        Response.ResponseBuilder response = Response.ok(checkStatus);
 
    Date expirationDate = new Date(System.currentTimeMillis() + maxCacheInterval);
    response.expires(expirationDate);
     return response.build();
    }
 
}

While I think Silverlight is a technology on its way out. It is still around. It is nice to know that with a couple of simple moves you can get it to play nice even with a Java backend

Illustration by arinas74

When we try to think about service consumers, the obvious candidates are, of course, other services. Nevertheless there are other software components that interact with services e.g. legacy systems,  Non-SOA external systems or reporting databases. The Composite Frontend pattern deals with yet another type of service consumer – the User interface.

First let just verify that User interfaces aren’t in fact services. One reason user interfaces are not services is that they converge several business areas e.g. if you want to enter an order you’d probably also want to lookup information about the customer, maybe you’d also want to browse the product catalog, look at open invoices etc. In addition to convergence, user interfaces deliver data rather than process it. User interfaces are data producers (actually there’s one exception to that – where the UI is the front of a “human service” see orchestrated choreography pattern (in chapter 7) for more details.

Ok, so UIs aren’t services, does it matter? Well, it does and the problem is not that UIs aren’t services per se. The main challenge caused by user interfaces comes from their main difference i.e. the aggregation or convergence of several services into a cohesive and useful UI.

6.1.1      The Problem

To better understand the challenges caused by user interface working with multiple services, let’s consider an example with just a single point of friction.

In a project I worked on we’ve designed the C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) system for an Unmanned Naval Patrol Vehicle (UNPV). One of the services in the system was dubbed “Common Operational Picture” or COP for short. The COP ‘s responsibility was to handle anything that is detected by sensors e.g. ships, planes, whatever (There’s technical jargon for all that like targets, detections, tracks etc. but that’s not important here). One of the main UI representations of the COP was a map ,such as the one in figure 6.4 below, which showed all the detections. Clicking on map icon, say a ship, presents some information the COP knows about it, such as id, nationality, course  etc.

 Figure 6.4 A simplified  illustration of a  front end for a “Common Operational Picture” service of a naval command and control system. We see a shore line and then using NATO symbology: 2 radars, a submarine and an a ship (the Unmanned Naval Patrol Vehicle)

The system had a few other services in addition to the COP, amongst them there was the “UNPV service”. The UNPV service was responsible for anything related to the UNPV itself for instance, setting it on a navigation course, turning it around, etc. The UNPV service had several UI screens to allow managing and monitoring these functions. Another responsibility of the UNPV service was to send its location to the COP (locations are the COP’s responsibility, remember?) so back in the UI, one of the icons of the map is that of the UNPV.

What happens when a user clicks on the UNPV icon on the map?  Remember, while the desired outcome is to display a popup with options related to controlling the UNPV, the click is on the map, a control serviced by another service (the COP). In an Object Oriented system the UNPV might be a sub-class of a detection so that it would accept the same event and respond a little differently (in a more specialized way). Here, however the COP and the UNPV are completely different services, developed by two different group and maybe even two different companies.

We may be able to dismiss this specific example and just solve it with a specific solution e.g add an ‘if’ statement somewhere to call up the correct commands and to interact with the correct service(s). The problem, however, is that this example is just the tip of the iceberg. For instance: how do we handle security? – do we need to login for each service separately? How do we handle things that all the services need? SOA’s premise is that we’d get a sort of lego-like enterprise where we can compose different business processes easily. Is there any way  we can get that in the  user interface? In summary:

How do you we interact with multiple services, get an integrated, cohesive user interface and still preserve SOA principles and modularity benefits?

 

One option is, as mentioned above, write specific client code. Using this approach “an application”, is any specific composition of services. For the example above, the application would include the two service (COP and UNPV) and a UI that ties them together. The up-side of this approach is that each application delivers a consistent experience for the user. After all, a specific or tailored application can be made to be very cohesive. Additionally there are many tried and tested ways to build flexible UIs with a proper separation of concerns, e.g. using Model-View-Controller and its variations (in a multitude of rich client and web technologies) so we’d probably be able to reuse some of the UI-side logic even going  from application to application. Nevertheless, we do lose on flexibility. For one, any service change that has UI aspects needs to be redone for each of its UI instances (applications). More so, since the UI specifically ties multiple services changes in one service may cause another to mal-function within the unified UI. We also lose on Composability, or the ability to replace services and to create new business flows (relatively) easy. Overall it’s a bad option long-term but it can be made to work as a short term solution.

A related option is taking a similar approach of tying several services together but instead of integrating them on the client side we integrate the services together on the server side. This approach shares it pros and cons with the previous solution. However there are specific circumstances where it does make sense and you can read about them in the next pattern (section 6.5 Client/Server/Service)

Lastly, we have the option to have independent UI components per service. This would overcome the limitations we’ve mentioned above since each service’s corresponding UI can evolve independently and you can just cram a as many of these as you like to create an application. Unfortunately, with all its benefits this is a non even an option here as, by definition, we won’t have the mechanisms for UI components that work cross services. i.e. it won’t actually solve problems like the one in the example and we can’t get a cohesive UI.

6.1.2      The Solution

What we need, essentially, is a way to compose services together while keeping their respective autonomy on one hand and providing mechanisms to glue them together as a cohesive whole – That’s what the Composite Frontend pattern is about:

Apply the Composite Frontend pattern to aggregate services while providing them unified client-side services like layout and theming as well as coordination services for client-side service integration

Figure 6.5 The Composite Frontend pattern. Each Service has a Portlet which is a Service Agent combined with a UI logic (most likely Model in a MVC UI pattern). The UI host provides services for the different potlets to weave them together into a coherent UI.

The Composite Frontend pattern is about taking the ideas (and sometimes the technologies) behind web portal and applying them to SOA services. Web portals provide unified access point that aggregates multiple web pages. They also provide single sign-one and personalization. SOA interfaces need that and more.

The composite front-end pattern is composed of two main components: the portlet and the host. The portlets are the building blocks, “the composites” which are fused together to form the user interface. The portlets are made of at least two components. The user interface logic (views and controllers in MVC lingo). The second component, the service proxy (or agent) , is the more interesting one from an SOA perspective. The service proxy is a client-side representation of a service. The proxy serves as the model for the user interfaces components. It is usually recommended to have a single proxy per service -just like it is recommended for each service to maintain its own data store. Furthermore, from a product management perspective it can be seen as  part of the service itself

The host is the “value-add” part of the composite frontend pattern. The host provides the glue that ties the different portlets into a cohesive whole. As such, the host provides  several roles. Firstly it provides the canvas or surface on which the portlets are displayed. Additionally it controls the life-cycle of the portlets and lastly it provides capabilities (avoiding the loaded term services…)  like inter-portlet communications and single-sign-on.

Lets revisit the problem discussed in the previous section. We had a right-click on a ui component, which should have produced a context menu with options from two services. How would that would with the composite frontend pattern? One option is that a click would be first intercepted by the host which would then dispatch it to any registered portlet. Another option illustrated in figure 6.6 below , is for the click to  be intercepted by the first portlet the Common Operation Picture (or COP), have it notify the host and have the host ask all the iixnvolved portlets to render the right-click menu. The COP portlet should pass enough information as part of the event for the other porlets to be able to do something meaningful with.

Figure 6.6: Sample event flow in a Composite Frontend. Events are intercepted by the user interface components of individuals portlets , The events are transferred to the host which dispatches them to registered protlets for handling. The host can then render the results for display

The composite frontend pattern is a service consumer pattern so the proxy will utilize the various service interaction patterns like saga, request/reply etc. (see chapter 5) and it can benefit from the various service composition patterns like Service Registry and Servicbus (see chapter 7)

You’ve probably notices the use of the term portlets to describe the service agents and you might be wondering why the pattern is named Composite Frontend rather than Portal. The main reason for that is that the pattern can also be used with rich client implementations and not just web ones – let’s explore that further in the technology mapping section

6.1.3      Technology Mapping

Normally, you’d won’t be developing your own Composite Frontend container and instead use existing products that provide the framework and usually the tooling to help build the portlets.

The obvious example for that are web portal frameworks. Modern enterprise web portals usually support anything from JSR 168/286 (Java Portlet specification) to  WSRP (Web Services for Remote Portlet) to open web standards like RSS, plain REST services or standards like open social.  There are a lot of products in this area both commercial like  ibm WebSphere portal server and Microsoft Sharepoint and open source options like Jboss Gatein and Lifray.  Figure 6.7 below show he layout functionality of the UI host as it is implemented in Jboss Gatein

Figure 6.7: The layout capability of a Composite Frontend UI host as it is implemented in Jboss Gatein portal.

Web portals are not the only option for implementing composite frontends. You can also implement the concept for desktop (“rich client”) applications. An example for that is the prism framework made by Microsoft’s Pattern and Practices group. Prism implements the Composite Frontend pattern for both Silverlight and WPF applications. Prism provides all the functionality of a user interface host and lets you write portlets that consume these capabilities. Code snippet 6.4 below demonstrate using an EventAggregator facility that allows inter-portlet communications (such as the one needed for the sample scenario in the map component example above):

Code listing 6.4 Sample use of Prism’s EventAggregator to send events between different porlets unified by the prism shell

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[Export(typeof(SampleView))]
public partial class SampleView : UserControl
{
   [ImportingConstructor]
   public SampleView([Import] IEventAggregator eventAggregator
   {
       InitializeComponent();
       eventAggregator.GetEvent>().Subscribe(OnItemSelectedReceived); #1
   }
   public void ItemSelectedReceived(ItemSelectedEvent item)
   {
     //do something with item...
   }
}

#1 subscribing to an temSelectedEvent. Another portlet can call get on the EventAggregator to get a reference to the event and raise it without knowing if thare are any subscribers

Lastly, in addition to web portal frameworks and desktop framework you can roll your own implementation of Composite Frontend. however, as mentioned above it is usually better to  choose one of the available options as it quite an investment to get it right.

6.1.4      Quality Attributes

Before moving on to the next pattern lets examine some business drives (or scenarios) that can drive us to use the Composite Frontend pattern.

In essence, the main drives to Composite Frontend are flexibility to adding and changing services and the desire for an integrated user interface that feels as a whole Table 6.X provides examples for both quality attributes:

Table 6.3  composite frontend  pattern quality attributes scenarios. These are the architectural scenarios that can make us think about using composite frontend pattern.

Composite Frontend is probably the preferred way to provide an SOA user interface. However one problem we still have to solve with integrating UIs is UIs that are not SOA aware – for instance what happens when we have an existing UI that we want to expose to services? The next pattern will try to answer exactly that.

Vertica is  a columnar database optimized for analytics. In a nut shell, columnar databases allow fast aggregation of  data as well as holding a lot of columns per row – both traits are helpful when trying to report on data (but vey wasteful when you try to do OLTP operations). Autonomy adds to that path analysis and related algorithms to provide insight from stored data. Add that to HP’s hardware capabilities and you can get a high-performance data appliances that can handle large amounts of data efficiently.

HP is not alone in this trend. We see similar moves by EMC which acquired Greenplum followed by  unified GreenPlum/Hadoop  SW-HW solution, IBM acquiring Netezza and  rolling  its own Hadoop version, heck, even Teradata recently acquired Aster Data to bolster its analytics offering. It’s almost like we’re back in the 1950′s with companies creating dedicated appliances instead of general purpose computers.

While Teradata, an NCR spinoff, pioneered this trend, I think Oracle’s introduction of Exadata popularized this trend. Oracle which is probably the leader could (and still can) be sold with any hardware. All of a sudden, with the acquisition of Sun, Oracle started to keep the high-end customers to itself. This was especially a blow to HP considering the first incarnation of exadata ran on HP’s hardware. Anyway, as we saw above, the big vendors* are rushing to build their own “complete software and hardware suits” and HP, it seems, is doing the same. By talking about dropping its PC business HP is trying to pull an IBM (and its Lenovo move) and focus on Enterprise solutions in general and the hot analytics market in particular

Meanwhile I am reading that HP servers are having trouble handling the demand for their tablet dumping - I guess that’s also bad press to the cloud message of HP. I hope their analytics message and solutions will fare better

By the way, for now this is only interesting for larger corporations which are willing to spend the big bucks involved  (e.g. Vertica was priced at 100K$ per terabyte last time I checked). Smaller companies esp. SaaS provider, will probably still solve their big data problems with Hadoop, Cassandra and the like. However as data is more than doubling every two years and as the top-tier market will get saturated, I am sure we’ll start seing offerings with more reasonable price-tags over the next few years.

* You may have notices that Microsoft is missing from this list – MS is also making moves in this field with Parallel Data Warehouse and Dryad . Unlike the other’s they do not have hardware capabilities as well as some other challenges. Maybe I’ll dedicate a post to them in the future.

RabbitMQ is a message bus built in Erlang. It implements the AMQP protocol, which, unlike JMS, is also a wire protocol and not just an API. (meaning you can use an AMQP client with any compliant AMQP server) AMQP has a few concepts which are different from “regular” messaging infrastructures (like MSMQ or MQSeries). The illustration below shows the main concepts of AMQP

Virtual Host – Virtual host is administrative container which  provides access control boundaries. Each virtual host has its own set of exchanges. A connection can only be associated with a single virtual host

Exchange – An exchange is a message routing agent. Exchanges can be temporary, auto-deleted or durable. Messages are published to exchanges and then routed to queues that are bound to the exchange (if no queues are bound the message will be lost).Exchanges support one of the following routing schemes

• Direct – based on a routing key. Any queue (or exchange) binding to the key will get the message
• Fan-out – no routing key , each queue or exchange bound to this type of exchange will get a copy of the message
• Header -  Header based routing allows compound routing based on a combination of lists of identifiers (essentially key-value pairs) the routing can be done on either any or all key-values specified. The subscription then specified a set of key-values and an operator (and or any) e.g. { ‘x-match’ => ‘any’, :customer => ’23′, :agent => ’007′ }. This looked like a promising direction until we’ve found that it isn’t well supported (e.g. it isn’t even documented in the C# documentation of RabbitMQ) and doesn’t perform well
• Topic – Topic based routing allows compound routing based on topic hierarchy. Topics is based on pattern matching (a strong core capability of Erlang, RabbitMQ’s implementation language) and allows versatile subscription based on wildcards: * a single segment placeholder or # zero or more segments  (e.g. foo.*.bar will match foo.baz.bar, foo.bag.bar but not foo.baz.bag.bar, foo.#.bar will match all of them)

Both queues and exchanges can bind to an exchange. The default exchange uses the queue name as routing key (i.e. sends a message directly to a queue)

Queue – A queue is a FIFO buffer. It is important to note that the FIFO order is only guaranteed when a single consumer is used. Queues, like exchanges cab be temporary, auto-deleted or durable. Getting messages from exchanges to queues is done by binding the queue to an exchange.

So that’s a short into to AMQP itself. In the next installments I’ll expand a little about RabbitMQ itself, show some coding samples and finish it up with some pros/cons

illustration by beautyredefined

First off it is a major event since Amazon controls almost 60% of the Infrastructure as a Service market (per WSJ) and an incident like this is bad publicity for the whole cloud concept. After all if Amazon is fledgling what does that mean for Rackspace and the other IaaS players – not to mention PaaS players like Google and Microsoft (since PaaS solutions require more complicated software and higher integration with end-solutions.

It is also worth mentioning that this isn’t the major outages for Amazon. One notable “availability event”  occurred in 2008 where S3 had major problem for about half a day and a few minor problem with EC2 in 2009. What’s stands out here is that the availability zones features that was supposed to isolate this type of breakdown to smaller areas broke and only sites that had data-center redundancy (like Netflix for example) managed to handle the interruption while sites like foursquare, reddit and even, it seems,  a company monitoring cardiac arrests

were all harmed.

Another alarming behavior on the part of Amazon is the lack of transparency / bad crisis management in handling the outage. For example Keith Smith CEO of BigDoor (one of the startups affected by the outage) writes

“Starting at 1:41 a.m. PST, Amazon’s updates read as if they were written by their attorneys and accountants who were hedging against their stated SLA rather than being written by a tech guy trying to help another tech guy.”

When a big supplier fumbles a lot of companies are affected and it is bound to get big press. Also, systems, esp. complex ones, have bugs and its understandable that things may break from time to time (and I am sure that Amazon, which evidently has top talent would find a way to prevent this from recurring). However, Cloud providers need to understand that “with great power comes great responsibility” and the technical offering need to be strengthened with great support and transparency.

On the technical level, it also means that, while moving to the cloud carries a lot of benefits and can save a lot on operations costs, the responsibility for our application’s up time is still our responsibility and depending on the  cost of failure (on the scale from few dollars to lives of people)  we should also architect for disaster regardless of vendor claims. When we build closed systems we may  look at the Mean-Time Between Failure (MTBF and MTBCF) advertised by hardware manufacturers but we’d also add software based reliability mechanisms – for the cloud that may mean cross data-center (region) deployments, cross cloud provider deployments, or even on-premise backup – This is the same measures you’d take when your dealing with the electric company, if it is important enough, you’d install UPSs and generators and alternate sites and whatnot, you just have to figure out how important business continuousness is

I guess we’ll all wait to see how all this unfolds and what will be the after-effects of this outage on Cloud-computing. I personally think that it is still a good move in many cases, however this incident, help focus that the responsibility for our application’s wellness  is still ultimately  ours

Edit Apr. 24th:

I just read a post in Coding Horror which refers to a year old post in Netflix’s blog called “5 lessons we’ve learned using AWS [Amazon WebSevices]“. Netflix, in case you’re wondering survived Amazon’s outage and indeed, in lesson #3 they explain that if you want to survive failures you have to plan and constantly test for it:

Lastly note that in real world scenarios you probably use a mix of simplification, parallel and yes even leaps – We need to have several tools in our tool-set. We can’t afford to just have a hammer since after all, not every problem is a nail – right?

* Architecture definition as it appears in the first post of the series :

“Software architecture is the collection of decisions affecting the system’s quality attributes; which have global effects and are hardest to change. Software architecture provides the frame within which the design (code) is built.”

** The context based routing was added as part of a previous architectural change. I mention this here as it is an example for a simplification – an architectural element that was not part of the original architecture but was added later when the actual need arrived (when we had to support both internal operations as well as 3rd party integration)“Software architecture is the collection of decisions affecting the system’s quality attributes; which have global effects and are hardest to change. Software architecture provides the frame within which the design (code) is built.”

*** illustration source newson6

1) VMRole is not IaaS. This is not my opinion. It is Microsoft’s (my employer) stated position.

Sorry however, whether an offering is IaaS or PaaS or anything is determined by its capabilities not by the label some marketing person put on it. The VM role is more IaaS than PaaS. It is true that it isn’t a realy IaaS since it has a limited support of VMs (e.g. you can’t run Linux on it)

2) Yes, it is a good idea to allocate one service per role. How else are you going to scale?

First off, scale is not the only reason for moving to the Cloud, probably not even the major reason to do so. Reduced IT costs, right-sizing hardware needs, flexibility are some of the other reasons to move. From a pricing perspective this can prove to be a poor choice. Let’s do the math. The particular client mentioned in the post has 4 web sites (variations on the product) and some 20 services. If you have an IO bound application (which they do) than you should probably use  a medium instance (smaller instance have moderate or low IO performance). You’d want to run 2 instances per role (to get the 99.5 uptime guarantee ). Yearly cost =0.24$ * 24 hours * 365 days * 24 roles *2 > 100K$ where we can probably pack everything into 2 extra large instances at 16K$ per year. Yep great idea indeed

3) Services (Web or REST) can be implemented on either Web or Worker roles.

It seems that by services you mean “web-services” but that’s not the only way to implement services. In any event I didn’t say you can’t. However Worker role (or VM) is where you can implement stateful services if you need them

4) The cost of a proper architecture in Azure is a business discussion not a technical one.

See point 2 above. Generally speaking architects who ignore the cost of their architecture are bound to fail. It is never just a business discussion (same goes for other “business” concerns like time-to-market etc.)

5) Worker roles are NOT where you put all of your stateful services. Worker roles are used to implement non-web tier services. Which also need to be stateless in order to scale.

Again the scale thing (it reminds me this :)) So basically you are saying that unless you are stateless you cannot scale? is SQL Azure Federation a hoax then? Or is Microsoft the only company with the smarts to build stateful scalable solutions?! or what?

6) CloudValue is attempting to use the Windows Azure Platform as a host. Cloud platforms are not hosting platforms That is a different paradigm.

Let me get that right – Are you telling me to advise my clients to move off of Windows Azure? Is this an official Microsoft stand???  Seriously, I know it is not as we are working with MS reps in Israel and UK to help get them to the cloud  but come on…

Don’t get me wrong. Azure has some really nice features and it keeps improving all the time. I think worker roles (or something on top of it) need to provide a higher level of abstraction from the mapping to an instance so that you can really right-size your IT spending. Not every solution needs to scale to Google or Facebook size

Anyway, PaaS is the more interesting offering in and  in Windows Azure it is comprised of a lot of services like Azure SQL, ServiceBus, Web role (to host web sites) and our friend- the Worker Role. Microsoft defines the Worker role as follows:

A worker role is a role that is useful for generalized development, and may perform background processing for a web role. When you have a need for a background process that performs long running or intermittent tasks, you should use this role

That’s sounds like a good plan – but what happens when you have an SOA with a lot of services? You’d think that it would be a good idea to allocate a worker role for each service but that will translate to a large usage bill as each worker role runs on its own instance.

If all your services are stateless* than you can use the Web role to solve that. Starting with SDK 1.3 of Azure you can use full IIS installation (MS understood that their former crippled web host was a mistake, but that’s another story). Full IIS means you can host multiple services with out worrying about i. And since they’re stateless you can scale easily by adding instances and all is well. This is, by the way, MS’s official solution for the problem – which means that worker role is were we’d put our non-stateless, ie. stateful services – and that’s too costly if we go by the book (service per Role) and costly when we cram them all together since now we have to develop quite a lot of infrastructure

Here’s a real-life example : We (CloudValue) are  currently working with a client in the forex market that want to port their current portfolio to the cloud. The database was a relatively painless port to Azure SQL, the web-servers took a little more work (mostly related to moving to IIS 7.5) but can now be deployed to a web-role. The back-end however is build from quite a few services some of which are, lo and behold, stateful – exchange rates and related market data arrive at high rates and require low latencies (here is an extreme example) so now what?

The first thing we’re doing is move everything to a VM role – that’s the fastest way to get to “something” running in the cloud, and I guess that has some merits in the PR department. If we want to move these services to worker roles or better yet to a single worker role (with multiple instances) we need to develop the infrastructure ourselves – I’m (re)writing a RoleManager which is essentially a watchdog that monitors which services are running, allows the different services to be divided between instances and generally do a lot of stuff I am expecting a PaaS vendor to provide out-of the box.. oh well

I assume that the composite application which is going to be part of the AppFabric (CTPs planned sometime in 2011) will address this issue, meanwhile we have to solve this problem ourselves (like the RoleManager I mentioned above)

* Stateless is a nice way to say that you’ve passed this hot potato to someone else and that the state is now its problem… :)

Illustration by Laura Leavell

“Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.”

In plain english that means that if CloudPageBlob inherits from CloudBlob and CloudBlob.UpdateText(someText) works CloudPageBlob.UpdateText(someText) should also work and not throw and exception… (or alternatively CloudPageBlob shouldn’t inherit from CloudBlob)

Hear that Microsoft?