Security around public cloud offerings has always been a major point of concern (and controversy) for users. How do cloud providers protect customer data? How is log data protected? How is the surrounding infrastructure secured? We previous talked about how iON stays up and running even through EC2 outages. Today, we will talk about iON security to show how we protect customer information and the infrastructure used in building iON.
Category: Tech Ramblings
Last month the AMQP working group, which includes big hitters such as Bank of America, Credit Suisse, JPMorgan Chase, Barclays, Goldman Sachs, Microsoft, Cisco, VMWare, Redhat, and Informatica finalised version 1.0 of the AMQP standard. It has been 5 years in the making, the market for messaging has changed a lot in that time.
What is AMQP?
“The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.” - Wikipedia
We provide a lot of webinars with tips and tricks from our development team on how to get the most out of Mule. But what about in the real world? We’re pleased to present a great customer use case of Mule in the wild.
In 2010, Employers Direct, a major workers’ compensation insurance provider, became Pacific Compensation. As part of this shift, the company fundamentally changed its entire model from direct sales to utilizing insurance brokers. This required a major systems overhaul and posed substantial integration challenges.
I wrote an article recently on InfoQ about how REST replaced SOAP on the web. The comments rolled in and I found myself if a debate that I have had many times before – “why do I need an integration platform?” There are a number of answers to this, but stripping features away the key principle that answers this question is Loose Coupling. Let me explain.
High availability. Fault-tolerance. Redundancy. Region failover. These are all major features that users look for when determining which cloud platform to use. They are not, however, easy problems to solve when building a cloud platform. Previously, we discussed the technology surrounding Mule iON’s architecture. Now, we will take a deeper dive into these components and how we carefully built Mule iON to resist outages or failures on Amazon EC2.
I think most agree that this years JavaOne had turned a corner. The dark cloud over the future of Java under Oracle’s stewardship had lifted and there was a lot more interesting things happening with the platform. The hot topic was Java 7, and its EE counterpart. Walking away from the conference I had some final thoughts:
JavaOne seems to have new flare now that the dust has settled from the Sun acquisition, and is set to be the best event in a long time. This year we’d love you to come by our booth and meet some of the team. There will be some cool Mule swag (yes, the squeezy Mules are back), demos of Mule Studio and a chance to see Mule iON in action and win some stuff.
If you reached this blog and you are not a Mule user (yet) keep reading, I will not cover anything Mule specific. If you are new to OAuth or want to get an introduction to its concepts this post is the right one!
Authentication is vital in any kind of system but it is even more relevant when it comes to the web. As the web grows, more and more sites rely on distributed services and cloud computing. As resources are spread all over the web, sharing them across multiple sites is not an unrealistic requirement considering the following scenarios: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services. In order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else it also provides these applications unlimited access to do as they wish.
Most people who write UIs don’t care about testing. You know why? Because it’s hard. So hard, they’d rather not even bother and test things manually. You have multiple browsers. You have multiple platforms. And worse, you have all these frameworks and toolkits which are difficult to test. I’ll pick on GWT here for a moment. It takes 20 seconds to start a test – let alone a server side component to interact with or the time it takes to run your test. 
In over 10 years of developer experience, I worked for different companies, in different roles, but I always found the same problem over and over again: bug reporting sucks. I spent some time thinking about how to avoid some usual problems in this area and I realize that we could apply the same technique we apply to improve the code: reviews.