Standalone Mule runtime engine allows customers to deploy applications in their server, located in the cloud or data center. All application data remains within the customer network so it is a choice for security conscience customers who may have regulatory needs or security policies to comply with.
However, as the customer’s application network grows they may face various challenges with a standalone architecture:
In May 2020, we announced the general availability of Mule 4.3, Studio 7.5, and MUnit 2.5. This release concluded a long internal journey with several objectives: hardening and stability, performance parity between Mule 3 and Mule 4, and closing developer productivity gaps (API specification lifecycle in Studio) in Studio 7. As we made this release public, we achieved an important milestone in Mule 4’s evolution. Mule 4.3 is now better-equipped than ever before to welcome Mule 3 applications into Mule 4.
Picture this: you’re buying a new car. Should you upgrade your vehicle to get better features? Usually, you’re buying a vehicle to drive it — but, thanks to technology, there are dozens of other reasons to upgrade. Your current ride probably doesn’t have the latest safety and convenience features, and your warranty has likely expired. So, should you hang on to your old wheels? Think about cost, safety, and connectivity. If your mechanic is spending more time with your car than you do,
Is your organization undergoing a digital transformation? Is your IT department under pressure to move all the applications and infrastructure to the cloud? An increasing number of organizations today are looking to iPaaS solutions that provide integrated software and hardware stacks for quick deployments, management, and a higher ROI. SaaS products like Salesforce, Workday, and ServiceNow have the system of records in the cloud which is another reason companies are moving to the cloud.
Hi all, in this post I wanted to introduce you to how we are thinking about integration patterns at MuleSoft. Patterns are the most logical sequences of steps to solving a generic problem. Like a hiking trail, patterns are discovered and established based on use. Patterns always come in degrees of perfection with much room to optimize or adopt based on the needs to solve business needs. An integration application is comprised of a pattern and business use case.
A few days ago I decided to do the exercise of migrating an existing transport (JPA) to be compliant with Mule 3.1.1, and after a couple of hours reading and a few minutes of coding I finally got it working. I would like to share some tips that may help you to migrate your own transport.
There is no shortage of well-known reasons for wanting to migrate your Java EE web application to open source Tomcat. But without development experience with both your current Java EE application server as well as with Tomcat, it isn’t clear what you must change in your Java EE application to get it to run properly on Tomcat. The benefits of being able to run it on Tomcat are significant — for example, Tomcat is free to run in production,
In order to make sure that the migration path is straightforward and well-documented, I just finished migrating the SFTP MuleForge project from Mule ESB 2.2.1 to 3.0. It was extremely helpful to have a good set of unit tests in the SFTP transport code. That makes it easier to tell if your project still has all of the necessary functionality after the migration. If you are interested in migrating your own MuleForge project,
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.