Wednesday, January 25, 2012
It is quite simple to configure this with the Vordel Application Gateway. Just right-click the Listeners -> Vordel Reporter node in the Policy Studio tree, and follow the configuration steps which are listed here on the Vordel Extranet: https://extranet.vordel.com/documentation2/VG6/common/tutorials/reporter_scheduled_reports.html [ If you need a logon for the Vordel Extranet, contact Vordel at firstname.lastname@example.org ].
Tuesday, January 17, 2012
To answer this question, it is useful to divide up the load balancing requirement into "in front of" (ingress) and "behind" (egress) the Gateways.
In front of the Gateways (ingress), if there is already a load-balancer in place, then it's natural to deploy the Gateways in Active-Active configuration behind it. If the reporting or routing requires the source IP address, then load balancer can place this into the X-Forwarded header and the Gateway consumes this.
Policy Director is used to send the same configuration to multiple Gateways in an Active-Active cluster (and if there is a hot-standby, then to it also).
The distributed caching across the Gateways is used to keep state (eg message counts for throttling across Gateways in a cluster).
If there is no load-balancer in place, then it's simple to setup a cluster of Gateways with a VIP (Virtual IP address) shared across them. Policy Director is used to keep the configuration in sync.
Behind the Gateways (egress), you can use the Gateway's inbuilt load-balancing. This can be Round-Robin across backend servers, or weighted on response time (Gateways will then favor faster backend servers). So there is no need for a Load Balancer behind the Gateway. Load-balancing in the Gateway is configured within a "Remote Host" in Policy Studio.
Wednesday, January 11, 2012
To answer the question, take a step back and think about what an Application Gateway is. An Application Gateway takes tasks such as application integration and application security and it moves them into a piece of network infrastructure (which may be virtual or physical). By moving these tasks out of applications and onto the network, you make the tasks run faster, and easier to manage since they are now decoupled from the applications themselves.
So, breaking it down, there are two things going on here: (1) moving integration and security tasks onto network infrastructure, and (2) managing the Gateway as a piece of network infrastructure. It follows logically that there are two distinct roles involved here: (1) The person configuring services and policies on the Gateway, and (2) the person operationally managing the Gateway. Person (1) knows about APIs, apps, and policies. Person (2) does not need to know anything about APIs (much less know anything about REST or XML) but knows all about SNMP, Splunk, load-balancers, and NAT.
This is why Vordel provides two distinct training courses, aimed at these two different people. For person (1), who will be registering APIs and SOAP services on the Gateway and applying policies to them, we provide the Vordel Certified Systems Engineer (VCSE) training. This involves registering APIs (via their URLs), choosing policies to apply to them, and pushing the policies out to Gateways. It includes SOAP and REST. For person (2), we provide the Vordel Certified Network Administrator (VCNA) training. This explains how to monitor the "speeds and feed" of a Gateway, where alerts can be sent, how to monitor it via network admin tools such as HP Arcsight, how to deploy additional virtual appliances in a VMware ESX environment, etc.
The separation of duties carries over to the Web-based interfaces used to manage the Vordel Application Gateway. In the case of the person managing APIs and policies, they see dashboards such as the one shown above. Here I see the traffic being passed to three APIs: CDYNE's EmailVerify service, SalesForce itself, and SalesForce's login service, for a two minute period on January 9th 2012.
In the screenshot above, we see what the Network Administrator sees. Rather than seeing information about SalesForce APIs, they instead see the network administration view of the Application Gateway. We see, for example, here the RAID Array Status for disks in the Application Gateway. Also, as you can see, system logs, networking, and server status can be monitored in this way. All of the same information can be sent to a product like HP Arcsight so that the network administrator does not even need to look at Vordel tooling.
In summary, there are two distinct types of people who manage Application Gateways on an ongoing basis, and this maps to Vordel's two distinct training courses, and to the different Web interfaces we provide for these people. All of this is geared towards moving application integration application security out of applications and onto the network (virtual or physical).
Wednesday, January 4, 2012
Kin mentions that:
One thing to know about these API management service providers is, well...they are API management service providers. To my knowledge they don’t actually deploy your API for you, they help you build a strategy, and manage the API. But you still need to rely on other tools and in-house resources to deliver your API.This is where I'd disagree slightly. In the case of an API Gateway, it can also be used as a service delivery platform to deliver an API in front of existing enterprise system systems. This is because API Gateways include many adapters to, for example, various message queues, TIBCO EMS/Rendezvous, databases, and FTP/SFTP. These are used to deliver a REST API interface in front of an enterprise system which does not natively support REST, not to mention JSON, OAuth, or OpenID. This can be as simple as delivering a REST API interface in front of an existing SOAP service within the enterprise, to mapping from REST into messages placed on the message queue, through to mapping from "lightweight" identity mechanisms suitable for APIs (such as OpenID or OAuth) through to enterprise identity management (e.g. mapping from Google OpenID to Oracle OAM). So, an API Gateway usually does not only manage the API, it actually delivers the API too.
Here is the policy in action. You can see that the Vordel Gateway creates a hyperlink to Google, to ask the user to select their account. If you look at the status bar in the screenshot below, you can see the OpenID string generated by the Vordel Gateway:
When I click the link, I am asked which Google account I want to use to log into the service. Google shows me the two accounts which I am currently logged into:
Once I choose the Google Account, I see that the Vordel Gateway has generated an Oracle Access Manager obsso cookie, which is visible in Firefox:
If you're interested in getting a copy of the policies I used for this, contact Vordel at email@example.com . For more information, including videos, about Vordel Gateway interop with various Oracle products, check out: http://www.vordel.com/oracle/
Tuesday, January 3, 2012
A Gateway serves an important purpose here, by providing fine-grained information on why clients are blocked. A Gateway can return XML to clients which expect XML responses, and JSON to REST API clients which expect JSON. Let's see how you can use the Vordel Gateway to take a policy which returns an XML fault (in this case a SOAP Fault) and converts it automatically to JSON...
To start this, I fired up Vordel Policy Studio and connected to my Dev API Gateway. I then dragged in a Policy Shortcut to a policy called "JSON Fault". Next I right-clicked on it and choose "Set as Fault Handler", as shown below:
This means that if any of the filters in the chain return false, my policy gets called. Next let's look at this policy. You can see below that it takes a regular SOAP Fault and converts it automatically to JSON:
When we look at it in action, in the API Gateway's Real-Time Monitoring, we see the familiar "Path through the policies" on the left, and on the right you can see the JSON which is returned to the JQuery client:
The API Gateway's Real-Time Monitoring shows what is happening now for your APIs and services. But in order to look at what has happened in the past, we open the API Gateway's audit trail. Here you can see the opening page, and I click on the "Audit Trail" button:
On the Audit Trail, I run a report for the API requests blocked in the last hour by my API Gateway. Here I see a bunch, and I click on one to see more detail.
When I click on the API request which was blocked, I see the exact reason why it was blocked in the "Path through the Policy". I can see below that it was the authentication which failed, the same reason which was passed back to the JQuery client.
So in summary, it's quite straightforward to return JSON fault information to clients, and view fault information in the Audit Trail, using the Vordel Gateway. To get more info, or your own copy of the Vordel Gateway, contact us on firstname.lastname@example.org