SOA (Service Oriented Architecture) is an acronym that has been gaining in popularity over the past few years:
http://www.google.com/trends?q=soa
We're not a company to jump on the acronym bandwagon. One good reason is that there are simply too many acronyms to support, even if you are only playing in the Java playground. That's usually made quite apparent to me in the morning when I visit TheServerSide.com.
Flux has been the backbone of Service Oriented Architectures. It's nothing new. You won't find a slew of marketing acronyms scattered throughout our website though. Why not?
We focus on solutions rather than technology. This is largely driven by the KISS principle. I believe that adopting and supporting every popular Java acronym would make Flux more complex rather than easier to use.
So, how can Flux be the backbone of a Service Oriented Architecture? It's possible with the current Flux release. A lot of the enhancements coming in future releases build on the ability of the Flux engine to be the glue of a Service Oriented Architecture.
Web services can be easily invoked from a Flux flow chart, or job. The “Web Service Action” is there to meet this need. Simply point the Web Service Action to a WSDL, pass data from the flow chart to the web service, obtain the result from the web service, and store the result in the flow chart.
Being able to invoke web services (whether they are internal to your enterprise or hosted by a business partner) is one piece of the SOA puzzle. The piece is to wait for a web service to be invoked and perform a task. This is somewhat trivial. Just create a web service using your web service framework of choice (I prefer JAX-WS and Apache CXF myself) and call Flux APIs from the web service.
What Flux APIs would you likely call with from the web service? There are usually two options that satisfy most requirements. One is to simply call Engine.put() to schedule a Flux job when the web service is invoked. The other option is to publish a message to a Flux flow chart, which will then process the message from the web service.
Here's the meat of the example. Just wrap this in a web service and start designing your SOA flow charts:
// Get a Flux Factory and Engine Helper
Factory factory = Factory.makeInstance();
EngineHelper engineHelper = factory.makeEngineHelper();
// Connect to an RMI Flux engine
Engine engine = factory.lookupRmiEngine("localhost");
// Get a messaging helper and create a new MessageDefinition
MessagingHelper messagingHelper = engineHelper.makeMessagingHelper();
MessageDefinition messageDefinition = messagingHelper.makeMessageDefinition();
// Add some data to the message
Map messageProperties = <b>new</b> HashMap();
messageProperties.put("JOB_NAME", "/orderForecast");
messageProperties.put("CLIENT_ID", "112");
messageProperties.put("USER_ID", "9999");
messageDefinition.setMessageProperties(messageProperties);
// Publish the message to the Flux engine
MessageAdministrator msgAdmin = engine.getMessageAdministrator();
msgAdmin.publish(messageDefinition, "ws_publisher");
This code snippet simply publishes a message to a Flux engine. A flow chart would be designed to begin with a Flux "Message Trigger" and process the incoming message when the web service is invoked. You would likely obtain data from whoever invoked the web service and put that data into the message before publishing it. I've just used static data for illustration purposes.
This ought to be enough ideas to get you started on your own Flux-based SOA solution. I've started on some development work that could make all of this much easier, without requiring any code. If I am successful, then you will be able to satisfy all of your SOA requirements by using simple a drag-n-drop and fill in the boxes interface.
Let me know if you are interested and I can create a working example to illustrate these concepts. It's simple yet very powerful stuff!