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.
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,
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.
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,
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 – 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,
In the previous installment of the Beyond Integration series, we talked about some strategies for evolving legacymonolithic 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.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.