This post is brought to you by Pablo Cibraro. Pablo is a Software Architect focused on MuleSoft’s solutions for Microsoft.
As part of our on-going effort to make Anypoint Platform even more accessible and intuitive for .NET developers, we are thrilled to introduce a RAML parser and Visual Studio extensions that make it easy to consume and implement APIs using RAML.
What is RAML?
RESTful API Modeling Language (RAML) is a language for describing a Web API in terms of resources, methods and implemented patterns (security, paging, filtering, projections, etc). RAML is based on YAML and leverages other open standards such as JSON or XML to document the schema of the resource representations. In short, RAML allows you to do the following for your API:
- Write Human-readable documentation using Markdown
- Define supported resources and HTTP methods
- Reuse common usage patterns such as data paging or filtering
- Describe expected responses for multiple media types with schemas and examples for each
- Define security aspects
Here’s an example of a RAML document describing a very simple API for browsing a movie catalog:
Our January 2015 release of Anypoint Platform brings with it many new updates to power API-led connectivity. For organizations with investments in .NET, we are thrilled to add to the list the 2.0 release of our .NET Connector. The enhanced .NET Connector enables .NET developers to use familiar languages and tools when building integration applications with Anypoint Platform.
With this connector, you can use Visual Studio and any Common Language Runtime (CLR) language to write code for complex transformation and message enrichment to apply business rules or perform custom message routing logic within a Mule application. You can also reference or reuse existing code including third-party assemblies, and build new libraries of custom codes specifically for your application.
Citrix Modernizes BizTalk with Anypoint Platform
To stay relevant, today’s businesses have to adopt SaaS applications, cloud services, and API technologies and integrate them with their legacy systems. In SearchSOA this week, MuleSoft customer and Citrix integration developer Vinod Sangaraju discussed how Citrix has deployed CloudHub and is planning to use MuleSoft’s new solutions for Microsoft to fill BizTalk integration gaps.
Citrix Systems integration development manager Vinod Sangaraju found the MuleSoft Anypoint Platform when searching for an iPaaS solution to connect Citrix solutions with Salesforce, Marketo, Workday, and other cloud and on-premises applications. His search was driven by Microsoft BizTalk’s limited SaaS connectivity. His team had been filling that gap by using Microsoft BizTalk for on-premises integration scenarios and MuleSoft’s Anypoint Platform, in particular CloudHub, for cloud-to-cloud and cloud-to-ground integration. That wasn’t ideal, he said.
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.
MuleSoft’s Anypoint Platform vs. Microsoft BizTalk Server
Last Updated August 26, 2016: Have you ever wondered if you should choose Microsoft BizTalk or MuleSoft’s Anypoint Platform? Below are 10 points to consider when deciding on the best integration solution for your organization:
1. Extensibility to Best of Breed
BizTalk Server promotes a tightly coupled model in which many of the services are bundled within the product. While this is great for compatibility, it limits the ability of companies to use 3rd party applications that may provide better functionality. MuleSoft has built Anypoint Platform to be open and extensible to best of breed services and applications.
Announcing MuleSoft’s solutions for Microsoft!
Today, we announced the launch of MuleSoft’s Solutions for Microsoft. These new solutions enable companies to leverage existing Microsoft IT investments and integration logic written in .NET on Anypoint Platform™. Using our new .NET Connector and MSMQ Connector, developers no longer have to to be siloed by coding language or development framework. With MuleSoft’s solutions for Microsoft, developers can customize Mule application logic using any .NET language and familiar .NET development tools, including Visual Studio.
A Step-By-Step Guide
SaaS applications like Salesforce have proven to be highly disruptive for many .NET architectures. In this multi-part blog series, we’ll demonstrate step-by-step how .NET-centric organizations can use existing assets (e.g. legacy .NET applications, SAP) to maximize the value of their Salesforce investment without disrupting underlying code.
SaaS and APIs have changed the IT landscape. Applications you need to connect to now and in the future will be in a variety of languages and likely not in your datacenter. Limiting your next generation integration server by code base or deployment architecture will handcuff IT innovation, limiting your company’s ability to embrace future opportunity. .NET developers looking to get their company connected should think through these five questions before starting on their journey to a modern, loosely-coupled architecture.
How do I expose services in the style preferred by each client?
There are two major schools of thought for web services: SOAP/WSDL and REST. Given the large number of legacy systems in place in a typical enterprise, your integration software should meet the demands of each approach regardless of what is used by a given service. A modern integration engine can perform the heavy lifting to translate each message from the surfaced API into the form used by the target service. It can then transform and route messages while bridging different protocols along the way (e.g. HTTP to MSMQ). Using this method, clients become less dependent on interface and protocol requirements and service owners can vary services over time to meet changing business requirements while mitigating down time.
When looking at options for your next generation integration platform, the development language of the underlying ESB should not be a primary concern. .NET teams in particular often constrain their search to only .NET-centric ESBs, ultimately leaving them few options. If you find yourself in this position, here are a few things to consider:
- At its core an ESB is all about interoperability.
A strong ESB will support a broad range of standards, protocols, and adapters, enabling integration of services and applications written in any language or platform. A Best of Breed ESB doesn’t care if the services it is connecting are written in Java or C#.
- A Best of Breed ESB will enable the majority of integration work to be done through tools that are easy to learn and provide visibility into what is happening in the ESB, rarely requiring developers to write or debug code.
- Java and C#, the predominant languages in the enterprise, are nearly identical in syntax.
So how should you choose the best ESB solution? As you begin the journey to evaluating your next generation integration platform there are critical components that will help you connect, implement, and deploy faster:
The SOAP standard was created to address the communication needs between different applications independently of the programming language, platform or technology in use. It is a standardized protocol based on XML over a variety of communication protocols such as HTTP, to invoke methods on remote objects. In this blogpost we’re going to consume SOAP web services implemented with the Microsoft Windows Communication Foundation framework (WCF) from a Mule application. WCF is part of the .NET framework since version 3.0 and provides the building blocks to expose C# and VB.NET methods as SOAP web services, hosted on the IIS web server.