Cape Clear ESB (Workday) Assemblies Context Options

One client I am assisting is the Cape Clear ESB and it Assembly functionality. This provides mediation support via a Spring Bean configuration file which is generated via graphical drag/drop tools. Because the Assembly Service is stateless and the project we were working on required some context sharing, we had to open up the covers and learn about org.springframework.context.ApplicationContext and org.springframework.beans.factory.InitializingBean. A single bean with a scope of singleton was developed to provide context for all instances of the assembly and when the assembly was loaded this information was initialized as part of the afterPropertiesSet() method.

Within each instance of the assembly, Cape Clear provides another context called com.capeclear.mediation.MediationContext which provides a setProperty() and getProperty() method. This provides simple storage of variables within an instance.

XACML: An option for authorization

I am currently taking the next step in security development learning about XACML from www.oasis-open.org. In the scenario that I am working on with the client, there Identity Management Solution will be acting as the Policy Authoring Point whereas the ESB that we have deployed will act as a Policy Enforcement Point and Policy Decision Point. Due to the fact that we have a clustered ESB a decision that we are mulling over is whether to have a central/shared directory for XACML Policies or use the support for XACML Request/Responses to do it real time. Our concern is the latency especially in a high volume environment and we are currently steering towards a shared directory. This will allow each ESB to take a portion of the load and keep the processing local.

As part of a SOA Solution we will be using Service Agents or Intermediaries to support the authentication (SAML) and authorization (XACML). The ESB provides out of the box interceptors for both of these and only requires that the Service Consumer be able to interact with the SAML Provider.

SAML

Well it's been awhile since my last post but work and life have been quite hectic. Currently I have a client that is attempting to integrate a Identity Management/Policy Decision application with their ESB. As part of this effort examination of the many options has presented itself and we have agreed to examine the Security Assertion Markup Language as a potential solution. The overall use case is to have internal/external clients use an SSO approach towards invoking available services.

To demonstrate this capability a SAML Assertion will be inserted into the SOAP Header of a request. The deployed Web Service in the ESB will include Message Processing Logic in the form of an interceptor. The interceptor will examine the SOAP Header and SAML Assertion. At this time, it will be absent of a Digital Signature which adds an additional layer of integrity for the Assertion. The other challenge is the use of SAML 1.0 versus the current supported version of 2.0. Fortunately, the PDP has support for SAML 1.0 eliminating the immediate need to custom code 2.0 support.

For a sample SAML Assertion, check out the Sun Web Site at:

Sun Sample

and OASIS which manages the specification.

OASIS Site

Service Scalability

Over the past few weeks I have spoken with several customers who are implementing SOA in various stages and have decided to employ Web Services as the foundation. One of the key concerns is scalability and the ability to handle large volume for public / private services. An approach that evolved from these discussions was the following:

- For new services, specify governance in the Service Analysis / Modeling phase. This should specify the SLA for the Service and help identify the potential reuse and usage pattern that may be experienced.

- Services typically begin with a single instance using protocols such as HTTP

- Service scalability should be tested via Performance tools to determine how it degrades with load, supportable performance etc.

- Services should be monitored using JMX or similar API to determine runtime usage and usage patterns.

- Make services stateless so that they can be easily clustered.

- If service usage is higher than anticipated, consider configuring a cluster of service instances and use Hardware or Software load balancing.

- If throttling is desired, have service instances read requests from a JMS Queue as this places an abstraction between the service consumer / service provider. Queues allow for asynchronous communication and persistence point for inbound requests. Services can then throttle how quickly requests are processed without losing messages.

Deployment / Test of simple BPEL Process in Apache ODE

In my previous post I spoke of the configuration / startup of Apache ODE. This morning I deployed one of the examples and tested it using the provided sendsoap.sh utility and SOAPUI. A couple of things were necessary to do this:

1) New processes are stored in a folder with the process name and include:
- BPEL File
- WSDL(s) File
- deploy.xml (deployment descriptor)
- other necessary files
2) The folder is stored under the directory.
3) On startup the server will load the processes and report on it within the server log file as shown below:



4) The Apache ODE User Guide then describes a way to test services using a script called sendsoap.sh under the Apache ODE Distribution bin directory. To get this to run I needed to open up permissions using chmod. One this was complete the syntax for executing this is:

/bin/sendsoap.sh (URL to the web service) (SOAP file sample)

or in the case of what is provided in the distro:

/bin/sendsoap.sh http://localhost:8080/ode/processes/helloWorld examples/HelloWorld2/testRequest.soap

When executed the following is returned in the client window:



The tomcat/catalina server window shows the following:



5) Testing in SOAPUI, the following was executed and the results are shown in the following image:
- Created new project in SOAPUI
- Selected WSDL
- Generated a message
- Invoked Service

Setting up Apache ODE within Tomcat / Axis2

So it has been a busy week and I have had little time to work on the Open Source BPEL investigation. I have decided for simplicty sake that I start with Apache Axis2 versus Apache ServiceMix. This will allow me to quickly fire in SOAP requests and not have to become familiar with the ServiceMix infrastructure. I will tackle this next and apply what is learned here to that.

So here are the steps that I followed to get Apache ODE installed within Axis2. I made the mistake of initially downloading the Axis2 binary distro versus Tomcat. The Apache ODE instructions work with Tomcat/Axis but not Axis2 standalone.

1) Download Apache Tomcat 6.0.16
2) Download Apache Axis2 1.3 WAR distribution
3) Download Apache ODE 1.1.1 WAR distribution
4) Copy axis2.war to tomcat/webapps
5) Copy ode.war to tomcat/webapps
6) Set JAVA_HOME
7) Run Tomcat using tomcat/bin/catalina.sh run

The console then shows the following on startup:



Success!

I then accessed the Axis2 Console and could see the Apache ODE Services by going to http://localhost:8080/ode.



Next will be deployment of a BPEL sample into Apache ODE and invoking using SOAPUI.

Cheers!

Eclipse BPEL Project

Just wanted to give a rundown of the Eclipse (Europa) BPEL Project and my impressions at the moment. The eclipse bpel project is located at:

Eclipse BPEL Project


Having experienced most of my BPEL development in either TextPad (BPEL 1.0) or in the Cape Clear Studio solution (BPEL 1.1), the Eclipse BPEL Project was not too difficult to slide into. Here are the highlights:

- BPEL Project is only focused on BPEL 2.0. No BPEL 1.1 at this time.
- Overall GUI is nicely organized and employs a very similar look and feel to the BPEL Editor in Cape Clear.




-Assignment Editor in the current release M3, does not provide a graphical drill down to the schema element level. You can select your messages but no further.




-Activities are easily selected and placed in the panel. The Properties window needs to be visible to then edit those value.
-No tab to edit the BPEL directly with context sensitive help. I opened the BPEL in an XML Editor and flipped between the windows.
-XPath is done manually rather than created via the selection tool.
-PartnerLink defintion process is not as easy as in Cape Clear but it does generate an artifact WSDL file that includes the partnerlink definition so you do not need to muck up your WSDLs with the elements.

Issues that I have experienced:

1) Currently the Web Service Tools that is bundled with the BPEL Project appears to have a bug with imported schema. This is obviously unrelated to the BPEL Project but the full-lifecycle of developing the Service Contract and using this for the BPEL is not working properly. Currently have to use inline schema instead of importing.

What I haven't tried:

1) Deploying generated BPEL 2.0 into a container. Will try Apache ODE in either Axis or ServiceMix to confirm execution.