Monday, November 26, 2012

Video blog: Service composition / orchestration to SaaS with the Axway/Vordel API Gateway

Ross Mason from Mulesoft recently wrote an article entitled "With SaaS, it’s not just about your apps — it’s how you connect those apps, too". This is very true. APIs are what are used to connect apps together, and, as Ross explains, it frequently makes sense to orchestrate them, to achieve a greater business purpose.

For this reasons, a frequently-asked question about the Axway/Vordel API Gateway is "Can you orchestrate or compose two APIs using it?". Indeed this is possible, and quite easy to setup. Frequently, you wish to call one API and then use the output of that API as an input into another API, for example a SaaS API like SalesForce.com. 

In this video blog, I'm showing how to call an email verification API, to check the validity of an email address, prior to calling the SalesForce API. The Axway/Vordel API Gateway orchestrates the calls to both APIs as part of one "circuit" or policy. Below, I have put a diagram of the flow:


First let's walk through at the scenario. It's a familiar scenario where an organization has a web form which is filled out, and the information is inserted as a lead into Salesforce.com. We wish to check, firstly, if the email entered into the form is valid. Here's the scenario explained:

video

So, firstly lets see how a policy is configured on the Axway/Vordel API Gateway, using drag and drop, to connect directly to SalesForce, to send information from a Web form up to SalesForce, using the SalesForce API. Notice how this policy makes use of a "Policy Package", placed into a grouping in Policy Studio called "Cloud":


video

Once we have made our simple policy, we wire it up to a path on the API Gateway so that requests from the Web form result in a call to the SalesForce API:


video

Now we are in a position to post our Web form, which results in the information from the form being sent up to SalesForce through its API. Remember we haven't orchestrated in the email verification API yet. So, the bogus email makes it through fine.

video


Next we do the actual API orchestration. We add in the callout to the email verification API. Let's see how that is done:


video


At this point, we now have our service orchestration in action. The Axway/Vordel API Gateway has composed the two APIs together. If the response from the email verification API is a success, then we call the Salesforce API.

Let's see it in action:

video

Now let's take a closer look at how the response from the callout to the email verification API is used to check if the email is valid or not:

video

Finally, one of the most important aspects of orchestrating APIs is that you can apply SLAs (Service Level Agreements) and reporting to the APIs you are calling. This is especially important for SaaS services which you're paying for, such as Salesforce.com. Let's see how this is done with the Axway/Vordel API Gateway:


video
In this video blog, we saw application orchestration to a SaaS service via APIs, using the Axway/Vordel API Gateway. If you want to test this in action yourself, you can get your own free copy of the Axway/Vordel API Gateway from the here.

Friday, November 23, 2012

Another key difference between REST and SOAP

A lot has been written about the difference between REST APIs and SOAP Web Services. The technical differences are well known at this stage. SOAP is heavyweight, while REST is light and mobile-friendly. However, there is another key difference which is often overlooked:

  • It is easy to create SOAP Web Services, but difficult to consume them. 
  • It is difficult to create a good REST APIs, but easy to consume them. 
Taking SOAP first: development platforms such as .NET made it almost too easy to create a SOAP Web Service. I remember seeing MSDN demos showing how, in a few clicks, you can take a .NET object and expose it as a Web Service, complete with WSDL. But, in those quick clicks, what had you created? You had exposed the methods of your objects as SOAP operations. But why? Is this really what you wanted to do? And while it was easy to say "Clients can just consume the WSDL to call my new Web Service", this was easier said than done. And when clients did this, it often made little sense to directly run the methods of the class. 

Fast forward to the world of REST. One of the great virtues of REST is that it is so much easier to consume a REST API, compared to consuming a SOAP Web Service. In addition, it does not require parsing XML, if you prefer to directly read in JSON. However, creating a good REST API takes thought and some decisions. You should think about how you'll appropriately use the HTTP verbs, how to express versioning, and what kind of error messages you'll return. Fortunately, an API Server helps a lot here, by providing a platform for delivering APIs, to take care of aspects like security, usage quota-management, and analytics. But it still is important to take time to design your API up front. 

Friday, November 16, 2012

ProgrammableWeb: API's, the soft underbelly of online banking?








