Cloud Platforms and Open APIs: The new application stack

November 29 2011

3 comments
motif

Application stacks are so passé, now its all about the slice. With the rise of open APIs we are seeing a new breed of application. Infrastructure APIs are cropping up everywhere for doing things like email, FTP, monitoring and management, analytics and application security.  These slices of functionality, delivered as services, remove the time consuming need to set up services locally and allow developers to spend their time building their application.

Mule iON Architecture Series: The Technology

September 14 2011

2 comments
motif

Building a highly available and fault tolerant cloud platform comes with its share of challenges. What happens when components fail? What happens when the cloud itself experiences downtime?  How is it possible to ensure customer apps are always available and their log data is never lost?

These are some of the very questions we ask ourselves when working through the iON architecture.  With so many choices, both open-source and commercial,

ESB and Hub n’ Spoke Architectures – ESB or not to ESB revisited Part 2

In my last post, ESB or not to ESB revisited – Part 1, I put some definition around what an ESB really is, today I’m going to describe two integration architectures, ESB and Hub and Spoke, providing the benefits and considerations for each.

Previous Posts:

What is an ESB? – ESB or not to ESB Revisited Part 1

I wrote a post a while back, To ESB or not to ESB, about when to use an ESB and when not to.  It got a fair bit of pick up, and I’ve had a lot of people reach out to me about it with specific use cases.  It got me thinking it’s time to revisit the topic and provide more practical information about your options for integration.

This is a multi-part post where I’m going to start by defining what an ESB really is,

SOAP and REST are not interchangeable

motif

Recently I saw this question posted in a forum: “Does REST have better performance than SOAP”?

This question is symptomatic of a fundamental misunderstanding of REST, I think. SOAP is a particular protocol used to implement RPC functionality. REST, on the other hand, is not a technology or protocol, but an architectural style. Systems that were built with the REST architectural style are fundamentally different from RPC based systems. For REST, we think in resources and data.

REST constraints: A benefit-focused discussion, part 1

motif

REST – the REpresentational State Transfer as defined in Roy Fielding’s thesis –  is not a protocol, a standard, an API, a technology or a product. You cannot buy it, you can’t download and install it and you don’t need to poke another hole in your firewall for it. Instead, REST lives at a level completely decoupled form any specific technology, protocol or product, because REST is merely an architectural style: A set of constraints and principles,

Beyond Integration, Part 3: Towards Eventing

motif

In the previous installment of the Beyond Integration series, we talked about some strategies for evolving legacy monolithic systems into finer grained services orchestrated by Mule ESB. As mentioned in this earlier post, following such a path opens the door for implementing new business operations by using the newly created services in novel and previously impossible ways.