Technical future proofing assumes constant change in both operational environments and technology. The impacts of change are mitigated by emphasizing versatility and adaptability in system architecture. This tenet applies equally to both hardware and software systems. By ensuring that system components are modular, and that they interact using standard interface patterns and in a loosely coupled manner, components can be modified or readily swapped for more capable variants across the entire system lifecycle. As a result, the system as a whole remains functional and useful well past the time when the original configuration has become obsolete. This article illustrates risks associated with inadequate future proofing and provides an overview of tools and techniques that promote long lasting, future proofed software systems.
Read the full blog post at Adam's blog
As Progress Software divests its non-core businesses, including the Sonic ESB and FuseSource, forward thinking Progress customers are looking at alternative vendors, who can provide a stable, supported, and innovative middleware platform. For many developers, the Sonic ESB along with other Progress SOA products was a first introduction to service development, mediation, and management. However, Progress™ lack of product portfolio governance has created a disjointed portfolio and increased developer effort to create a comprehensive SOA platform.
For IT teams seeking a more robust alternative to Progress Software and looking to avoid the risk of an unknown platform future, WSO2 provides a viable path forward. WSO2 is the only application infrastructure vendor who has delivered a complete middleware platform through organic development effort, not through problematic, disjointed acquisition. Smart, innovative IT teams from eBay, AAA, Alfa Bank, and Concur place their most important business transactions on WSO2s high performant ESB; a bus handling over 1 billion transactions per day and $2,000 each second for eBay.
A couple of years ago, at WSO2 we implemented a new HTTP transport for WSO2 ESB. Requirements for this new transport can be summarized as follows:
Read the full blog post by Hiranya.
Representational State Transfer (REST) is an architectural style widely used to communicate over the web. In this model, each resource is uniquely identified by an URI and there are four operations - GET, POST, PUT and DELETE - defined for each resource. The HTTP protocol which is widely used in web communications nicely fit into this architectural model. Therefore we can easily implement Restful APIs and access them using the existing web infrastructure.
In order to provide the interoperability between the business entities, most organizations tend to expose their APIs as Restful services. However in most organizations the back end services may use different types of protocols as well as message formats. These system can be web services implemented with SOAP, some legacy systems like CORBA or some SAP system end points. A middleware layer, which can be used to implement Restful APIs integrating those back end systems, allow users to expose their APIs as Restful services easily.
This article describes some of the best practices that can be implemented when using WSO2 ESB in production for smooth 24x7 operation. The content is more suitable for advanced users who have experience with the WSO2 ESB. New comers are encourage to read the quick start guide of WSO2 ESB .
ESB performance is a hot (and disputed topic). In this post I don't want to talk about different vendors or different benchmarks. I'm simply trying to help people understand some of the general aspects of benchmarking ESBs and what to look out for in the results.
Representational State Transfer (REST) provides a lightweight approach for building distributed systems. Instead of relying on overcomplicated protocol stacks and heavyweight middleware, REST facilitates communication between systems by leveraging simple message formats and open protocols that power the Web.
The famous article titled “How to GET a Cup of Coffee” by Jim Webber describes a comprehensive model for connecting applications and automating workflows using REST. It clearly demonstrates the power of REST and is probably one of the best references available on the subject. Taking a Starbucks coffee house as an example the article illustrates how a RESTful architecture can be used to implement an order management system while automating several business processes that involve customers and Starbucks employees. It even discusses several non-functional requirements such as performance and security and shows how such features can be incorporated into a RESTful design.
Taking Jim Webber's work as a foundation this article describes how a complete RESTful solution can be implemented using WSO2 middleware. We will attempt to implement the order management system described in Webber's article and see how the Starbucks workflows can be automated using the REST support available in WSO2 platform.