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,
Given the ever broadening capabilities and functionality of Anypoint Platform, even the most experienced MuleSoft developers will be challenged to remember all the features and tricks the product suite provides. Especially on fast-paced implementations, one can easily be caught up with the ebbs and flows of the daily project tasks and ironically, forget to leverage that one tool that can really help with productivity – documentation. In services,
No, that was not a typo…
Implementation services team members are truly the workhorses and warhorses of enterprise software companies. From the business analysts to the field engineers, their efforts contribute critically to whether or not customers can successfully go live into production. Therefore, it is important the “horses” are well trained for a company to be successful. As for Mule,
With the launch of APIhub.com, acquisition of ProgrammableWeb and launch of the RAML spec we co-developed with Box, LinkedIn, Intuit and others – we are investing heavily in the API space to help developers take part in the API economy. APIs are unlocking massive business value and customers are turning to us more and more to help make their API vision a reality.
We’ve just rolled out a new platform service in our CloudHub R20 release for storing application data. With Mule’s Object Store capabilities, each CloudHub integration application is given it’s own storage, with zero configuration required. This makes it a extremely easy to implement two very important integration scenarios:
- Persisting OAuth tokens – all our OAuth enabled connectors can store tokens and restore them using ObjectStores
- Storing synchronization state –
Working with web APIs, local APIs and different data formats and structures is too damn hard. You have to write painful verbose code to:
- Query Web APIs and work with the data
- Enrich and join data from external services with local services
- Compose RESTful services from existing services
- Version services and data formats
- Merge data from different sources into a common data format
- Sort through sets of data
For those of you that wish the view this webinar again, or for those of you that missed it, the archive of this webinar is now available online here.
Also the sample code shown in the Webinar is now available here. Any questions can be sent to our User List
Defining what constitutes a service when building service-orientated applications seems to be a common problem for developers and architects who are new to building services. The main issue seems to be the scope, i.e. what is the granularity of the service. This is actually quite difficult since the granularity of a service can vary depending on the application. The trick with any fuzzy problem is to break it into smaller pieces. There is a very simple service taxonomy defined in Thomas Erls SOA in Principals of Service Design book which I believe makes the approach to defining services much easier.