Sometimes (more often than we think), less concurrency is actually more. Not too long ago, I found myself in a conversation in which we were discussing non-blocking architectures, tuning, and performance. We were discussing that tuning for those models often starts with “2 threads per core” (2TPC). The discussion made me curious about how Mule’s batch module would perform if tested by 2TPC. I knew beforehand that 2TPC wouldn’t be so impressive on batch, mainly because it doesn’t use a non-blocking threading model. However, I found myself thinking that the 16 thread default threading profile might be a little excessive (again, because sometimes less is more) and wanted to see what would happen if we tried it. You know, just out of curiosity.
CONNECT 2015 Technical Sessions
With over 30 sessions, customer case studies, hands on labs, product demonstrations, complimentary certification, and a packed solution expo of MuleSoft certified partners, CONNECT provides an great opportunity for current users of Anypoint Platform to uplevel their skills. And if you’re deciding if MuleSoft’s solutions are a good fit for you and your organization, we’ve designed a 3 day experience that will equip you with the resources to make the right decision.
Here are seven CONNECT 2015 sessions created by developers, for developers:
“Any sufficiently advanced technology is indistinguishable from magic.”
- Arthur C. Clarke
Take a quick look around you. Maybe you’re on your way to work, or perhaps you’re waiting in line at the coffee shop. Now take a quick look at the people around you–don’t stare--but try and eyeball the number of people you see. Got it?
Here’s the thing: three out of four of the people around you have a smartphone1. Which means that by the time you finish reading this paragraph, they might have been able to do any one of the following things:
Ever wanted to get certified on our Anypoint Platform, but discovered that you didn’t have the training?
We’d like to introduce MuleSoft.U: self-study, public, FREE certification courses that will enable developers to learn core MuleSoft skills. At a significant cost per seat for a public class, instructor-led training is unattainable for most independent developers. With MuleSoft.U, independent developers can get up and running in no time. In our first course, Mulesoft.U Developer Essentials, students will learn:
- How to use Anypoint Studio to build integration applications to connect to SaaS and on-premise applications and data.
- How to use the Anypoint Platform for APIs to define APIs with RAML and then implementing them as web services using Anypoint Studio and APIkit.
- Deploying and running applications on CloudHub and/or Mule ESB Enterprise.
This is a great resource for independent developers, and any partner and customer developers who prefer the multi-week schedule are welcome to enroll as well. The first course begins on May 20, so register today!
Financial Institutions (FIs) find that deploying PaaS and IaaS solutions within a private cloud environment are an attractive alternative to technology silos created by disparate server hardware, operating systems, applications and application programming interfaces (APIs). Private cloud deployments enable firms to take a software-defined approach to scaling and provisioning hardware and computing resources.
FIs face a number of challenges as they build out their private cloud and PaaS environments:
- Financial services firms are deploying private clouds and PaaS to improve IT manageability and to empower developers, but still need to manage and monitor legacy environments and third party applications
Learn how @ CONNECT 2015
The pressure to deliver solutions in support of initiatives such as mobility and cloud services often trumps keeping mission-critical services stable and reliable. Without a way to simultaneously respond to the demands of the business and IT, industry leaders of today will quickly become the logos of the past.
API-led connectivity has become IT’s secret weapon in tackling this challenge. And for CONNECT 2015, we’ve created an opportunity for CIOs and IT leaders to deeply engage with peers and MuleSoft experts and leave inspired, with an understanding of best practices and a list of practical actions that can be taken today.
Handling endpoints with disparate speed when the platform is in the cloud
A fairly common integration requirement is to accumulate data coming in real-time or near real-time, hold and consolidate the records, then send the transformed messages to another system on a fixed schedule (e.g. daily etc.) for business reasons, especially if the endpoints are legacy systems. For on-premises integration platforms, this use case is rather straightforward to implement. For cloud-based integration platforms though, which are generally geared toward real-time processing and lack access to local file storage, this requirement does seem to pose some technical challenges. Fortunately for CloudHub, with the built-in persistent queue feature and the Mule Requester Module, the implementation is as easy as doing it with legacy on-premises platforms.
When it comes to getting data in and out of Salesforce using Anypoint Platform, there are a number of different options. Typically, using just one of them won’t give you everything you need and you might have to combine a number of them to to achieve a complete solution. In this post, we’ll summarize 4 options – Realtime, Custom, Bulk, and Data Virtualization – when to use which, and things to keep in mind for each.
Part 1: The Challenge
Let’s imagine you’ve been working as an architect in a large company for several years and are very proud of the now mature Supplier Relationship Management (SRM) application you specified, formed, and delivered to the business, as it continues to provide value.
Functionally, the SRM is a web application that allows for managing relationships of suppliers and materials, maintaining hierarchical structures, uncovering unwanted dependencies and helping your clients significantly reduce supplier costs. Your department was chosen for this quarter’s highly visible and mission-critical innovation project: a new mobile application.
Howdy! This is the last post of the Mule 3.7 series Be sure to check out the other posts in the series:
- A sneak peek into Mule 3.7’s deepest internals »
- One to Contain them All: Unifying the Mule Registry in 3.7 ».
IMPORTANT: If you haven’t read the previous posts in this series, do so now. This will be very difficult to follow otherwise. This post carries the same warning as the first one: it’s mainly intended for developers coding their own custom Mule components. If you’re the kind of person who codes their own components or finds it tasteful to leverage the low level Mule APIs and internals, then you should definitively read this series of posts. On the other hand, if you’re the kind of user which just simply uses Mule out-of-the-box and the Anypoint Studio palette gives you all you need, then you probably won’t be as excited about this long read, but it’s recommended anyway; it’s always good to know your tools.