Brian,
I did some JCAPS2Camel conversions:
The mapping in JCAPS/ICAN can be either XSLT or jcd. XSLT is trivial to migrate
to Camel. I will not detail this here.
jcd-style mapping works usually as follows (pseudocode):
receive()
unmarshal source format
target.fieldX.set(source.fieldY.get())
….
marshal target format
send()
so it´s basically what you sketched out
below+unmarshalling+getters+setters+marshalling. This can almost literally be
translated to Camel. You could put most of your jcd into a bean and do the rest
(from+to+all the EIP goodies) with a DSL of your choice.
I would *not* stick with the OTDs (even if that should be possible somehow) but
rather re-do them new (with BeanIo). I had some issues (multi-byte characters)
with Bindy.
The file-component is much more elegant to use in Camel, it´s much easier, more
concise, more powerful as the file eway.
One gotcha: With jdbc/sql you have to limit the field-length in Camel yourself
(OTDs do this for you)
JMS can be bridged from JCAPS-STCMS to ActiveMQ so you can make a smooth
transition fitting your time-frame.
Webservices are (just my personal opinion) a bit easier to get along with in
JCAPS, the learning curve for CXF is -uhmm- steep. If you know your 2-3 tricks
it should be easy&straightforward.
FTP-component is great, too. So no problems there.
There are a lot more choices (DSL, container, etc.) in Camel. I personally like
blueprint+Karaf. When you compare a route deployed to Karaf to an .ear file
deployed to Glassfish you see the following things:
-) startup/shutdown a *lot* faster
-) much less memory (like 150 mega compared to 1 giga for the exact same
functionality)
-) less CPU usage
-) build much faster
-) deploy much faster
-) config changes much easier
There are many other features (clustering/fabric/cloud, up-to-date IDE,
JMX-monitoring,webconsole, hawtio,…) worth exploring and the development-cycle
is lightning fast.
JCAPS/ICAN was 1990, Camel is 2005
cons: a lot to learn, sometimes frustration with the documentation
pros: access to source (!), extremely flexible and advanced architecture,
fantastic support for testing
Bottom line: just do it (if no management interferes). If you can get help,
your learning curve can be flattened a bit.
Hope this helps, Thomas.
Am 24.04.2013 um 09:44 schrieb Fitzcaraldo <brian.fitzger...@marlo.com.au>:
> All endpoints are either FTP, JMS, WS or JDBC so it is well within what Camel
> can do. JCAPS models messages as Object Type Definitions (OTD) and these
> are all XSDs or CSVs and so can be converted easily.
>
> The JCAPS equivalent of a Camel route is a JCD class. Here's an example that
> writes an incoming string to a file and a queue:
>
> public class Collaboration_1
> {
> public com.stc.codegen.logger.Logger logger;
> public com.stc.codegen.alerter.Alerter alerter;
> public com.stc.codegen.util.CollaborationContext collabContext;
> public com.stc.codegen.util.TypeConverter typeConverter;
>
> public void receive( com.stc.connector.appconn.file.FileTextMessage
> input,
> com.stc.connector.appconn.file.FileApplication FileClient_1,
> com.stc.connectors.jms.JMS JMS_1,employees.EmployeesOTD Employees_1 )
> throws Throwable
> {
> com.stc.connectors.jms.Message msg = JMS_1.createTextMessage(
> input.getText() );
>
> employees.EMPLOYEES emp = Employees_1.getEMPLOYEES();
>
> JMS_1.send( msg );
>
> FileClient_1.setText( input.getText() );
>
> FileClient_1.write();
> }
> }
>
> I haven't yet been able to find an example of format conversion but assume
> it uses XSLT or Java object mapping (anyone know?).
>
> I was hoping someone might have been down this path before and would be
> prepared to share their experiences.
>
> Thanks
>
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/JCAPS-to-Camel-tp5731389p5731404.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