I have written a piece published in ProgrammableWeb today on "API's, the soft underbelly of online banking". The coverage of the recent DDoS attacks on US banks focused on the fact that their websites were down, but the fact that the attacks also impacted their mobile apps seemed to be treated like an afterthought. The mobile apps were impacted because their APIs were not available, resulting in the apps being unable to "call home" to log the user in, get their balance, etc. I believe that as mobile apps (and apps in general, from all sorts of devices) continue to become the primary way in which people use the Internet, API outages will be as damaging, if not more, than website outages. This points to a need for API Server technology to monitor uptime and alert based on attacks like this.

Wednesday, November 14, 2012

Industry Analysts on Axway and Vordel

Gordon Smith in Silicon Republic has a nice article today on the analyst coverage of the recent Vordel-Axway news. He summarizes the responses from Gartner and Forrester analysts. He notes that:
Industry analysts have welcomed the news last week that Ireland’s Vordel is to be acquired by the French software group Axway. 
Paolo Malinverno, a vice-president of research with Gartner, has been tracking both companies for several years. He classified the deal as the combination of a leader in the enterprise B2B space with a smaller, focused player specialising in API management and SOA governance. “This unites an industry leader with a much more innovative company and literally unifies the market and multiplies it, to some extent,” he said. “It’s a good match and it’s definitely a case where the total is greater than the sum of the elements.” 
Stefan Ried, principal analyst with Forrester’s Business Technology Futures team, said the deal makes sense for a middleware vendor and B2B integration specialist like Axway to consider a security vendor as an acquisition target. “The need to modernise security around integration scenarios becomes more important than ever,” he wrote in a blog post. http://www.siliconrepublic.com/strategy/item/30213-analysts-welcome-axway/
Kin Lane also covers the news on his API Evangelist blog. Kin's take is that:
...the acquisition shows the API industry is maturing and producing desirable companies with proven API products, that larger software companies can use as a competitive advantage. While Vordel's API management, SOA governance and identity management will help Axway’s customers, I think Vordel’s customers is probably the type of new client large software companies will want be also seeking out through acquisitions. http://www.apievangelist.com/2012/11/13/axway-acquires-api-management-service-provider-vordel/
It's definitely true that, as Kin notes, API Management has long passed the tipping point and now large organizations are deploying products like Vordel's, which is the sign of a mature industry.

Thursday, November 8, 2012

Delivering Value-Add without the Value-Added Network

Stefan Reid from Forrester blogs today about Axway's intent to acquire Vordel. Stefan has a deep background with companies such as Software AG and SAP, and at Forrester has been leading thinking on Cloud integration brokers.

Stefan perceptively links the Vordel-Axway move into the broader move of B2B from private networks to the Internet. He writes that:
Traditional B2B integration over private networks is more and more replaced with B2B connectivity and cloud based integration over the internet.
http://blogs.forrester.com/stefan_ried/12-11-08-axway_aquires_vordel_why_does_the_acquisition_of_security_experts_by_integration_vendors_make_sense
This has deep resonance for me. In 1996, I joined an EDI Value-Added Network (VAN) provider in Ireland called Eirtrade. I was charged with enabling their customers to leverage the Internet for B2B transactions. I was recently out of college, so I was excited to use my programming knowledge in action.

What makes a 'Value-Added' Network different than any other network?

