Cross-Origin Resource Sharing(CORS) in OAG

Cross-Origin Resource Sharing (CORS) provides a mechanism for browser-based applications to make requests to a resource in another domain. Using CORS, programmer can continue regular XMLHttpRequest. It is alternative to the JSONP pattern which is forced to program the callback function. In the case above, cross-site scripting (XSS) issues may happen. And JSONP only supports GET HTTP VERB.

In API Gateway, HTTP listeners can be configured to support CORS to selectively allow access by web applications running in other domains. Please see the following policy setup for CORS.

Continue reading

How to Enable OAuth endpoints in OAG

The OAuth service is not available in the basic installation. You must deploy it manually.

1.Set up API Gateway OAuth 2.0
However, there is a convenience script in $VDISTDIR/samples/scripts/oauth for deploying the OAuth 2.0 Services Listener, supporting policies and sample apps, this can be run from $VDISTDIR/samples/scripts with:
Continue reading

OAG throttling across multiple instances

As I have discussed the Global Cache in the previous blog, I will explain how to throttle web service call across multiple instances by utilising Global Cache.

1. Setup the Distributed Cache
Distributed Cache1
Note: Use the variable ${env.SOA.EXTERNAL.HOST} for hostname. This best practice will make easy when you build and deploy the configuration.
Continue reading

OAG Global Caches

OAG Global Cache stores the a unique identifier for the request, whenever the same request comes in, the cache can retrieve the result instead of forcing the Web Service to reprocess the identical request and generate the same response.

Based on those features, we can setup distributed cache to track the web service request and throttling across instances. For the detailed setup for throttling, I will introduce in the later topics.

Here I list the distributed cache setup screen.
Distributed Cache

Service Virtualization IN OAG

OAG has got in-built Load Balancing functionality which is different from any network appliances like F5 etc. So after the service is registered to convert REST to SOAP dynamically, or deployed in front of a database, or a message queue, or an ESB, user would connect call those services from internet or intranet. They will go through frontend network load-balancer, which talk to the OAG listener. Then OAG will perform all the policies redirected with service handler. And then OAG will utilise its own in-built Load Balancing to talk back to the back-end service. The following shows the workflow summary.
Continue reading