Create Weblogic JMS SAF (Store and Forward) using WLST

As a follow up to my last blog, here is a simple WLST script to automate the whole process of creating EDN specific SAF on a non-SOA Weblogic server

----------------------------------------------------------------------------------------

######################################################
# This WLST will connect to the 'local' weblogic server
# and create a remote SAF connection as mentioned below.
# It is written to create a SystemModule-0 JMS Module,
# Create two connection factories (XA and non-XA),
# RemoteContext, SAFImportedDestination
# and a remorte queue for EDN setup on a non-SOA weblogic.
# However, the script can be modified to create any JMS object.

# Make sure to edit/verify the lines at <---xxx---> comments
# to suit the environment
#######################################################

#connect('weblogic', 'welcome1', 'soabpm-vm.site:7001')
connect()

edit()

startEdit()

#Create SAF Agent
cd('/')

cmo.createSAFAgent('SAFAgent-0')

cd('/SAFAgents/SAFAgent-0')

cmo.setServiceType('Sending-only')

#JMS Module
cd('/')

cmo.createJMSSystemResource('SystemModule-0')

cd('/SystemResources/SystemModule-0')

#<-------------specify -------="" cluster="" etc.="" jms="" module="" server="" target-="" the="">
set('Targets',jarray.array([ObjectName('com.bea:Name=AdminServer,Type=Server')], ObjectName))

#Remote SAF Context
cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0')

cmo.createSAFRemoteContext('RemoteSAFContext-0')

cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/SAFRemoteContexts/RemoteSAFContext-0/SAFLoginContext/RemoteSAFContext-0')

#<----specify ------="" host="" pwd="" remote="" server="" user="">
cmo.setLoginURL('t3://soabpm-vm.site:7001')
cmo.setUsername('weblogic')
cmo.setPassword('welcome1')

cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0')

#Create EDN connection factories
#<--------specify --------="" connection="" factory="" jndi="" names="">
cmo.createConnectionFactory('EDNConnectionFactory');
cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/ConnectionFactories/EDNConnectionFactory')
cmo.setJNDIName('jms/fabric/EDNConnectionFactory')
cmo.setDefaultTargetingEnabled(true)
cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/ConnectionFactories/EDNConnectionFactory/TransactionParams/EDNConnectionFactory')
cmo.setXAConnectionFactoryEnabled(true)

cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0')
cmo.createConnectionFactory('XAEDNConnectionFactory')
cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/ConnectionFactories/XAEDNConnectionFactory')
cmo.setJNDIName('jms/fabric/xaEDNConnectionFactory1')
cmo.setDefaultTargetingEnabled(true)




cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0')

cmo.createSAFImportedDestinations('SAFImportedDestinations-0')
cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/SAFImportedDestinations/SAFImportedDestinations-0')
cmo.setSAFRemoteContext(getMBean('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/SAFRemoteContexts/RemoteSAFContext-0'))
cmo.setSAFErrorHandling(None)
cmo.setTimeToLiveDefault(0)
cmo.setUseSAFTimeToLiveDefault(false)
cmo.setDefaultTargetingEnabled(true)

#SAF Queue
cmo.createSAFQueue('SAFQueue-1')


cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/SAFImportedDestinations/SAFImportedDestinations-0/SAFQueues/SAFQueue-1')

#<---------specify configured="" currently="" edn="" for="" name.="" queue------------="" queue="" remote="" the="">
cmo.setRemoteJNDIName('jms/fabric/EDNQueue')

cmo.setNonPersistentQos('At-Least-Once')
cmo.setTimeToLiveDefault(0)
cmo.setUseSAFTimeToLiveDefault(false)
cmo.setUnitOfOrderRouting('Hash')

cd('/JMSSystemResources/SystemModule-0/JMSResource/SystemModule-0/SAFImportedDestinations/SAFImportedDestinations-0/MessageLoggingParams/SAFImportedDestinations-0')
cmo.setMessageLoggingEnabled(false)
cmo.setMessageLoggingEnabled(true)
cmo.setMessageLoggingFormat('%header%,JMSCorrelationID,JMSDeliveryMode,JMSDestination,JMSExpiration,JMSMessageID,JMSPriority,JMSRedelivered,JMSReplyTo,JMSTimestamp,JMSType,%properties%')


cd('/')


activate()
#####################################################

----------------------------------------------------------------------------------------

stocks-suggest is now on Java 6

My general depression on the stock market had put down all my excitement on stocks-suggest. This is the application i had been writing for a while that can suggest changes (BUY or SELL) on a given portfolio based on a set of rules;besides the fact that it is one of the most interesting architecture i have ever done. Here is the report from some of my past runs.


********************************************************
Report at: Tue Jan 29 11:38:02 IST 2008
********************************************************
[Report: stockName: RENUKA.NS result: BUY buyPrice: 1003.7 change: -9.700000000000045]
[Report: stockName: JPASSOCIA.NS result: BUY buyPrice: 374.5 change: -1.1999999999999886]
********************************************************
Report at: Tue Jan 29 11:44:36 IST 2008
********************************************************
[Report: stockName: RENUKA.NS result: BUY buyPrice: 1003.7 change: -11.700000000000045]
[Report: stockName: JPASSOCIA.NS result: BUY buyPrice: 374.5 change: -4.699999999999989]
********************************************************
Report at: Sun May 10 22:35:24 EDT 2009
********************************************************
No stock decisions for the moment
********************************************************




Tonight, i got it compiled successfully on Java 6. Boy, it took a lot of commitment from me to finally start on this again. Latest source is at stocks-suggest google code repo.

Drools and JibX dependencies had to be updated to the latest to get rid of the Xerces Abstract method error after migrating from Java 1.5. Here is the output of mvn eclipse:eclipse for all dependencies.

o commons-logging:commons-logging:1.1
o log4j:log4j:1.2.12
o logkit:logkit:1.0.1
o avalon-framework:avalon-framework:4.1.3
o javax.servlet:servlet-api:2.3
o junit:junit:4.4
o org.drools:drools-compiler:5.0.0.M5
o org.drools:drools-core:5.0.0.M5
o org.mvel:mvel2:2.0.6
o org.drools:drools-api:5.0.0.M5
o joda-time:joda-time:1.5.2
o org.antlr:antlr-runtime:3.1.1
o org.eclipse.jdt:core:3.4.2.v_883_R34x
o janino:janino:2.5.15
o org.jibx:jibx-extras:1.2.1
o org.jibx:jibx-run:1.2.1
o org.codehaus.woodstox:wstx-asl:3.2.1
o stax:stax-api:1.0.1
o quartz:quartz:1.5.2


I am gonna work on this for a while now. Changes i intend to do in future releases.

1. Refactor test cases
2. Change rules appropriately.
3. Load it on a Spring DM server
4. Create a UI on Webflows (Not decided on the framework. Might as well do it on something simpler like Struts also)
5. De couple reader, binder, renderer, rule engine and report generation modules and have them talk to each other on Mule bus.

RIA and Zkoss

Last week, i read an artcle on direct RIA frameworks like Zkoss. Zkoss was new for me. So, I did some googling around and here are my thoughts on RIA and the related.

Your MVC web application
In a typical MVC application, view and controller do operations for displaying a model (the view part) and handle actions (thats the controller) from views. Views are created by the server and pushed on to a client side browser as HTML.

Why AJAX?
Ajax is a way of making the client - server event based communication better. In Ajax world, a click of a button would fire an event which a client side javascript will send to the server side action class. Action does some processing based on the event and returns a response to the client side javascript. Client script knows how to deal with the response and responds by making the necessary changes in client HTML DOM.



The "BIG" difference is that with AJAX, your server communication has become "SMALL". You don't need to submit the entire client DOM to server side. Send only, what is required for that processing and change only that much on the HTML being displayed in browser. This is a big leap in user experience since user only sees some changes in his HTML file compared to the whole page reload for every action/event. With this as the backbone framework, we can now have richer web GUI controls that deals with small portions of your screen and smaller/quicker request/response to update itself.

All good. Why RIA now?
Before we start talking about RIA and Ajax together, we need to first understand them as two different approaches for solving two big web application problems:- browser/client - server communication and user experience.

Rich Internet Application frameworks have a different take on your typical MVC web application modeling. Fact is, they don't enforce on MVC at all. RIA frameworks can combine coding for view and its event handling mechanism into one physical file, like in MVC1 style. The idea is to combine server side actions (your struts actions or JPF controller) and views (in JSP, HTML, etc.) into one unit and let it access business layer or data layer directly.

Zkoss also lets you define server side event handler files as separate entities. But that definitely is not the intention with which RIAs are being developed.

The best part of RIA frameworks is that client-server communication is invisible to developer and hence the term direct AJAX. This gets rid of all the routine code for AJAX that developer needs to write.



How Zkoss does it!
Zkoss does this in 'zul' files. You need to setup a servlet listener that knows how to deal with 'zul'. As part of your setup, all you need to do is copy zkoss jars to your lib directory and modify your web.xml for Zkoss servlets.

Once this much is done, you can write zsrcipts in zul files. They currently support multiple languages including java and ruby. When you run the app on an app server, these files gets compiled into its client server versions like skeltons and stubs. Just like JSPs, zuls gets compiled into servlets.

A java zscript pretty much will look like JSP scriplets; with the difference that this time zscript is more component oriented and all process related. It is like Swing for Java. This is different in that scriplets are normally used to deal with request variables, or write some dynamic HTML.

ZKoss is not the only RIA out there. GWT from google, FLEX, Silverlight from Microsoft, etc. They all implement and stand for the same solution space.

Having said all the good things, there is one point about direct AJAX that we better be aware of before we adopt them. Since developers don't handle the real HTML and what goes between client and server, debugging in related scenarios can be very painful. However, i believe, once proven to be efficient, RIA frameworks can deliver much better user friendly applications in shorter development period.

I also believe RIA based web applications will be the winner in long term race. This, in view of all the new product trends like FLEX and Silverlight and how the market is so keen on them. Lets accept it! Tomorrow's developer demand won't be for network layer experts; but for product specialists who can quickly convert a business problem to a programed solution. The less routine and house keeping code, the more productive you are. That's when RIA frameworks can help you win.