SOA School: Put your SOAP to REST

Reading Time: 5 minutes

The benefits of applying the principles of SOA when catering to the IT needs of your organization are clear in a business-driven, vendor-neutral architecture. It considers all requirements from the perspective of the business process and delivers implementations in order to automate the same. The implementations themselves, driven by the same SOA principles and goals, are not bound to any one particular vendor because they are intrinsically interoperable, that is, they expose and consume Services or APIs (we use the terms interchangeably here).

The service, which is the building block of SOA architecture is reusable because it is agnostic to all business processes. It is effectively resused when it forms part of a composition, which typically maps to an abstraction of a business process. The SOAP standard has long been the backbone of SOA Service Interface design and continues to thrive inside the enterprise. An alternative standard in the form of RESTful Services has long been popular to engineers who prefer its simpler, more lightweight approach to the same problem. Regardless of the type of Service, SOA recommends governing and managing your initiative so that the reusable services do actually get reused and that the recurring logic typically needed to host these (security, quality of service, compliance, etc.) can be applied in the form of centralized and resusable policies.

As the New Enterprise enthusiastically embraces the vast array of discreet software solutions available in the cloud, it now seeks to leverage the single factor which has brought about the huge success of all of these SaaS offerings: their API-first approach. Building on the wisdom and solid principles of Service Oriented Architecture, the New Enterprise exposes RESTful Web APIs which can be consumed by the various channels of business (mobile, web, office, partners, resellers, etc.). In this way, it exposes its core business as a service, perhaps consumable in unforeseen ways beyond the enterprise! Thus, the suite of services and the orchestrations that invoke them can be easily leveraged and put to new use by facading them with a simple RESTful API, easily consumable by the client apps used in each of the channels.

With this post, I’d like to introduce you to the Anypoint Platform for APIs, which caters to the entire lifecycle of service and API design, development, deployment and API management – all on a single platform. We do so by showing how Anypoint Platform can cater to an omni-channel initiative within a retail business.

Designing your RESTful API for Longevity

Reading Time: 20 minutes

One of the greatest challenges API developers face is creating an API that is flexible enough to pass the tests of time and technology. In other words, creating an API that is built to last. Here are some tips to help you ensure your API has a happy, and long life expectancy – saving you a lot of frustration, and your company a lot of money!

“Unfortunately, people are fairly good at short-term design, and usually awful at long-term design.”

– Dr. Roy Fielding, Creator of REST

The first step to building an API for longevity is understanding that your API should be built to last beyond the current release, and even beyond your current roadmap. You want to build an API that developers can implement fearlessly, without worry that it will change in a few months, or even within a couple years.

After all, there is almost nothing that developers hate more than APIs that are constantly changing – as it breaks their code and destroys their application. In fact, I think more developers are more understanding of bugs than they are of repeated backwards compatibility breaks.

Continue reading

Integrating Mule ESB with .NET Based Rules Engines

Reading Time: 7 minutes

The recent release of the Anypoint Connector for .NET opens up many opportunities for plugging into .NET based rules engines. Since the .NET Connector allows developers to call out to native .NET code, these rules engines can be easily integrated as a result.

Anypoint Platform .NET solution

Why do I want to do this?

Utilizing a rules engine promotes efficiency in system interfaces where some business logic needs to be executed and this logic can be frequently updated. You could wire all of this logic into your integration application via custom code or using several routers but these rules become difficult to maintain in code and may require several re-deployments as changes are introduced. Using a rules engine allows developers to decouple business logic from integration logic and as a result, rules can be easily maintained.

MuleSoft recognizes that organizations may have made significant investments in .NET based rules engines and these rules may need to be extended from their legacy platforms for a period of time. As a result of business transformation, there may be new requirements that are better suited for a modern integration platform to address in order to support API or SaaS integration use cases. MuleSoft’s Anypoint Platform is able to support these use cases by providing the agility and connectivity to enable these business scenarios while supporting an existing rules engine platform.

