Hi folks, in this fourth post of the new Mule Agent blog post series I will introduce the Mule Agent architecture and the main advantages it provides.If you missed the previous posts in this series, check them out below:

During its development, we discussed the best ways to make the agent extensible and configurable, allowing users to customize it depending on their main use cases, adapting it to their current development cycle and practices. So please enter and take a look at the architecture we defined and implemented for those purposes.

Albin Kjellin on Thursday, March 12, 2015

SOAP & REST Attachments in Mule


I was recently working on a project where we had to handle SOAP attachments. Working with SOAP attachments is the kind of thing that you work on every 3-5 years and then 10 seconds after you are done you forget all about them. All the information required is available in our docs but it can still be good to have a complete end to end example as a reference. Esteban Robles Luna’s (former MuleSoft colleague) blogpost, Working with SOAP attachments using Mule’s CXF module, from 2011 was most helpful.

This is the second of a series of blog posts around the new Mule agent. For an overview of the new Mule agent, be sure to read Introducing the new Mule agent. In this post, I’ll talk about the new agent in relation to the Mule Enterprise Management Console (also known as MMC).

Readers of this post are probably familiar with MMC, which is MuleSoft’s current on-premises management/monitoring solution. The agent is a first step in the development of MuleSoft’s next generation management and monitoring solution. Think of this solution as more than just MMC 2.0. Over the next few Anypoint Platform releases, this agent will unify management and monitoring of Mule ESB, CloudHub, and API Gateway to provide MuleSoft customers with unparalleled visibility and control over their connectivity landscape. And because we’re taking an API-led connectivity approach to developing the agent, it will be highly extensible.

Steven Camina on Tuesday, February 17, 2015

Introducing the new Mule agent


icon-muleears-blue-bigTogether with the release of Mule 3.6, we’ve also shipped a new Mule agent that exposes new APIs to manage and monitor running Mule, enhancing the experience of creating API-led connectivity in a big way.

The new Mule agent exposes APIs that allow enterprises to easily tie in to their existing SDLC processes and applications. The agent also has a flexible framework that’s quickly customizable to meet new operational governance requirements around Mule.

This is the first of a series of blog posts where you can learn about this new agent.

What is the new agent?

The agent provides two very powerful pieces of functionality. Specifically:

  1. the Mule agent exposes Mule runtime APIs via REST and/or Websockets
  2. the Mule agent enables Mule instances to publish data to external systems

Let’s talk about these two pieces of functionality more, as these impact the way users interact with Mule ESB from an operations, manageability, and monitoring perspective.

Sometimes you’re expecting a JSON, specially when publishing or consuming a REST API. But you need to make sure it’s a good JSON, not the kind of JSON that would kill you with a machete. Since the Javascript Object Notation format (JSON for short) can be used to described pretty much anything, validating that the one you received actually complies with what you expected is no simple task. Or at least it wasn’t until the JSON schema specification came out. Just like XSD schemas are XML documents used to describe how a valid XML looks like, a JSON schema is a JSON document used to make sure that yours doesn’t come with a machete. You gotta love the recursion of it!

Mariano Gonzalez on Wednesday, January 21, 2015

Give your old school API some love


If you’re an assiduous reader of this blog, then you probably already heard about our vision around APIs, our Anypoint API Manager solution and all our RAML based stories. Those are our recommended way of approaching REST APIs and if you haven’t already, we all highly recommend you to take a look at them. However, we’re about connecting everything, everywhere. Thus we recognize that there are a lot of APIs out there built in plain old Java code and a migration process is not something you can do overnight. If you own such an API, this post is about us wanting to help you too. Anypoint Platform includes a Jersey module to allow embedding Jersey-based APIs into the runtime, reusing the Java code powering your API but still gaining access to all the other features of the platform. In Mule 3.6 we upgraded our supported Jersey version from 1.6 to v2.11 to give you access to the latest and greatest that Jersey has to offer.

Mike Stowe on Thursday, January 15, 2015

API Best Practices: Hypermedia (Part 3)


Part four of the API design best practices series. Read part one: Plan Your API.

Or jump to part one of the hypermedia sub-series.

A Road Trip

First off, let me apologize for the delay in this third part of the hypermedia sub-series. Christmas meant a warm trip back to Minnesota, a road trip through the Texas panhandle, and numerous snow storms in between — until finally I had the chance to cut through the mountainous desert of Southern California on my way back to beautiful San Francisco.

Now I understand some of you are probably wondering what any of that has to do with this post, other than it’s about 3 weeks after promised. One of the greatest challenges of the drive was battling my way through the snow and construction, and just hoping that the interstate would stay open (they literally close the interstates if it’s bad enough). But the one thing I could be sure of was that at every turn, between my steady GPS and road signs, I knew where I was going, and I knew when my path was being detoured or I couldn’t take a certain road… I knew this, because everything was nice and uniform.

Norberto Herz on Friday, January 9, 2015

Let’s honor the future


This post is about fulfilling some expectations created by sci-fi movies, using Arduino and Nobel to expose RESTFul APIs for controlling physical devices.

The early-arriving future disappointment

This is the year that, according to some Hollywood prophets, cars will be finally flying, clothes will adjust their sizes to our bodies, trash will be combustible, and houses will be intelligent – though I never understood why they thought that an intelligent house would have a fax hanging on the wall. Come on? FAXES!

Mike Stowe on Thursday, December 18, 2014

API Best Practices: Hypermedia (Part 2)


Part four of the API design best practices series. Read part one: Plan Your API.

Or jump to part one of the hypermedia sub-series.

The Harsh Reality of the State of Hypermedia Specs

Hypermedia sounds great in theory, but theory only goes so far. Where hypermedia really shines, or completely fails, is in implementation. Unfortunately, as hypermedia is still a relatively new aspect of web based APIs, there isn’t one specified way of doing things. In fact, you’ll find that even some of the most popular APIs operate completely differently from each other.

Mike Stowe on Thursday, December 11, 2014

API Best Practices: Hypermedia (Part 1)


Part four of the API design best practices series. Read part one: Plan Your API.

What is Hypermedia

One of the challenges to implementing and correctly using hypermedia in your REST API is first understanding what hypermedia is, and what it means to use hypermedia as the engine of application state (HATEOAS).