How do you take your existing investments in Enterprise and SaaS Applications, and turn them into collaboration tools that make businesses more effective? Organizations utilizing CMIS-based content management systems such as Alfresco frequently need to integrate and interact with these systems of record, and increasingly find pushing the content out via new channels to a socially savvy workforce speeds business processes. In this Webinar we will explore how to quickly do the following:
In over 10 years of developer experience, I worked for different companies, in different roles, but I always found the same problem over and over again: bug reporting sucks. I spent some time thinking about how to avoid some usual problems in this area and I realize that we could apply the same technique we apply to improve the code: reviews.
Its about time the Web became more event-driven. We have had AJAX for many years enabling events between server and browser, but on the backend we are still polling data. With the explosion of public APIs from SaaS, Social Media and Infrastructure Apps, more and more applications are written by composing web APIs. Developers often need to call a API to get data updates, only to find that nothing has changed. Streaming APIs provide a more elegant solution to polling allowing developers to subscribe to changes they are interested in.
This section of our blog is about showcasing current and upcoming cloud connectors. Cloud Connectors are Mule modules that allow easy connectivity to cloud APIs such as Twiiter, Facebook, and the thousands of Software as a Service platform out there on the net.
This week will talk about Mongo. Mongo is very popular database nowadays, and for several reasons. It is being use in production by several well known companies such a Disney, The New York Times, Foursquare, Chicago Tribune among several others.
On one of the previous blog posts by Ross, “To ESB or Not to ESB“, he did a great job in outlining the two basic integration architectures: “Enterprise Service Bus” and “Hub and Spoke”. Included in the Blog is a good overview of the benefits and considerations that are relevant for each architectural choice.
A key implementation consideration for SOA enabled architecture such as An ESB is the capability to maintain pace with the integration needs of the organization.
The reason this is important is that we live in very dynamic IT world where business needs and system can change with the next bright idea. If your organization responds too slowly, then you are putting your organization at risk by not being able to compete effectively in the market place.
To truly be competitive, your organization must adapt to the ever changing, and complex world of technology integration. The reality is that you no longer have months to design and additional months to deliver integration services to the organization.
In the real world there is a good chance that you have an existing Identity Management System already deployed. It is also quite likely it’s either a hub and spoke implementation or a system that has not been updated in quite some time.
So how do you maintain and extend an existing identity management system? What are the basic choices you have for managing your current environment and, extending it into an SOA enabled architecture?
If you have come to this “fork” in the road then there are two obvious choices available.
- Rip and Replace the existing solution
- Continue to add on to your proprietary hub and spoke solution
Both of these choices will work but they are not ideal for any number of reasons (Expense, Time to Delivery, Continuing investment in Legacy environment). So what are the alternatives and how can I use SOA concepts to maintain services and support the organizations growth:
“How can I maintain and extend my current environment in an SOA enabled environment”?
There is a readily available answer for this question and in this blog we will present a real life demonstration of how this can be accomplished.
In the next part of the blog we are going to walk through a real life example of using a SOA enabled (hybrid approach) to provisioning and de-provisioning cloud SAAS accounts.
Testing exception handling code is not always an easy task. You either need to setup the external conditions that cause the exception to be raised or generate mocks to get the same results.
A third option is using a bytecode injection tool like Byteman. Using Byteman scripting language you can insert custom behavior into the application code under test. The main use cases for Byteman are:
This is my final post in a series of ESB or not to ESB articles where I have attempted to shed some light on what an ESB really is and show some alternative architectures for performing integration. I’ve given an overview of four main architectures that I see most often and provided some context about the benefits and the considerations of each. You can read the original post and follow-up parts 1, 2, and 3. Here is a quick recap.
- ESB or not to ESB – original post
- ESB or not to ESB revisited – Part 1. What is an ESB?
- ESB or not to ESB revisited – Part 2. ESB and Hub n’ Spoke Architectures
- ESB or not to ESB Revisited – Part 3, API Layer and Grid Processing Architecture (this post)
An API layer (or Service Layer) provides a set of APIs to access data and/or functionality. Typically implemented using REST or SOAP services over HTTP, it provides decoupling of backend systems and applications from the clients that access them.
It is pretty common that Mule messages contain XML as a payload and that those messages need to be validated/transformed. XML documents can be automatically validated using XSD, though those validations are structural and sometimes we need to manually code some validation in plain Java (especially in complex scenarios like validating references, existence conditions and value dependencies).
Do you want share properties between mule instances? or just between different flows within Mule?. Then mule session properties are what you are looking for.