One of the first questions I asked at the VAN was "What makes a 'Value-Added' Network different than any other network?" (of course, at college I'd learned about Token Ring networks, etc). The answer was that the "Value-Added" part included: transformation, identity, privacy, and reliability. The VAN would provide message-transformation capabilities. It also guaranteed the identity of clients. In addition, the VAN was a closed-off network, which meant that sensitive data (e.g. medical test results) were protected. Finally, if a recipient was not available, the message could be resent or polled later.

Recreating the "Value-Added" aspect of the VAN on the Internet

The Internet was just the "Network", without the "Value-Added" part. Lacking security, privacy, or reliability. It quickly became apparent that my task was to recreate the "Value-Added" aspect of the VAN, except on the Internet. So this meant layering on identity, transformation, privacy, and reliability to the Internet-based B2B traffic.

The other 80%

The other thing which I quickly realized is that customers did not want to simply stop using the VAN. The VAN "just worked", and even if it was a bit expensive, it still enabled business. The real pain-point was to enable the "other 80%" of their customers and suppliers who, for one reason or another (usually cost), did not use the VAN. This was where the Internet came in. At the time (late 90s), companies setting up fast Internet connections would naturally think "Why not use this for our business transactions too?". The challenge was to connect these other 80% of clients to the network.

Trust

On the Internet, famously "nobody knows you're a dog". This is not a good basis for B2B commerce. When using the Internet for B2B, the challenge was to layer on Identity. In the late 90s, this means digital certificates. Now, we have OAuth 2.0 and OpenID Connect.

Putting it all together

After implementing some B2B-over-Internet projects with Eirtrade, putting together solutions for identity and message transformation, implementing the "Value Added" benefits missing from the Internet, I naturally thought "If there was a product which just did this, I would use it". This was the genesis of Vordel. Increasingly it was clear that B2B traffic would make use of Web technologies (HTTP(S), XML) on the Internet, and therefore a product was required to apply all of the "Value-Add" to this B2B-over-Internet traffic, to fill in all the "Value-Add" which is provided by a traditional VAN.

Vordel's products, from Day 1, have been to enable B2B traffic on the Internet. Starting with XML, then SOAP came along, and REST APIs. And now, Cloud-based. This is a perfect fit with Axway, with its heritage in Managed File Transfer (widely used for B2B) and B2B platforms. It's exciting times, and I'll be following Stefan's ongoing research closely. 

Wednesday, November 7, 2012

Extending the Enterprise


Today I'm very happy to be able to share the news that Axway has announced intent to acquire Vordel. Axway is a leader in B2B software offering a range of products that link businesses together – products deployed worldwide in industries ranging from manufacturing to financial services to government. Vordel's cloud and mobile technology is highly complementary to Axway offerings, as organizations build upon existing B2B and MFT integrations to encompass SaaS services, APIs, and mobile apps. 

Here at Vordel, we already see customers benefiting today from the combination of Axway and Vordel products working together. With Axway and Vordel, these organizations can deploy their business interactions together, across many data formats and protocols, all managed under one policy umbrella. This capability is of great value to the enterprise, because it simplifies governance, providing one suite that encompasses legacy formats as well the latest API, mobile, and cloud technologies.

Vordel also provides very strong identity management integration, including the latest standards such as OAuth 2.0, backed by a very flexible policy engine for fine-grained access. With Axway and Vordel, these identity and policy capabilities can now be applied to many different types of business interactions, all while managing policies centrally. Business can now extend the edge of their enterprise to embrace cloud and mobile with unified governance.

We will soon share more about these exciting plans – plans that will be of great benefit to both new and existing customers.

For more information read the FAQ here

Thursday, November 1, 2012

API Gateway Design - Making De-Normalization the Norm

In database design classes in Computer Science, we learn that normalization is a good thing. And it certainly is a good thing, for databases. In the case of APIs, it is a different story. If a client must do multiple GETs to obtain the data it needs, or multiple PUTs or POSTs to send up data, just because your database happens to be normalized, then something is wrong.

One of the functions of an API Gateway is to de-normalize your data so that clients are spared from making extra REST API calls, with all of the overhead which goes with that. Mugunth Kumar explains this very well in this excellent presentation, using Twitter as an example. When you do a GET on a tweet, it not only returns you the Tweet itself, but also other information (e.g. description of the Twitter user who sent the tweet). This saves the API client (often a mobile app) from making another request for that data. Effectively, the API Server has gathered up that data, which may come from different database tables, and de-normalized it for the response. You can try it out yourself here, by looking at the JSON which comes back from this Twitter API GET the most recent Tweet from my timeline.

Many Vordel customers are using the API Server to gather together the data which is returned to the API clients, often taking this data from multiple sources (not only databases, but also message queues and even from other APIs). This data is then amalgamated into single JSON or XML structures. It often then cached at the API Server, in this structure. In this way, clients are spared from doing multiple calls, and instead (like the Twitter API example above) get the data they need in one request, or can PUT or POST up data in one action, rather than piecemeal. De-normalization is key to this process, and is one of the great benefits of an API Gateway