Connecting the BizTalk Rules Engine

To demonstrate this concept, we will take a recent customer scenario for connecting Anypoint Platform to the BizTalk Rules Engine. This MuleSoft customer has seen their IT landscape evolve and they now have requirements to support SaaS based endpoints and comprehensive API lifecycle management. Much like any organization, there were some timing constraints in making a complete transformation. As a result, they wanted to continue to leverage their legacy rules engine for a period of time while this transition was taking place.

High Level Architecture

In this simplified walk-through we are going to have a consuming application that would like to perform a credit check on a particular customer request. This scenario is well suited for using a business rules engine as there is different logic involved in performing this credit check that can change frequently. When the credit check logic does require modification, we do not have to redeploy a lot of different components; just a set of business rules. A rules engine provides a ‘separation of concerns’ that allows an ESB to focus on what ESBs are good at: connectivity and routing.

The flow of our solution follows:

  • A Consuming Application will reach out to Mule ESB via an HTTP request.
  • Mule ESB in turn will call a native .NET method via the .NET Connector. This connectivity is enabled via the .NET Connector that was released in July 2014. The .NET Connector allows developers to call .Net assemblies that have been written in any .NET language.
  • The BizTalk Rules Engine does expose an API which can be consumed from any .NET assembly or application.  We are able to take advantage of this API within our .NET method.
  • We will pass a TypedXML document to the BizTalk Rules Engine which is the data format that the BizTalk Rules Engine is expecting.
  • The BizTalk Rules Engine will evaluate the incoming message and then run it through a series of 5 different rules that evaluate the Customer Group that that the customer belongs to in SalesForce and the max credit threshold for that particular group.
  • A boolean value will be returned that includes a flag indicating whether or not the credit check has been approved or not

Conclusion

In this blog post we discussed some real-world concepts and challenges that Connected Enterprises are encountering. We were able to provide a solution that allows organizations to be flexible while enabling innovation that allows organizations to meet their business objectives.

Biztalk vs Mule ESB »
Learn how to move to a modern integration solution »

Infographic: The Future of Financial Services

Reading Time: 4 minutes

The Connected Bank

For many banks, back office systems for such critical functions as deposit accounting, loan servicing, and payment processing have been in place for decades, running on huge legacy mainframes. According to industry analysts, IT departments spend 70 to 90 percent of their budgets managing and maintaining these disparate systems, leaving little left over for new initiatives.

In addition, with poor operational efficiency a barrier to growing revenues, banks have prioritized reducing exceptions, delivering transparency, and improving system interoperability to increase technology ROI.

But it’s not enough to “run the bank” as some in the industry refer to business as usual spending. IT departments also need to “grow the bank”—delivering new products and services to meet customer demand. For example, according to the World Payments Report 2013, customer demand and innovation is driving the global mobile payments market, with volumes tripling over the past 4 years. Much of this growth comes from non-bank providers who have outpaced banks in delivering innovative and customer-centric mobile payment solutions, raising customer expectations. In an effort to keep up, banks are expanding mobile and tablet banking features.

However, rigid, monolithic legacy technology is restricting the ability of banks to meet the demands of increasingly web-savvy digital natives, accustomed to performing transactions instantly, whenever and wherever they want. Whether a bank decides to undertake a major “rip and replace” modernization program or refresh their architecture with newer technologies such as web services, cloud computing, APIs or OpenStack, integration is the key to growing the bank. For example, in order to enhance a corporate mobile banking app with real-time payment tracking, a bank could use a private API to send and receive data to the back-office payment system using web services.

A next generation connectivity platform enables application integration across on premises and cloud systems, web services orchestration and governance, and API creation and management, all on one platform. MuleSoft’s Anypoint Platform is the world’s leading connectivity platform for SOA, SaaS, and APIs. It enables financial services firms to realize the vision of a Connected Bank. Here is our infographic showing how leading financial institutions are realizing this vision: