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,
The first thing that comes to mind on Mule Cache scope is how to implement this cache mechanism with a webservice. Mule has a wonderful mechanism of caching with its cache scope, available in Anypoint Studio with Mule ESB Enterprise, and there are examples available on internet on how to extend the Mule caching mechanism with EHCache. Check out Mule caching with EHCache if you are still looking for an example.
I’m going to provide an overview on how to build a simple contract-first web-service and JAX-WS client that consumes the web-service with Mule Studio.
The sample below is going to build the following:
Build SOAP/ HTTP web service using Mule & CXF that is CRUD web service to create, retrieve, update and delete an order and returns the order id. This exercise implements only the create operation for this service.
Last month we released Mule 3.3 M1, our first milestone on the way to Mule 3.3. While for production you should use Mule 3.2.1, we hope these milestones are a great way to play around with the latest and greatest features. This is a great opportunity to provide feedback and have an impact on what we are doing for the Mule 3.3 release.
Mule allows us to expose services to the web through CXF, but what happens when these services handle sensitive information that we don’t want just anybody to read or change? We need to be able to authenticate who is consuming the Web service and determine if the user should have access to the service or not.
In this post we are going to show you, step by step, how you can use the Username token profile to validate the user identity using a Spring Security authentication provider running in Mule.
You might have noticed that under certain circumstances Mule will add its own Soap Headers to the CXF calls. This can be a problem in some situations. For example, let’s say I’m communicating with a remote web service that is not expecting these extra headers. This will probably result in a validation failure and leave me unable to communicate with the web service. Fortunately there is a way to avoid the unwanted headers, which is what we’ll be discussing now.
Mule has had support for WS-Security via CXF for some time now, but Mule 2.2.4 Enterprise goes a bit further still with the inclusion of the Mule SAML Module and a new WS-Security example. In this article, I will step through the WS-Security example so that you can see the different possibilities available for incorporating WS-Security into your Mule application.
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.