a turmericdb schema in a MySql database to store the predefined policies

any web browser, as REST client, FF in my case

Jetty-Turmeric Web Server Setup:

Download and decompress jetty-turmeric. This customised Jetty already provides a Echo Service as example. We need 4 instances (copies) of it, so let’s call it jetty-turmeric-1.0.1.0-SNAPSHOT-1, jetty-turmeric-1.0.1.0-SNAPSHOT-2, jetty-turmeric-1.0.1.0-SNAPSHOT-3 and jetty-turmeric-1.0.1.0-SNAPSHOT-4. Don’t forget to change their listening ports, otherwise you will get a nightmare of conflicts. I choose 8080, 8081, 8082 and 8083. Also you need to change SSL ports, and debugging port in case you want to do a remote debuggin with Eclipse: -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

Then, lets prepare the Jetty #1 and #2, those who has the Echo Service Consumer. One of the yellow boxes we need to setup in the SIF is the AuthenticationHandler, that is a handler which makes call to the Authentication Service deployed in Jetty Server #3 and 4 respectively. So we need to edit the {JETTY-HOME}/resources/META-INF/security/config/AuthenticationPolicy.xml file and add the operation against we need the Authentication process be run :

As some services are deployed under another Web Server, we must indicate the actual endpoint and don’t forget to change the Transport Protocol, from LOCAL to HTTP. This applies for {JETTY-HOME}/lib/turmericsoa-security/AuthenticationServiceConsumer-1.x.x.jar/META-INF/soa/client/config/AuthenticationService/ClientConfig.xml

As we can see in the above chart in Jetty#3 resides, Security Service, Policy Service and PolicyAdminUI (the Web UI for
policy Administration).
Download and extract them under webApps folder. Then the custom updates are:For Security Service: NoneFor Policy Service: NoneFor PolicyAdminUI: in {Jetty3-HOME}/webapps/policy/lib/web.xml update the endpoint ports as Jetty3 has, that is 8082
for http and 8445 for shttp.

Later, in both {JETTY3-HOME} and {JETTY4-HOME} /resources/META-INF/config/cassandra.properties you need to add Rate
Limiter Keyspace info and also indicate there that cassandra will run in standalone mode instead of embedded mode,
default mode.

This config should follow the cassandra configuration. Other cassandra files are not necessary to be changed due to we set embedded=false. This, tells Turmeric that Cassandra service is running in a standalone mode; setting to true TurmericSOA will start its own embedded Cassandra service.

A new “googol” event is coming son, Nov 30th, the GooglePlex takes place at Olympus Mons Tech Talk Room, Building CL4 in Mountain View, CA.

“Googleplex is a 1-day event for developers to learn about different Eclipse projects and related technologies. You are invited to attend and listen as experts from the Eclipse projects and Google share their experiences of using Eclipse. It’s also a great opportunity for you to meet and network with other Eclipse enthusiasts”

There you can learn about two projects under the EbayOpenSource ecosystem, VJET, an Eclipse plugin for javascript development by Justin Early (eBay) and TurmericSOA, the open source version of eBay’s SOA engine, by Dave Carver (Intalio)

Turmeric‘s next release will provide two new rule patterns for Rate Limiting Policies, which allow to limit calls for any XACML Subject or Subject Group. With them, grows the rules flexibility as well as its throwput.

Recalling those years developing a Motohealth protocol, I cleaned up the dust from my writing capabilities in EBNF 🙂 , then, this is how the Rule syntax looks:

128.10.10.4:hits>1000: Limit that IP after 1000 calls*HITS>10000: Limit any call after 10000 calls, regardless what and who made them*MyService:my_operation.count>150: Limit any call to my_operation after 150 calls, regardless who made them*MyService.count>100: Limit any call to myService after 100 calls, regardless the caller and the operation*

new ones….MyService:my_operation.SubjectGroup.count>500: Limit any call to my_operation after 500 calls, made by a Subject Group*
MyService:my_operation.SubjectGroup.Subject.count>500: Limit any call to my_operation after 500 calls, made by each Subject member of a Subject Group*

(*) Limiting action acts based on on the specified Effect action field.

Don’t forget Subject and SubjectGroup must be targets on the RL Policy definition. (FMI refer the Turmeric 1.0.0 wiki)