Examples mapping onto API
One of our recent internal checklist items was to take a brief look at a number of the examples and see how they map onto the SwitchYard API.
HelloWorld : HelloWorld is pretty basic and I don't see anything different here than what is in InOnlyTest.java or InOnlyOutTest.java in the core/runtime module. The only difference really is that in ESB 4.x, a JMSListener is used to receive the message. Obviously one of the requirements for Switchyard will be a JMS component - that would be needed to duplicate the message input.
CustomAction : The CustomAction quickstart reveals two areas that would have to be handled under the new API : a list of custom-defined process methods, and a custom property setter.
List of process methods defined in configuration file (StatefulAction.java) :
<action name="fourth" class="org.jboss.soa.esb.samples.quickstart.customaction.StatefulAction" process="methodOne,methodTwo,displayCount" > <property name="exceptionMethod" value="exceptionHandler" /> </action>
Doing something like this would be possible through the configuration, where we store ExchangeHandler functions to be executed, but it should be discussed whether the ability to execute multiple process methods in the place of handle or exchangeIn/exchangeOut is something which should transfer over from ESB4.
Property setter (jboss-esb.xml) :
<action name="seventh" class="org.jboss.soa.esb.samples.quickstart.customaction.CustomBeanConfigAction"> <property name="information" value="Hola Mundo" /> <property name="repeatCount" value="5"/> </action>
CustomBeanConfigAction.java :
private String information;
private Integer repeatCount;
public void setInformation(String information) {
this.information = information;
}
public void setRepeatCount(Integer repeatCount) {
this.repeatCount = repeatCount;
}
public Message process(Message message) throws ActionProcessingException {
System.out.println("[" + serviceCategory + ":" + serviceName + "] Repeat message: " + information + " " + repeatCount + " times:");
for (int i=0; i < repeatCount; i++) {
System.out.println(information);
}
}
In the example above, both the information and the repeatCount variables are set by automatic setters. The use of custom property setters and the ability to use those variables automatically is something that probably should be looked at in ExchangeHandler.
HelloWorldFileAction : The only thing really missing here is a File component. The HelloWorldFileAction quickstart employs a little bit of build trickery (an ant copy filterset) to rename the configuration file and to hard-code a few locations into it. The configuration file contains a number of options that are sent to a fs-message-filter (directory, input-suffix, work-suffix, post-delete, post-directory, post-suffix, error-delete, error-directory, error-suffix). Some of these are options that would need to be incorporated into the FileComponent and others are options that could be configured just by specifying a java.io.FileFilter and passing a number of properties to it.
SecurityBasic, SecuritySAML : In ESB4, the container's security implementation is leveraged to protect ESB services. In SecurityBasic, a security moduleName is specified within the Service definition in the configuration, and that module name is added to login-config.xml.
In terms of the API, there likely will have to be an extensible Security interface (like SecurityService in ESB) and checks/privileged execution added to the handler processing. In ESB4, ActionProcessingPipeline.java does the following :
// Authenticate the caller securityService.authenticate(securityConf, securityContext, authRequest); // Store the encrypted security context. Will be re-attached to outgoing messages. SecurityContext.setSecurityContext(SecurityContext.encryptContext(securityContext)); ... return (Boolean) Subject.doAsPrivileged(securityContext.getSubject(), getPrivilegedAction(message), null);
Security credentials should also be able to be passed in directly through a Context. Would this fit under Correlation or Exchange scope?
TransformXML2POJO : The interesting part of TransformXML2POJO is the use of SmooksAction - the rest of the quickstart is custom actions to display the message and to convert a POJO into message/String form.
In the configuration, the location of the smooks configuration file is specified as well as a resultType :
<action name="transform" class="org.jboss.soa.esb.smooks.SmooksAction"> <property name="smooksConfig" value="/smooks-res.xml" /> <property name="resultType" value="JAVA" /> <!-- property name="reportPath" value="/zap/smooks-report.html" / --> </action>
The ESB4 SmooksAction looks like it would be a pretty straight translation from Action to SwitchYard component. The SmooksAction looks for a number of ConfigTree properties (resultType, smooksConfig, reportPath, mappedContextObjects, message profile) which would be passed into the component.
MessageFilter / SimpleCBR : The interesting part of both the MessageFilter and SimpleCBR quickstarts is the ContentBasedRouter. We'll look at MessageFilter :
<action class="org.jboss.soa.esb.actions.MessageFilter" name="MessageFilter"> <property name="ruleSet" value="FilterRules.drl"/> <property name="ruleReload" value="true"/> <property name="destinations"> <route-to destination-name="DemoDestination" service-category="Test" service-name="NextService"/> </property> <property name="object-paths"> <object-path esb="body.'org.jboss.soa.esb.message.defaultEntry'" /> </property> </action>
Most of the magic here happens in ContentBasedWiretap, where the rules are executed based on the ruleSet. This looks like it will require a ContentBasedRouting component, but the one interesting part of the ContentBasedRouter is that it is making ServiceInvoker calls and looks like it will require the use of the service registry in Switchyard.
