Speeding up your OES-enabled app

When you secure a WebLogic app with OES or use OES to secure a Java based application using the Java Security Module the overhead and performance impact is minimal (it's usually measured in microseconds). In fact most customers report that OES is faster than the code it replaced.

When you use OES' Web Services Security Module your application makes SOAP or RMI calls over the network to a central server or cluster of servers. This is inherently slower than in process calls, not because the Web Service SM is slow, but because SOAP, XML, and SSL all add computational overhead, and network communication adds latency. Consider that a simple ICMP ping is measured in milliseconds and it's clear that this might be a fairly large impact on your application.

When an application calls OES there is a single, common Java API you can use regardless of which SM you are using. At its simplest the API takes three parameters - action, resource and context data - and returns a boolean along with context data. Programmers new to OES will often go no further than making calls to this API and if you are using the Java Security Module, which runs in the same process space as your application logic, you need go no further.

But if your making SOAP or RMI calls you'd be doing yourself a disservice by not looking further.

OES offers two additional API calls that allow you to make bulk authorization calls. One (isBulkAcessAllowed / isBulkAccessAllowed) allows you to send a batch of action/resource and context calls and get a list of true/false responses. The other (isChildResourceAccessAllowed / isChildResourceAccessAllowed) allows you to ask OES for a list of resources it knows about that the user is authorized to access.

These interfaces are also available in the WSDL and the .NET example shows how you can make these calls from C#.