Tom's Tech Blog

The Bus in the Clouds: A Use Case

2009-03-05T11:10:00.008-05:00

There's been a lot of noise about The Cloud. As a techie it sounds cool and, since its new, it must BE cool, right? I figured I'd take a look.

Of course there is no point in doing anything other than "Hello World" if your not trying to solve some problem. There are plenty of problems out there but, if we think of The Cloud in terms of IaaS (Infrastructure as a Service), are there any benefits that can be derived from the introduction of The Cloud into our bag of tricks?

A common SOA use case we have seen involves a scenario in which an enterprise must marshal purchase orders(or any other type of document) from various trading partners into an internal enterprise system. Essentially:

Expose network protocol based end points to get messages on to the bus
Transform incoming data to internal format
Route to the appropriate internal service
Return a response

Standard Operating Procedure
The diagram below describes the traditional approach. It uses an ESB to handle protocol translation, message transformation and routing. It has a lot of benefits in terms of flexibility and it gets the job done.

This standard approach satisfies the use case requirements but introduces a number of problems:

Security - You've just poked a hole in your firewall to allow HTTP or FTP or whateverTP traffic into your enterprise
Scalability - Is one ESB server enough? Or will success be your worst nightmare?
Availability - What if you have an outage? Will your trading partner be able to resend? How many times can you ask them to resend before they start to think you may not be worth it?
Cost - You need to buy the hardware, the space to host it, the power to run it and its got to be strong enough for peak load. During non-peak it just sits there. Doing nothing.

Consider The Cloud
We're going to look at the specifics of how the infrastructure resources exposed by Amazon Web Services(AWS) provide an opportunity to address some of these issues (and raise a few new ones).

Okay, what did we do?

Security - Trading Partners now communicate with SQS over SSL. They do not access your enterprise at all (no holes in the fire wall)
Scalability - SQS is infinitely scalable. Additional EC2 AMI instances running the ESB can be spun up on demand as volume increases. More importantly they can be stopped when load decreases(see Cost).
Availability - Redundancy across the AWS infrastructure. SQS is replicated across the infrastructure. In the unlikely event of an outage at Amazon your AMI can come up automatically at another Amazon site.
Cost - If you process orders every day from 12:00am till 2:00 then run your AMI for 2 hours and bring it down. In coming traffic will queue up on SQS till your ready for it. You only pay for what you use.

Note that many of the components in the two diagrams are identical. That's part of the beauty of the approach. While there are some nuances to the environment it is not a radical shift in paradigm with respect to the tools and development life cycle you are currently familiar with.

Conclusion
AWS and IaaS are the best thing since whatever came before sliced bread. It solves all our problems, raises no new issues and even does your laundry. We can all go golf or fish or twitter or whatever.

No.

This is a new technology. Every new technology comes with its own set of gotcha's. So we'll start a new series of articles in which we'll implement our use case and see what happens. Some of the technologies we'll be using the following are:

AWS Simple Queue Service (SQS)
AWS Elastic Cloud Computing(EC2) Amazon Machine Image(AMI)
Typica - A Java library that wraps the AWS API (Thank you David Kavanagh)
Fuse ESB(ServiceMix) 4 - The ESB
Hyperic - ESB monitoring
JMeter - Testing(our "trading partners")

In doing this I'm being helped by my friends(see list on the right) so I'll be referencing some other blogs a long the way. I hope you find it all helpful.

If You Find this Interesting
I'll be doing a presentation on it along with a full demo at the Emerging Technologies for the Enterprise conference being held in Philadelphia on March 26th and 27th. Hope to see you there.

I'm Back

2009-02-23T14:28:00.003-05:00

Okay, there seems to be a pattern here. Once a year I get the urge to blog and start spewing wisdom until I run out(usually does not take long). While my interests are still largely in the SOA area I'm finding the concept of Cloud Computing extremely compelling.

I'm going to be doing some entries on the cloud and how it relates to SOA in the near future. Specifically I'll be talking about Amazon's Simple Queue Service(SQS) and Elastic Cloud Computing(EC2) so check back. I might say something interesting.

Emerging Technologies Conference

2008-02-13T13:24:00.003-05:00

I'll be speaking at the Emerging Technologies Conference on some experiences we had with testing various ESB products in our SOA Lab. The conference is being held on March 26th and 27th at Drexel University in Philadelphia. The conference has an impressive list of sponsors and speakers so you should check it out. If you do stop by and say hello.

ServiceMix: When Things Go Wrong

2008-02-11T09:37:00.000-05:00

Okay, that was great. Everything worked. Life is good. It always is!

Yeah.

Now back to reality. We all know that things break. So what does it look like when they do. That's what we'll look at now.

In our use case we create a message that gets sent to service 1 which does some processing. The output from service 1 is sent to service 2 which also processes it. Then service 3 gets the output from service 2. Finally the output from service 3 gets routed back to the original caller. Now in light of the fact that today's topic is about things going wrong what would happen if service 2 failed? Glad you asked.

Code
We want to make sure that we get an exception. One good way to do that is to throw one. So we will add a new POJO implementation.

package com.chariotsolutions;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.servicemix.MessageExchangeListener;
import org.apache.servicemix.jbi.jaxp.SourceTransformer;
import javax.annotation.Resource;
import javax.jbi.messaging.*;

public class MyExceptionBean implements MessageExchangeListener {
@Resource
private DeliveryChannel channel;

private static final Log logger = LogFactory.getLog(MyExceptionBean.class);

public void onMessageExchange(MessageExchange exchange) throws MessagingException {
   if (exchange.getStatus() == ExchangeStatus.ACTIVE) {
       logger.debug("## Received exchange with status ACTIVE: " + exchange);
       throw new MessagingException("It Happened");
   }
   else{
       logger.debug("## Received exchange but status not ACTIVE: " + exchange);
   }
}
}

I won't bother with the line by line. If the status is active it throws an exception.

Behavior Configuration
We want our MyS2PojoService to call MyExceptionBean so that it will blow up(I feel like Gomez Adams). To do that we need to change the behavior configuration of MyS2PojoService as specified in its xbean.xml file. To do this go to:

myS2Pojo/src/main/resources/xbean.xml

Change the implementation of the myBean bean from MyPojoBean to MyExceptionBean. When your done it should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:bean="http://servicemix.apache.org/bean/1.0"
  xmlns:test="http://test">
<bean:endpoint service="test:MyS2PojoService" endpoint="myS2PojoSu" bean="#myBean"/>
<bean id="myBean" class="com.chariotsolutions.MyExceptionBean"/>
</beans>

Build the SU and SA
We have changed the behavior configuration of the myS2Pojo bean (myS2Pojo/src/main/resources/xbean.xml) so we need to rebuild its SU so go the project root for myS2Pojo and enter the following command:

mvn install

We changed an SU in our SA so the SA has to be repackaged to pick up the change. In the project root of the Sa (mySA) enter the following command:

mvn install

Now copy the SA to the ServiceMix hotdeploy directory and then start ServiceMix.

The JUnit Test Client
We're not quite ready to run the test. We need a new JUnit test client that expects an exception instead of a message. If we had one of those it would look kind of like this:

package com.chariotsolutions.test.generic;

import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.command.ActiveMQObjectMessage;
import javax.jms.*;
import javax.jbi.messaging.MessagingException;
import junit.framework.TestCase;
import org.junit.Test;

public class ExceptionResponseQActiveMqJmsTest extends TestCase {

// Test to ensure we get expected results
@Test(expected=MessagingException.class)
public void testJMSTest() throws Exception {
// Set up JMS environment
   ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
   QueueConnection queueConnection = connectionFactory.createQueueConnection();
   QueueSession queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
   Queue requestQueue = queueSession.createQueue("myJmsQueueTest");
   QueueSender queueSender = queueSession.createSender(requestQueue);
   Destination tempResponseQueue = queueSession.createTemporaryQueue();
   MessageConsumer responseMessageConsumer = queueSession.createConsumer(tempResponseQueue);

// Set up JMS requestMessage
   TextMessage msg = queueSession.createTextMessage();
   msg.setText("<text>Hello!</text>");
   msg.setJMSReplyTo(tempResponseQueue);
   msg.setJMSCorrelationID(String.valueOf(System.currentTimeMillis()));

// Print some stuff about the request
   System.out.println("#######################################");
   System.out.println("#");
   System.out.println("# About to send msg.getText(): " + msg.getText());
   System.out.println("# msg.getJMSReplyTo(): " + msg.getJMSReplyTo());
   System.out.println("# msg.getJMSCorrelationID(): " + msg.getJMSCorrelationID());
   System.out.println("#");
   System.out.println("#######################################");

// Start connection, send the message and wait for a response
   queueConnection.start();
   queueSender.send(msg, DeliveryMode.NON_PERSISTENT, 0, 100000000);
   Message responseMessage = responseMessageConsumer.receive(100000000);

// Print some stuff about the response and print it out
   System.out.println("#######################################");
   System.out.println("#");
   System.out.println("# responseMessage.getClass(): " + responseMessage.getClass());
   System.out.println("# responseMessage.getJMSDestination(): " + responseMessage.getJMSDestination());
   System.out.println("# responseMessage.getJMSCorrelationID(): " + responseMessage.getJMSCorrelationID());

// Get the TextMessage from the response
   ActiveMQObjectMessage activeMQObjectMessage = (ActiveMQObjectMessage) responseMessage;
   MessagingException messagingException = (MessagingException) activeMQObjectMessage.getObject();
   System.out.println("# messagingException.getMessage(): " + messagingException.getMessage());
   System.out.println("# messagingException.getStackTrace(): " + (messagingException.getStackTrace()[0]).toString());
   System.out.println("#");
   System.out.println("#######################################");

// Clean up after ourselves
   queueSender.close();
   queueSession.close();
   queueConnection.close();
}

}

Again, no line by line here. It is identical to the test we ran in ServiceMix: The Test Client (Part 1). The changes are in the test:

@Test(expected=MessagingException.class)

And the fact that we are expecting to get back an ActiveMQObjectMessage instead of a standard JMS TextMessage. We get the object out of that message, cast it to a MessageException and display enough to show it really is the same exception that occurred on the ServiceMix side.

Run The Client
Run the JUnit test client the via your preferred method. You should get output similar to this:

#######################################
#
# About to send msg.getText(): <text>Hello!</text>
# msg.getJMSReplyTo(): temp-queue://ID:tpurcell-15260-1202504355369-1:0:1
# msg.getJMSCorrelationID(): 1202504355780
#
#######################################
#######################################
#
# responseMessage.getClass(): class org.apache.activemq.command.ActiveMQObjectMessage
# responseMessage.getJMSDestination(): temp-queue://ID:tpurcell-15260-1202504355369-1:0:1
# responseMessage.getJMSCorrelationID(): 1202504355780
# messagingException.getMessage(): It Happened
# messagingException.getStackTrace(): com.chariotsolutions.MyExceptionBean.onMessageExchange(MyExceptionBean.java:21)
#
#######################################

Process finished with exit code 0

We FAILED! SUCCESS!!!
On the ServiceMix Side
Now lets look at the ServiceMix log. Don't worry. Not all of it. It is pretty much the same as what we saw in ServiceMix: The Test Client (Part 2) up to the point of failure. We'll pick it up from there:

DEBUG - MyExceptionBean                - ## Received exchange with status ACTIVE: InOut[
id: ID:127.0.0.2-117fad74ca4-18:3
status: Active
role: provider
service: {http://test}MyS2PojoService
endpoint: myS2PojoSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]

We pick it up as we enter our code ("##") in MyS2PojoService. At this point in the code we have not yet thrown the exception. That happens next. (Feel the anticipation?)

ERROR - BeanComponent                  - Error processing exchange InOut[
id: ID:127.0.0.2-117fad74ca4-18:3
status: Active
role: provider
service: {http://test}MyS2PojoService
endpoint: myS2PojoSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]
javax.jbi.messaging.MessagingException: It Happened
   at com.chariotsolutions.MyExceptionBean.onMessageExchange(MyExceptionBean.java:21)
   at org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:235)
   at org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211)
   at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
   at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
   at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
   at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
   at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:170)
   at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:167)
   at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
   at java.lang.Thread.run(Thread.java:595)

BOOM!!! There it goes.
Note that this is the exception object that gets serialized and sent back to our JUnit test client. That is good. We get the exception actually thrown by the application. Well, at least its good if what the exception the application throws is meaningful.

DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@be41d5 dequeued exchange: InOut[
id: ID:127.0.0.2-117fad74ca4-18:3
status: Error
role: consumer
service: {http://test}MyS2PojoService
endpoint: myS2PojoSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
error: javax.jbi.messaging.MessagingException: It Happened
]

Because of the MessageExchange state is ERROR this process is ending. In MyS2PojoService we used the MyExceptionBean which implements MessageExchangeListener. Note here that our onMessageExchange() method does not get called. This is because the status is ERROR, If its status was DONE it would be called one more time.

DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@1e91c40 dequeued exchange: InOut[
id: ID:127.0.0.2-117fad74ca4-18:2
status: Done
role: provider
service: {http://test}MyS1PojoService
endpoint: myS1PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
out: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]
DEBUG - BeanComponent                  - Received exchange: status: Done, role: provider
DEBUG - BeanComponent                  - Retrieved correlation id: ID:127.0.0.2-117fad74ca4-3:1
DEBUG - MyMessageExchangeListenerBean  - ## Received exchange but status not ACTIVE: InOut[
id: ID:127.0.0.2-117fad74ca4-18:2
status: Done
role: provider
service: {http://test}MyS1PojoService
endpoint: myS1PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
out: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]

Here we see that MyS1PojoService does get called again. This is because its MessageExchange status is DONE. Note that MyS3PojoService is not mentioned at all. It never gets called. The process stops when a fault condition occurs in the Static Routing Slip EIP.

DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@13ddbdd dequeued exchange: InOut[
id: ID:127.0.0.2-117fad74ca4-3:1
status: Error
role: consumer
service: {http://test}MyStaticRoutingSlipService
endpoint: myStaticRoutingSlipSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><text>Hello!</text>
error: javax.jbi.messaging.MessagingException: It Happened
]
DEBUG - JmsComponent                   - Received exchange: status: Error, role: consumer
DEBUG - JmsComponent                   - Retrieved correlation id: ID:127.0.0.2-117fad74ca4-3:1

The MessageExchange is now in an ERROR state. Its inMeassage was ><text>Hello!</text>. Its outMessage is a MessageException Object. It packs it up and sends it back via JMS.

DONE
There you have it, use case to implementaion, what you need to do get moving with ServiceMix. There is, of course, more. Much, much more. But that's the basics. I hope its helpful. I also hope its correct. If it isn't let me know and I'll update it.

ServiceMix: The Test Client (Part 2)

2008-02-05T15:53:00.000-05:00

Okay, last time we got the thing to run, got our output and it was what we expected. Now were going to look at the ServiceMix log and see what actually happened.

I have to say that, while what actually happened was interesting, I did not understand what actually happened. It took a little time to figure out what actually happened and I'm not quite sure I completely understand what actually happened but at any rate here is what actually happened.

Log4j
In order to see what actually happens we first have to edit the ServiceMix log4j configuration. Go to <serviceMix-home>/config and make the following additions to the log4j.xml file:

<logger name="org.apache.servicemix.jbi.messaging">
 <!-- To enable debug logging, replace the INFO by DEBUG -->
 <level value="DEBUG"/>
</logger>
<logger name="org.apache.servicemix.jms">
 <!-- To enable debug logging, replace the INFO by DEBUG -->
 <level value="DEBUG"/>
</logger>
<logger name="org.apache.servicemix.jbi.nmr.flow">
 <!-- To enable debug logging, replace the INFO by DEBUG -->
 <level value="DEBUG"/>
</logger>
 <logger name="com.chariotsolutions">
 <level value="DEBUG"/>
</logger>

Things to Remember
Review the code and remember that we have two different implementations of our POJO: MyMessageExchangeListenerBean and MyPojoBean. The difference in the way these are processed will be revealed in the log. Also note the log messages in our POJO's are prefixed with "##" to help them standout.

SEDA?
Throughout the log we'll see the term SedaFlow and SedaQueue referred to. What is SEDA? "Staged Event Driven Architecture".

Okay, what does THAT mean?

You may recall in our discussion 0f POJO 1 we talked about how the NMR uses the Delivery Channel to send messages from consumers to providers(Service Invocation). There are 4 different flow types supported by ServiceMix that define policies for how that will actually occur. SEDA is the default.

Run it (Again, again, again)
Now restart ServiceMix and then go to your IDE or command line or however you choose to run your JUnit test client and run it. When its done look at the console window where ServiceMix is running. You should see something like the following (without my comments interspersed).

What Actually Happened

DEBUG - MultiplexingConsumerProcessor  - Received jms message ActiveMQTextMessage {commandId = 7, responseRequired = true, messageId = ID:tpurcell-7873-1202
326079357-1:0:1:1:1, originalDestination = null, originalTransactionId = null, producerId = ID:tpurcell-7873-1202326079357-1:0:1:1, destination = queue://my
JmsQueueTest, transactionId = null, expiration = 0, timestamp = 1202326082926, arrival = 0, correlationId = 1202326082641, replyTo = temp-queue://ID:tpurcel
l-7873-1202326079357-1:0:1, persistent = true, type = null, priority = 4, groupID = null, groupSequence = 0, targetConsumerId = null, compressed = false, us
erID = null, content = org.apache.activemq.util.ByteSequence@43a8b8, marshalledProperties = null, dataStructure = null, redeliveryCounter = 0, size = 0, pro
perties = null, readOnlyProperties = true, readOnlyBody = true, droppable = false, text = null}
DEBUG - MultiplexingConsumerProcessor  - Handling jms message ActiveMQTextMessage {commandId = 7, responseRequired = true, messageId = ID:tpurcell-7873-1202
326079357-1:0:1:1:1, originalDestination = null, originalTransactionId = null, producerId = ID:tpurcell-7873-1202326079357-1:0:1:1, destination = queue://my
JmsQueueTest, transactionId = null, expiration = 0, timestamp = 1202326082926, arrival = 0, correlationId = 1202326082641, replyTo = temp-queue://ID:tpurcel
l-7873-1202326079357-1:0:1, persistent = true, type = null, priority = 4, groupID = null, groupSequence = 0, targetConsumerId = null, compressed = false, us
erID = null, content = org.apache.activemq.util.ByteSequence@43a8b8, marshalledProperties = null, dataStructure = null, redeliveryCounter = 0, size = 0, pro
perties = null, readOnlyProperties = true, readOnlyBody = true, droppable = false, text = null}
DEBUG - JmsComponent                   - Created correlation id: ID:127.0.0.2-117f0314f57-3:0
DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-3:0 in DeliveryChannel{servicemix-jms}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@bf989e dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-3:0
status: Active
role: provider
service: {http://test}MyStaticRoutingSlipService
endpoint: myStaticRoutingSlipSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><text>Hello!</text>
]

The JMS component that was listening to the queue got our message. Note that our message has been altered slightly. It now has encoding information.

The JMS component passed the message off to the Delivery Channel which invoked SedaFlow which enqueued our message (staged it). SedaQueue "dequeued" our message and sent it to MyStaticRoutingSlipService. We are on our way.

DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:0 in DeliveryChannel{servicemix-eip}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@1faf398 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:0
status: Active
role: provider
service: {http://test}MyS1PojoService
endpoint: myS1PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><text>Hello!</text>
]

MyStaticRoutingSlipService sent the message back to the Delivery Channel with instructions to route it to MyS1PojoService. Then SedaFlow and SedaQueue do their enqueue/dequeue thing.

DEBUG - MyMessageExchangeListenerBean  - ## Received exchange with status ACTIVE: InOut[
id: ID:127.0.0.2-117f0314f57-18:0
status: Active
role: provider
service: {http://test}MyS1PojoService
endpoint: myS1PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><text>Hello!</text>
]
DEBUG - MyMessageExchangeListenerBean  - ## In Message: <?xml version="1.0" encoding="UTF-8"?><text>Hello!</text>
DEBUG - MyMessageExchangeListenerBean  - ## Out Message: <bean1><text>Hello!</text></bean1>

For the first time we see the magic "##" which means we are in our POJO code. Specifically we are in MyS1PojoService which is implemented by MyMessageExchangeListenerBean. Note that our InOut MEP has "<text>Hello!</text>" on the inMessage and "<bean1><text>Hello!</text></bean1>" on the outMessage. So far, so good.

DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:0 in DeliveryChannel{servicemix-bean}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@9dc0a8 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:0
status: Active
role: consumer
service: {http://test}MyS1PojoService
endpoint: myS1PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
out: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]
DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:1 in DeliveryChannel{servicemix-eip}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@1f020af dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:1
status: Active
role: provider
service: {http://test}MyS2PojoService
endpoint: myS2PojoSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]

Our message got handed back to the Delivery Channel so SedaFlow enqueues and SedaQueue dequeues the message coming out of MyS1PojoService. The ServiceMix StaticRoutingSlip class has no log messages but it moved on to the next endpoint in our routing slip so we see another enqueue/dequeue which results in our MyS2PojoService being invoked.

DEBUG - MyPojoBean                     - ## Received exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:1
status: Active
role: provider
service: {http://test}MyS2PojoService
endpoint: myS2PojoSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]
DEBUG - MyPojoBean                     - ## In Message: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
DEBUG - MyPojoBean                     - ## Out Message: <bean2><bean1><text>Hello!</text></bean1></bean2>

We are in our code again. This time its MyS2PojoService implemented by MyPojoBean. Note that on the outMessage we've appended the <bean2> tags. Cool!

DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:1 in DeliveryChannel{servicemix-bean}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@11b16 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:1
status: Active
role: consumer
service: {http://test}MyS2PojoService
endpoint: myS2PojoSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><bean2><bean1><text>Hello!</text></bean1></bean2>
out: <?xml version="1.0" encoding="UTF-8"?><bean2><bean1><text>Hello!</text></bean1></bean2>
]
DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:2 in DeliveryChannel{servicemix-eip}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@9957eb dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:2
status: Active
role: provider
service: {http://test}MyS3PojoService
endpoint: myS3PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean2><bean1><text>Hello!</text></bean1></bean2>
]

MyS2PojoService->DeliveryChannel->SedaFlow->SedaQueue->MyStaticRoutingSlipService->DeliveryChannel->SedaFlow->SedaQueue->MyS3PojoService

DEBUG - MyMessageExchangeListenerBean  - ## Received exchange with status ACTIVE: InOut[
id: ID:127.0.0.2-117f0314f57-18:2
status: Active
role: provider
service: {http://test}MyS3PojoService
endpoint: myS3PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean2><bean1><text>Hello!</text></bean1></bean2>
]
DEBUG - MyMessageExchangeListenerBean  - ## In Message: <?xml version="1.0" encoding="UTF-8"?><bean2><bean1><text>Hello!</text></bean1></bean2>
DEBUG - MyMessageExchangeListenerBean  - ## Out Message: <bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>

The ball's been passed back to us. This time its MyS3PojoService implemented by MyMessageExchangeListenerBean. <bean3> tags have been added. Awesome!

DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:2 in DeliveryChannel{servicemix-bean}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@3037a0 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:2
status: Active
role: consumer
service: {http://test}MyS3PojoService
endpoint: myS3PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
out: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
]

Our final message gets sent back to the Delivery Channel.

DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-3:0 in DeliveryChannel{servicemix-eip}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:1 in DeliveryChannel{servicemix-eip}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@147e60 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:1
status: Done
role: provider
service: {http://test}MyS2PojoService
endpoint: myS2PojoSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><bean2><bean1><text>Hello!</text></bean1></bean2>
out: <?xml version="1.0" encoding="UTF-8"?><bean2><bean1><text>Hello!</text></bean1></bean2>
]

What happened there? I thought we were done with MyS2PojoService. Well, not quite. If you've really been looking at the log messages you may have noticed that each of our services actually received their own copy of the MessageExchange.

MyStaticRoutingSlipService	127.0.0.2-117f0314f57-3:0
MyS1PojoService	127.0.0.2-117f0314f57-18:0
MyS2PojoService	127.0.0.2-117f0314f57-18:1
MyS3PojoService	127.0.0.2-117f0314f57-18:2

As work on each MessageExchange is completed each is marked DONE. Then they are routed back to the DeliveryChannel. In cases where our POJO implemented MessageExchangeListener (MyS1PojoService, MyS3PojoService) the onMessageExchange() method is called and we see the "## Received exchange but status not ACTIVE" log message. For MyS2PojoService, because it does not implement MessageExchangeListener, nothing is called.

DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@17504fb dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-3:0
status: Active
role: consumer
service: {http://test}MyStaticRoutingSlipService
endpoint: myStaticRoutingSlipSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><text>Hello!</text>
out: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
]
DEBUG - JmsComponent                   - Received exchange: status: Active, role: consumer
DEBUG - JmsComponent                   - Retrieved correlation id: ID:127.0.0.2-117f0314f57-3:0

Here the MyStaticRoutingSlipService sees its ACTIVE MessageExchange for the last time. Notice the inMessage is the original "<text>Hello!</text>" sent by the JUnit test client. The outMessage is the full message as processed by all of our services.

Next the MessageExchange gets passed to the JMS component for routing back to our JUnit test client. At this point our client has its response and completes its processing. What's left is all related to the remaining MessageExchanges being marked DONE and the NMR performing processing related to that state.

DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:0 in DeliveryChannel{servicemix-eip}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@17d8938 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:0
status: Done
role: provider
service: {http://test}MyS1PojoService
endpoint: myS1PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
out: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]
DEBUG - MyMessageExchangeListenerBean  - ## Received exchange but status not ACTIVE: InOut[
id: ID:127.0.0.2-117f0314f57-18:0
status: Done
role: provider
service: {http://test}MyS1PojoService
endpoint: myS1PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
out: <?xml version="1.0" encoding="UTF-8"?><bean1><text>Hello!</text></bean1>
]

Here notice the "##" in the log messages for MyS1PojoService. We're in our code in the MyMessageExchangeListenerBean, which implements MessageExchangeListener, and our onMessageExchange() method was called.

DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-3:0 in DeliveryChannel{servicemix-jms}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@68ef48 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-3:0
status: Done
role: provider
service: {http://test}MyStaticRoutingSlipService
endpoint: myStaticRoutingSlipSu
operation: {http://test}processThis
in: <?xml version="1.0" encoding="UTF-8"?><text>Hello!</text>
out: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
]
DEBUG - DeliveryChannelImpl            - Send ID:127.0.0.2-117f0314f57-18:2 in DeliveryChannel{servicemix-eip}
DEBUG - SedaFlow                       - Called Flow send
DEBUG - SedaQueue                      - org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@1358e57 dequeued exchange: InOut[
id: ID:127.0.0.2-117f0314f57-18:2
status: Done
role: provider
service: {http://test}MyS3PojoService
endpoint: myS3PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
out: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
]
DEBUG - MyMessageExchangeListenerBean  - ## Received exchange but status not ACTIVE: InOut[
id: ID:127.0.0.2-117f0314f57-18:2
status: Done
role: provider
service: {http://test}MyS3PojoService
endpoint: myS3PojoSu
in: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
out: <?xml version="1.0" encoding="UTF-8"?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
]

Notice the "##" again. MyS3PojoService's onMessageExchange() method was called. That's it. We're DONE.

Is There Anything Left?
Well, actually quite a bit. For instance, what would happen if one of our services got an exception and failed? Next we'll alter our code a bit to make sure that occurs and we'll see, yer..., what actually happens.

ServiceMix: The Test Client (Part 1)

2008-02-04T13:27:00.000-05:00

Okay, we've done everything we need to do in ServiceMix. What we need to do now is put a message on a JMS queue so our Static Routing Slip process can process it. We'll write a JUnit test client to do that but before we start lets quickly review the use case.

The Use Case
An external system (our JUnit test client) sends a message in on a JMS queue and waits for a response on a temporary JMS queue. The JMS message is picked up by our BC (MyJmsQueueTest) which is bound to our Static Routing Slip SE (MyStaticRoutingSlipService) which routes the messge to Service 1(MyS1PojoService) which does some processing. The output from Service 1 then gets routed to to Service 2(MyS2PojoService). Then the output from Service 2 then gets routed to to Service 3(MyS3PojoService). Then, finally, the output for Service 3 gets routed back to the external system(our JUnit test client).

The Code

package com.chariotsolutions.test.generic;

import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.command.ActiveMQObjectMessage;
import javax.jms.*;
import javax.jbi.messaging.MessagingException;
import junit.framework.TestCase;

public class EchoResponseQActiveMqJmsTest extends TestCase {

    public void testJMSTest() throws Exception {
// Set up JMS environment
        ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
        QueueConnection queueConnection = connectionFactory.createQueueConnection();
        QueueSession queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
        Queue requestQueue = queueSession.createQueue("myJmsQueueTest");
        QueueSender queueSender = queueSession.createSender(requestQueue);
        Destination tempResponseQueue = queueSession.createTemporaryQueue();
        MessageConsumer responseMessageConsumer = queueSession.createConsumer(tempResponseQueue);

// Set up JMS requestMessage
        TextMessage msg = queueSession.createTextMessage();
        msg.setText("<text>Hello!</text>");
        msg.setJMSReplyTo(tempResponseQueue);
        msg.setJMSCorrelationID(String.valueOf(System.currentTimeMillis()));

// Print some stuff about the request
        System.out.println("#######################################");
        System.out.println("#");
        System.out.println("# About to send msg.getText(): " + msg.getText());
        System.out.println("# msg.getJMSReplyTo(): " + msg.getJMSReplyTo());
        System.out.println("# msg.getJMSCorrelationID(): " + msg.getJMSCorrelationID());
        System.out.println("#");
        System.out.println("#######################################");

// Start connection, send the message and wait for a response
        queueConnection.start();
        queueSender.send(msg);
        Message responseMessage = responseMessageConsumer.receive();

// Print some stuff about the response
        System.out.println("#######################################");
        System.out.println("#");
        System.out.println("# responseMessage.getClass(): " + responseMessage.getClass());
        System.out.println("# responseMessage.getJMSDestination(): " + responseMessage.getJMSDestination());
        System.out.println("# responseMessage.getJMSCorrelationID(): " + responseMessage.getJMSCorrelationID());

// Get the TextMessage from the response and print it out
        TextMessage textMessage = (TextMessage) responseMessage;

        System.out.println("# textMessage.getText(): " + textMessage.getText());
        System.out.println("#");
        System.out.println("#######################################");

// Test to ensure we get expected results
        assertEquals("<?xml version='1.0' encoding='UTF-8'?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>", textMessage.getText());

// Clean up after ourselves
        queueSender.close();
        queueSession.close();
        queueConnection.close();
    }
}

Set up JMS environment
Much of what is here is standard JMS client stuff but there are a few things worth noting. First there is the URL passed to the ActiveMQConnectionFactory. Notice this is the same value ("tcp://localhost:61616") as was set on the brokerURL attribute of the #connectionFactory inner XBean definition in our MyJmsQueueTest definition.

Also note that the value specified on the createQueue() call is the same value("myJmsQueueTest") we used for the jmsProviderDestinationName attribute of the JMS endpoint defined in MyJmsQueueTest.

Finally notice that we are asking our JMS provider to set up a temporary queue for us(Destination tempResponseQueue). We will set the "replyTo" destination on our JMS request to the value returned by this call and then we'll set up a JMS consumer to listen to it for our response.

Set up JMS requestMessage
Remember we have to send XML so we set up a real fundamental XML snippet for our little test. Then, as we mentioned above, we set the JMS reply to destination in our JMS message's header to the temporary queue that we set up for that purpose.

The last piece of business is the correlationId. Typically this field is used to ensure that the client which made a request gets the response intended for it. This is particularly important in high volume applications. If we were coding for such a scenario we would use something more certain of being unique then System.currentTimeMillis(). What we really want to see in this little demo, however, is that the value gets preserved throughout the round trip.

Print some stuff about the request
Its nice to see something happening so we'll display values prior to sending our message. But notice that we're printing out the JMS replyTo destination and correlationId. We'll print them out again when we get our response. They should be the same.

Start connection, send the message and wait for a response
Not much to say. That's what we do.

Print some stuff about the response
We print out some stuff so we get that instant gratification but also to show that the JMS replyTo destination and correlationId are what we expected.

Get the TextMessage from the response
We cast the response message to the JMS TextMessage type and display the text. It should show that each of our POJO's wrapped the original message with its bean tag.

Test to ensure we get expected results
Here we use JUnit to assert the validity of the response TextMessage.

Clean up after ourselves
Being the good citizens we are we do our part to help keep the environment clean.

Run It
First make sure your SA is deployed and ServiceMix is up and running. Then run the JUnit test client. How you do this depends on your environment. I'm running Intellij so I just created a JUnit run configuration and ran it from the IDE. Similar capabilities are available in most IDEs.

Ugh! Problems
The first time I ran the JUnit JMS client it sent the message and just stalled waiting for a response. On the ServiceMix side the process started but then stopped and displayed the following stack trace:

java.lang.NoClassDefFoundError: org/aopalliance/intercept/MethodInvocation
at org.apache.servicemix.bean.support.BeanInfo.introspect(BeanInfo.java:130)
at org.apache.servicemix.bean.support.BeanInfo.introspect(BeanInfo.java:95)
at org.apache.servicemix.bean.support.BeanInfo.introspect(BeanInfo.java:69)
at org.apache.servicemix.bean.BeanEndpoint.getBeanInfo(BeanEndpoint.java:184)
at org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:248)
at org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211)
at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:170)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:167)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)

Clearly not what we had hoped for. It turns out there was a jar file, aopalliance-1.0.jar, missing from the <servicemix-home>/lib directory. The Jira issue is SM-1216. In the mean time, where can you get it? Well if you download the ServiceMix source and build it using Maven it will get downloaded to your local Maven repository. You can also download it from SourceForge. So get it, stick it in <servicemix-home>/lib and then...

Run It (again)
Now, when you run it, you should get output similar to the following.

The Ouput

#######################################
#
# About to send msg.getText(): <text>Hello!</text>
# msg.getJMSReplyTo(): temp-queue://ID:tpurcell-16663-1202227340393-1:0:1
# msg.getJMSCorrelationID(): 1202227340826
#
#######################################
#######################################
#
# responseMessage.getClass(): class org.apache.activemq.command.ActiveMQTextMessage
# responseMessage.getJMSDestination(): temp-queue://ID:tpurcell-16663-1202227340393-1:0:1
# responseMessage.getJMSCorrelationID(): 1202227340826
# textMessage.getText(): <?xml version='1.0' encoding='UTF-8'?><bean3><bean2><bean1><text>Hello!</text></bean1></bean2></bean3>
#
#######################################

Process finished with exit code 0

So we sent our message, "<text>Hello!</text>", specified a queue to reply to and a correlationId to tie the response to our request.

The response came back on the expected queue with the expected correlationId and notice our "enhanced" message. MyS1PojoService took our message and wrapped it in its "<bean1>" tag, then MyS2PojoService wrapped that output it in its "<bean2>" tag and, finally, MyS3PojoService wrapped that output it in its "<bean3>" tag.

SUCCESS!!!

What Happened on the ServiceMix Side?
Glad you asked. We'll look at that in the next post.

ServiceMix: Deployment Configuration

2008-02-04T09:48:00.001-05:00

Now we need to package each of our SUs and then wrap them into an SA. Back in the post entitled "ServiceMix: The Use Case and What You Need to Implement It" we ran some Maven goals that generated the project structures for our SUs and SA. One of the items that got created in each project was a Maven pom.xml file. We now need to configure the poms so we can build our SUs and package the SA.They are located at:

<project_root>/pom.xml

The SUs (myJmsSu, myStaticRoutingSlip, myS1Pojo, myS2Pojo, myS3Pojo)
These are easy. The Maven archetypes did all of the important work. I made just two changes in each largely just to be neat and tidy.

<name>
The default placed here was "A custom project". I just changed the names to something more descriptive. My updates are as follows:

myJmsSu	<name>MyJmsTest :: myJmsSu</name>
myStaticRoutingSlip	<name>MyJmsTest :: myStaticRoutingSlip</name>
myS1Pojo	<name>MyJmsTest :: myS1Pojo</name>
myS2Pojo	<name>MyJmsTest :: myS2Pojo</name>
myS3Pojo	<name>MyJmsTest :: myS3Pojo</name>

<url>
This I changed in each to match that of my company:

<url>http://www.<YourCompantHere>.com</url>

The SA (mySa)
There is a little more work to do here. We start out with the same changes as we made to the SUs but then we have to add dependencies.

<name>

<name>MyJmsTest :: myJmsTestSa</name>

<url>

<url>http://www.<YourCompantHere>.com</url>

<dependency>
Remember that in the JBI world you must package your SUs into an SA in order to deploy. That means that our SA is dependent on our SUs so we have to add <dependency> entries to our SA's pom to describe that relationship to Maven. So in the SA's pom find the junit dependency entry and add the following after it:

<dependency>
   <groupId>com.chariotsolutions</groupId>
   <artifactId>myJmsSu</artifactId>
   <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
   <groupId>com.chariotsolutions</groupId>
   <artifactId>myStaticRoutingSlip</artifactId>
   <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
   <groupId>com.chariotsolutions</groupId>
   <artifactId>myS1Pojo</artifactId>
   <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
   <groupId>com.chariotsolutions</groupId>
   <artifactId>myS3Pojo</artifactId>
   <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
   <groupId>com.chariotsolutions</groupId>
   <artifactId>myS2Pojo</artifactId>
   <version>1.0-SNAPSHOT</version>
</dependency>

Build the SUs
Okay we're ready to build our SU's. In EACH SU <project_root> (myJmsSu, myStaticRoutingSlip, myS1Pojo, myS2Pojo, myS3Pojo) enter the following command:

mvn install

Build the SAs
Now we'll wrap the SUs into an SA. In the Sa <project_root> (mySA) enter the following command:

mvn install

Ugh! Problems
I made it through the SU's without a problem but when I ran the mvn install for mySa I got the following:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The service unit myS2Pojo does not have a dependency which is packaged as a jbi-component or a project property 'componentName'
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10 seconds
[INFO] Finished at: Fri Feb 01 11:36:53 GMT-05:00 2008
[INFO] Final Memory: 12M/25M
[INFO] ------------------------------------------------------------------------

Okay, what did I do wrong? Nothing. It turns out that this is a bug in the jbi-maven-plugin that comes with ServiceMix. I'm using the binary 3.2.1 distribution of ServiceMix. If you are using a different version YMMV but this is the work around recommended in ServiceMix's Jira issue SM-694. It works.

In each of the POJO poms(myS1Pojo, myS2Pojo and myS3Pojo) find the following entry:

<properties>
   <servicemix-version>3.2.1</servicemix-version>
</properties>

Add the following immediately after the <servicemix-version> entry:

    <componentName>servicemix-bean</componentName>

Now, run mvn install on for each of your POJO projects and then run mySa's mvn install again. It should end with the celebratory:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Deploy
The fruit of our labor is a deployable SA. It actually comes in two flavors: a jar file and a zip file. They are identical and you can deploy ether one simply by coping it to your <servicemix-root>/hotdeploy directory. Of course in order to do that you need to know where it is. The jar will be in your mySa project:

mySmTest/mySa/target/mySa-1.0-SNAPSHOT.jar

Maven put the zip in your local Maven repository:

/.m2/repository/com/chariotsolutions/mySa/1.0-SNAPSHOT/mySa-1.0-SNAPSHOT.zip

So copy the SA to the ServiceMix hotdeploy directory and then, if you haven't already, start ServiceMix. You should see messages indicating the success of the SA's deployment and stating "Service unit started" for each SU.

Next?
Well it is nice that we have a deployed SA that will satisfy the requirements of our use case but how do we find out if it will work? We need a client that will put messages on the JMS queue. We'll write that next.

ServiceMix: Behavior Configuration (Revisited)

2008-01-31T14:40:00.000-05:00

As noted in "The POJO (Parts 1 and 2)" implementation of the POJOs forced me to expand my understanding of what JBI and ServiceMix are all about. As a result we will have to make some minor tweaks to the behavior(xbean) configuration we set up earlier. Let's get started.

Where's the Code?
Let's first make sure where clear as to where our POJOs should be:

myS1Pojo/src/main/java/com/chariotsolutions/MyMessageExchangeListenerBean.java
myS2Pojo/src/main/java/com/chariotsolutions/MyPojoBean.java
myS3Pojo/src/main/java/com/chariotsolutions/MyMessageExchangeListenerBean.java

Yes we copied MyMessageExchangeListenerBean from myS1Pojo to myS3Pojo(remember, we'll get fancy later). The only difference between the two is in the processXML() method where the myS1Pojo copy wraps the XML in <bean1> while myS3Pojo wraps it in <bean3>.

MyJmsQueueTest
The configuration for this BC SU is located at:

myJmsSu/src/main/resources/xbean.xml

The only change is to the defaultOperation attribute. It should now be:

defaultOperation="test:processThis"

The value specified here must match the method we want to call in the MyS2PojoService POJO which is implemented by MyPojoBean. This is because that POJO does not implement the MessageExchangeListener interface. The other two POJOs, in MyS1PojoService and MyS3PojoService, are implemented by MyMessageExchangeListenerBean which does implement MessageExchangeListener. For both of them the onMessageExchange() method will get called regardless of what we specify here.

MyStaticRoutingSlipService
The configuration for this SE SU is located at:

myStaticRoutingSlip/src/main/resources/xbean.xml

Here we add an operation attribute to the definition of MyS2PojoService:

<eip:exchange-target service="test:MyS2PojoService" endpoint="myS2PojoSu" operation="test:processThis"/>

This change is, of course, related to the defaultOperation change in MyJmsQueueTest. Note that the definitions for MyS1PojoService and MyS3PojoService do not change.

MyS1PojoService and MyS3PojoService
The configuration for these SE SUs are located at:

mySnPojo/src/main/resources/xbean.xml

Where: n is the POJO number (1 or 3)

The name of the class that implements our internal xbean changed so we change it here like so:

<bean id="myBean" class="com.chariotsolutions.MyMessageExchangeListenerBean"/>

MyS2PojoService
The configuration for this SE SU is located at:

myS2Pojo/src/main/resources/xbean.xml

This internal xbean implementation also changed so:

<bean id="myBean" class="com.chariotsolutions.MyPojoBean"/>

Next Deployment
Okay, we've built our Service Unit(SU) structures, configured their behavior and built a couple of POJO services to call. Next we'll use Maven to package or SUs into an Service Assembly(SA) .

ServiceMix: The POJO (Part 2)

2008-01-31T09:36:00.000-05:00

We built a POJO and it will work (trust me). In building it, however, we implemented a ServiceMix interface, MessageExchangeListener, that ties us to ServiceMix, dictates which method will be called and forces us to deal with life cycle issues that we really have no need to deal with in our simple use case. Is there another way? Glad you asked.

Review Our POJO's Mission (again)
There's nothing new: get a message, alter it, put it back on the NMR (read BUS).

Implementation 2: MyPojoBean
The Code:

package com.chariotsolutions;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.servicemix.jbi.jaxp.SourceTransformer;
import org.apache.servicemix.jbi.jaxp.StringSource;
import org.apache.servicemix.jbi.util.MessageUtil;

import javax.annotation.Resource;
import javax.jbi.messaging.*;

public class MyPojoBean {

   @Resource
   private DeliveryChannel channel;

   private static final Log logger = LogFactory.getLog(MyPojoBean.class);

   public void processThis(MessageExchange exchange) throws MessagingException {
       logger.debug("## Received exchange: " + exchange);
       InOut inOut = (InOut) exchange;
       NormalizedMessage normalizedMessage = inOut.getInMessage();

       String outMessage = processXml(normalizedMessage);

       normalizedMessage.setContent(new StringSource(outMessage));
       MessageUtil.transferInToOut(inOut, inOut);
       channel.send(inOut);
   }

   private String processXml(NormalizedMessage normalizedMessage) throws MessagingException {
       SourceTransformer sourceTransformer = new SourceTransformer();
       String inMessage = "";

       try {
           inMessage = sourceTransformer.contentToString(normalizedMessage);
       } catch (Exception e) {
           throw new MessagingException(e);
       }
       logger.debug("## In Message: " + inMessage);

       String coreMessage = inMessage.replace("<?xml version=\"1.0\" encoding=\"UTF-8\"?>", "");
       String outMessage = "<bean2>" + coreMessage + "</bean2>";

       logger.debug("## Out Message: " + outMessage);
       return outMessage;
   }

}

Implemented Interface
Note: NONE

Annotation
We saw this in the MyMessageExchangeListenerBean implementation: @Resource Delivery. Its declaration, purpose and use are exactly the same in this implementation.

The Operation
Note our method name: processThis(). It could be anything we like. I liked processThs(). We will see how the JBI container will know which method to call when we re-address the behavior configuration.

Status?
Note we are not checking. Our processThis() method will only be called once when the MessageExchange status is ACTIVE.

And All The Rest
The rest of our code is identical to the MyMessageExchangeListenerBean implementation. We:

Get the NormalizedMessage out of the inMessage of the MessageExchange
Muck with the XML
Update the contents of the NormalizedMessage
Transfer the inMessage to the outMessage on the MessageExchange
Send the MessageExchange back to the DeliveryChannel

Next?
Well we mucked about with our POJO implementation so we'll have to revisit our behavior configuration. We'll do that next.

ServiceMix: The POJO (Part 1)

2008-01-30T09:47:00.002-05:00

Before we get started let me acknowledge that there are eighty-seven different ways to do this and all of them are better than this one. For instance, we could package our POJO as a component and instead of having separate projects but that would be getting ahead of ourselves. Lets just get through getting it to work and understanding what's going on with the basics. Latter we'll get fancy.

Next the title of this entry is a lie. We all know that POJO stands for Plain Old Java Object. The ugly truth is that JBI simply does not support POJOs. It supports JBI components which must adhere to certain interface contracts that involve life cycle methods and the like. That being said requirements are terribly onerous so we'll buck up and do what needs to be done.

Finally there is the question of what kind of JBI POJO you want to implement. I have to admit I struggled with this quite a bit. We'll look at two ways to do it. They each have subtle configuration impacts and each behaves differently at runtime. I'm not sure which I'd prefer but it would probably depend on what I was trying to accomplish. At any rate we'll go through two and let you decide.

NOTE: If you've been following along you'll remember I stated earlier that "I reserve the right to swerve wildly off the road and into a ditch along the way". This is where I did exactly that. I did not fully realize the implications for behavior and configuration when I posted the "ServiceMix: Behavior Configuration" entry. There will be some small changes.

Review Our POJO's Mission
Now, what we need to do is get a message, alter it to show we did our job and then put it back on the NMR (read BUS). In our MyS?PojoService we don't care where it came form or where it is going. That is handled by our MyStaticRoutingSlipService.

Where is Our POJO
There are three services and each one has its own POJO. When we ran our Maven SU archetype to create our bean projects back in "ServiceMix: The Use Case and What You Need to Implement It" we created:

myS1Pojo/src/main/java/com/chariotsolutions/MyBean.java
myS2Pojo/src/main/java/com/chariotsolutions/MyBean.java
myS3Pojo/src/main/java/com/chariotsolutions/MyBean.java

We are going to change the names of those classes to:

myS1Pojo/src/main/java/com/chariotsolutions/MyMessageExchangeListenerBean.java
myS2Pojo/src/main/java/com/chariotsolutions/MyPojoBean.java
myS3Pojo/src/main/java/com/chariotsolutions/MyMessageExchangeListenerBean.java

I know but bare with me. We could avoid two separate implementations of MyMessageExchangeListenerBean but first of all we're dealing with basics(remember?). We'll do the fancy packaging later. Also think about what this means. Each POJO SU has its own implementation making them completely decoupled from each other. You could have different versions of the code running for different implementations.

Implementation 1: MyMessageExchangeListenerBean
This was the first type of POJO I implemented. It is the one that had the most examples on the ServiceMix servicemix-bean component page. It is also referred to as a "Being even more POJO" on the ServiceMix POJO Support page. It should be noted however that on that first page (servicemix-bean component page) there is this statement:

These POJOs are low-level POJOs: you need to understand the JBI Api and Message Exchange Patterns to correctly handle incoming exchanges.

We'll begin to see the impact of this in the code but we will really see it at run time.

Now, without further adieu, the code:

package com.chariotsolutions;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.servicemix.MessageExchangeListener;
import org.apache.servicemix.jbi.jaxp.SourceTransformer;
import org.apache.servicemix.jbi.jaxp.StringSource;
import org.apache.servicemix.jbi.util.MessageUtil;

import javax.annotation.Resource;
import javax.jbi.messaging.*;

public class MyMessageExchangeListenerBean implements MessageExchangeListener {

@Resource
private DeliveryChannel channel;

private static final Log logger = LogFactory.getLog(MyMessageExchangeListenerBean.class);

public void onMessageExchange(MessageExchange exchange) throws MessagingException {
  if (exchange.getStatus() == ExchangeStatus.ACTIVE) {
      logger.debug("## Received exchange with status ACTIVE: " + exchange);
      InOut inOut = (InOut)exchange;
      NormalizedMessage normalizedMessage = inOut.getInMessage();

      String outMessage = processXml(normalizedMessage);

      normalizedMessage.setContent(new StringSource(outMessage));
      MessageUtil.transferInToOut(inOut, inOut);
      channel.send(inOut);
  }
  else{
      logger.debug("## Received exchange but status not ACTIVE: " + exchange);
  }
}

private String processXml(NormalizedMessage normalizedMessage) throws MessagingException {
  SourceTransformer sourceTransformer = new SourceTransformer();
  String inMessage = "";

  try {
      inMessage = sourceTransformer.contentToString(normalizedMessage);
  } catch (Exception e) {
      throw new MessagingException(e);
  }
  logger.debug("## In Message: " + inMessage);

  String coreMessage = inMessage.replace("<?xml version=\"1.0\" encoding=\"UTF-8\"?>", "")    
  String outMessage = "<bean1>" + coreMessage + "</bean1>";

  logger.debug("## Out Message: " + outMessage);
  return outMessage;
}

}

Implemented Interface
Now let's go through it. The first thing to notice is we're implementing a ServiceMix interface: MessageExchangeListener. We use a few other ServiceMix classes but only because they provide some conveniences(which we will point out). MessageExchangeListener is the only one that ties us permanently to the ServiceMix JBI implementation. Using it means our "Service" would not be deployable to an other JBI implementaion (OpenESB for instance). However given the ServiceMix comment sited earlier about this being a "low-level POJO" there may be cases where you might want to use it.

Annotation
The next thing you will notice is the annotation @Resource. This provides an injection point for the container to provide a reference to the DeliveryChannel. We'll use this to put the message back on the NMR later.

In the plumbing of our NMR the DeliveryChannel is the actual pipeline across which service consumers request services from service providers. A consumer performs a Service Invocation by placing a Message Exchange on the Delivery Channel. The provider service is invoked when the NMR routes the Message Exchange over the Delivery Channel to that service.

The Operation
Note our method name: onMessageExchange(). You may recall that when we configured our "MyJmsQueueTest" BC SU we included the setting: defaultOperation="test:onMessage". Well like I said I swerved into a ditch.

As it turns out defaultOperation is the operation that will get called unless you implement the MessageExchangeListener interface. If you implement this interface, which I did here, the defaultOperation setting is ignored and the onMessageExchange() method is the one that gets called.

My code worked even though my setting did not match my method name. That bothered me. What I found was that the in the servicemix-bean component, in the class BeanEndpoint, the type of the bean is checked (instanceof MessageExchangeListener). If its a MessageExchangeListener then OnMessageExchange() is called, end of story. This is true whether the bean is a provider or a consumer of a service. In "The POJO (Part 2)" we'll find out how to get around this.

Status?
In our next line of code we check the status of the MessageExchange that was past in on the call to OnMessageExchange(). Why? Well remember again the statement about "low-level POJOS". Our POJO will get called twice: once on Service Invocation when the MessageExchange's status is ACTIVE and once after all processing completes and the MessageExchange's status is DONE. In our case we only want to manipulate the message while the MessageExchange is ACTIVE.

The Ins and Outs of the Exchange
Recalling once more our "MyJmsQueueTest" configuration, remember the setting: defaultMep="http://www.w3.org/2004/08/wsdl/in-out"? What we were telling our JBI container was that we wanted to use the "in-out" MEP. So our MessageExchange is of type InOut. This means it can hold a inMessage and an outMessage. We will take the inMessage, manipulate it and then transfer it to the outMessage before sending it on.

NormalizedMessages and XML
There is only one type of message JBI deals with and that's the NormalizedMessage. There is only one message format NormalizedMessages carry and that's XML. Okay, it can be XML with attachments, it can be XML with an XSD that describes complex types, but it must be XML. Later we will write a client to test our use case. We will put a JMS TextMessage on a JMS queue. By the time it gets to our POJO it will be wrapped in XML.

You can write a marshaler to change that but, agan, just the basics here so our POJO will have to just deal with it. That's what the processXml() method does. Here we use two of those ServiceMix convenience classes to strip out our core message and add a some graffiti to show we were here ("<beann>", "</beann>").

Update the Message
Next we change our NormalizedMessage by setting its contents to our new and improved message.

Transfer, Please
Then we use another ServiceMix convenience class, MessageUtil, to transfer the NormaizedMessage that was in the inMessage of our MessageExchange to the outMessage in our MessageExchange.

Send
Finally we send our message on its way. Remember our @Resource DeliveryChannel annotation? Well here is where we use it to send our MessageExchange back on to the DeliveryChannel to be routed by the NMR.

Now What?
Okay that's our first POJO, or POJO (Part 1). Next we'll look at a slightly different implementation that avoids the MessageExchangeListener interface and lets us control the method to be invoked.

ServiceMix: Behavior Configuration

2008-01-28T09:44:00.000-05:00

Okay, we have the skeleton of our SOA use case implementation in place but we have to configure it to make it actually work. First let's recognize that we need to do two types of configuration: behavior and deployment.

By behavior I mean configuring the JBI components in our SUs to perform their tasks. This is done in the xbean.xml file located in the /src/main/resources of each of our SUs.

By deployment I mean packaging the various SUs and their dependencies into a SA that can be deployed into our JBI container (ServiceMix). This configuration is done in the Maven pom.xml file located at the root of each SU and the SA.

We'll look at the behavior, xbean.xml, configuration first. We'll address each SU in the order they appear in our use case. So review the use case in the last post then we'll get started.

JBI
But before we do lets think about JBI. Java Business Integration is a product of JSR-208 and, as mentioned before, is the standard upon which ServiceMix is based. The standard describes a Normalized Message Router(NMR) over which components communicate via message exchanges. The NMR is, essentially, our bus. Four methods of calling a service, called Service Invocations, are required by the JBI standard. They are defined by Message Exchange Patterns(MEPs) . Service Invocations map to MEPs as follows:

Service Invocation	Message Exchange Pattern(MEP)
One-way	In-Only
Reliable One-way	Robust In-Only
Request-Response	In-Out
Request Optional-Response	In Optional-Out

Implementations are free to extend from this to implement additional MEPs but we're dealing with basics now so we'll leave it at that. Why is it important to point these out now? Well in the next step we'll define a "defaultMep".

MyJmsQueueTest
This is the entry and exit point for our process. It receives a message from the outside world and eventually sends the response back. ServiceMix comes with ActiveMq embedded so we'll use that as the host for the JMS queue. Our JMS request/response scenario will be implemented using temporary queues.

Now down to brass tacks. Our MyJmsQueueTest service is a Binding Component(BC) Service Unit(SU). The configuration XML file is located at:

myJmsSu/src/main/resources/xbean.xml

Here are the contents:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
xmlns:test="http://test"
xmlns:amq="http://activemq.org/config/1.0">
<jms:endpoint service="test:MyJmsQueueTest"
        endpoint="jmsQueue"
        targetService="test:MyStaticRoutingSlipService"
        targetEndpoint="myStaticRoutingSlipSu"
        role="consumer"
        destinationStyle="queue"
        jmsProviderDestinationName="myJmsQueueTest"
        defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
        defaultOperation="test:onMessage"
        connectionFactory="#connectionFactory"></jms:endpoint>
<amq:connectionFactory id="connectionFactory" brokerURL="tcp://localhost:61616" />
</beans>

First note the name space definitions:

xmlns:jms="http://servicemix.apache.org/jms/1.0"
This identifies the entries for the servicemix-jms component which is the JBI standard JMS BC provided by ServiceMix.
xmlns:test="http://test"
These entries are relevant to our particular use case implementation.
xmlns:amq="http://activemq.org/config/1.0"
Here we define the entries for ActiveMq.

Now let's look at each setting:

endpoint

service="test:MyJmsQueueTest"
This identifies our service on the NMR.
endpoint="jmsQueue"
This identifies the endpoint within the service. Why an endpoint? Isn't service enough? Well if we decide latter that we want to also expose our "service" via SOAP we just add a new endpoint.
targetService="test:MyStaticRoutingSlipService"
Our SU in this case is a Binding Component(BC). It is used to expose a service on our NMR to the outside world via a standard protocol. Here the "test:MyJmsQueueTest" service is being used to bind our "test:MyStaticRoutingSlipService" to a JMS queue.
targetEndpoint="myStaticRoutingSlipSu"
Remember a service can have more than one endpoint. This is the specific endpoint within our "test:MyStaticRoutingSlipService" that we want to pass our message to.
role="consumer"
Here we define our BC as a "consumer" of the inbound message. In other words it will listen to the defined JMS transport.
destinationStyle="queue"
We define the JMS destination type as a queue (as opposed to a topic).
jmsProviderDestinationName="myJmsQueueTest"
This is the name of the JMS queue our BC will listen to. Remember that we are using the version of ActiveMq that is embedded in ServiceMix as the JMS provider. In ActiveMq there is no need to configure the queue in advance of using it. If it does not exist ActiveMq will simply create it so no further configuration on the JMS provider side is reqired. This is not true of all JMS implementations (BEA for instance).
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
Here we are declaring that we want to use the Request-Response Service Invocation (In-Out MEP) defined in the JBI standard. What will happen is ServiceMix will send our eventual response to the replyTo destination, defined in the header of the incoming JMS message, using the correlation id that is also defined in the header of the incoming JMS message.
defaultOperation="test:onMessage"
This is the method to call on the target service (our POJOs).
connectionFactory="#connectionFactory"
The connection factory, defined below, that contains JMS provider specific configuration details. Note the "#". This is XBean syntax to reference an inner bean definition.

connectionFactory

id="connectionFactory"
The name referred to by the "connectionFactory" attribute of the endpoint element above. It identifies an inner bean definition with in this XBean
brokerURL="tcp://localhost:61616"
The URL for the broker. Since we are using the embedded ActiveMq that's all we need.

MyStaticRoutingSlipService
So a client puts a message on a queue and the MyJmsQueueTest BC SU picks it up and routes it to our first SE SU the MyStaticRoutingSlipService. This service is going to want to route our message to a service, wait for a response and then send that response on to the next service on our "routing slip". Our routing slip is defined in:

myStaticRoutingSlip/src/main/resources/xbean.xml

Its contents:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:eip="http://servicemix.apache.org/eip/1.0"
xmlns:test="http://test">
<eip:static-routing-slip service="test:MyStaticRoutingSlipService" endpoint="myStaticRoutingSlipSu">
<eip:targets>
<eip:exchange-target service="test:MyS1PojoService" endpoint="myS1PojoSu"/>
<eip:exchange-target service="test:MyS2PojoService" endpoint="myS2PojoSu"/>
<eip:exchange-target service="test:MyS3PojoService" endpoint="myS3PojoSu"/>
</eip:targets>
</eip:static-routing-slip>
</beans>

First the name space definitions:

xmlns:jms="http://servicemix.apache.org/eip/1.0"
This identifies the entries for the servicemix-eip component. This is the component ships with ServiceMix to support the standard set of Enterprise Integration Patterns. There appears to be a move toward deprecating this implementation in favor of the one provided by the Apache Camel effort. Camel, however, does not yet support the Routing Slip pattern so we'll use the servicemix.eip implementation for now.
xmlns:test="http://test"
Entries relevant to our particular use case implementation.

Now the meat:

static-routing-slip
The following entries simply identify our service and its only endpoint. This is the same as what was done for the MyJmsQueueTest BC SU.

service="test:MyStaticRoutingSlipService"
endpoint="myStaticRoutingSlipSu"

targets
Okay, here's the interesting part. What follows is a list of service endpoints. This is our "static-routing-slip". Each service will be called in the order in which they appear in the list with the output of the previous service.

exchange-target service="test:MyS1PojoService" endpoint="myS1PojoSu"
exchange-target service="test:MyS2PojoService" endpoint="myS2PojoSu"
exchange-target service="test:MyS3PojoService" endpoint="myS3PojoSu"

MyS1PojoService, MyS2PojoService, MyS3PojoService
Now we need to define an SE SU for each of the services in our routing slip. In our contrived example they are simple POJOs that merely add something to the incoming message to prove that they did something. We have a separate definition for each. Since they are practically identical we'll look at the configurations then discuss the entries. (Yes, there are other ways but, again, basics first then we'll get fancy).

MyS1PojoService Configuration
XBean configuration location:

myS1Pojo/src/main/resources/xbean.xml

Contents:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:bean="http://servicemix.apache.org/bean/1.0"
xmlns:test="http://test">
<bean:endpoint service="test:MyS1PojoService" endpoint="myS1PojoSu" bean="#myBean"/>
<bean id="myBean" class="com.chariotsolutions.MyBean"/>
</beans>

MyS2PojoService Configuration
XBean configuration location:

myS2Pojo/src/main/resources/xbean.xml

Contents:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:bean="http://servicemix.apache.org/bean/1.0"
xmlns:test="http://test">
<bean:endpoint service="test:MyS2PojoService" endpoint="myS2PojoSu" bean="#myBean"/>
<bean id="myBean" class="com.chariotsolutions.MyBean"/>
</beans>

MyS3PojoService Configuration
XBean configuration location:

myS3Pojo/src/main/resources/xbean.xml

Contents:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:bean="http://servicemix.apache.org/bean/1.0"
xmlns:test="http://test">
<bean:endpoint service="test:MyS3PojoService" endpoint="myS3PojoSu" bean="#myBean"/>
<bean id="myBean" class="com.chariotsolutions.MyBean"/>
</beans>

Now lets look at the details. First the name spaces:

xmlns:bean="http://servicemix.apache.org/bean/1.0"
These entries are for the servicemix-bean component. This component ships with ServiceMix to provide for the integration of POJOs into the JBI container. We can think of them as Message Driven Pojos (MDP) similar, in concept at least, to J2EE's Message Driven Beans(MDB).
Note: The servicemix-jsr181 SE also provides POJO support by exposing the POJO as a web service (CXF).
xmlns:test="http://test"
Entries relevant to our particular use case implementation.

Now the meat:

endpoint

service="test:MySnPojoService" endpoint="mySnPojoSu"
These should be familiar by now. They identify our service and its only endpoint.
bean="#myBean"
Here we use XBean syntax (remember # from the MyJmsQueueTest SU?) to reference an inner bean definition that describes our POJO.

bean
This is the inner bean definition that describes our POJO.

id="myBean"
A name to reference it by.
class="com.chariotsolutions.MyBean"
The fully qualified name of our POJO.

Okay, we have finished configuring the behavior of our BC (MyJmsQueueTest) and SE (MyStaticRoutingSlipService, MyS1PojoService, MyS2PojoService and MyS3PojoService) SUs. They will have to be packaged in a Service Assembly(SA) before we can deploy. Before we get to that, however, there is one more thing to consider. Our POJO, com.chariotsolutions.MyBean, where did that come from? We'll look at that next.

ServiceMix: The Use Case and What You Need to Implement It

2008-01-25T11:56:00.001-05:00

Okay, so I have some basic understanding of what the JBI Components are and how to package them up. Now, can I actually do anything. We'll see. First I'll lay out a use case. Then I'll try to implement it.

The Use Case
An external system sends a message in on a JMS queue and waits for a response on a temporary JMS queue. The message gets routed to Service 1(S1) which does some processing. The output from S1 then gets routed to to Service 2(S2). Then the output from S2 then gets routed to to Service 3(S3). Then, finally, the output for S3 gets routed back to the external system via a temporary JMS queue.

Okay so looking at this it looks like a match for the Static Routing Slip Enterprise Integration Pattern(EIP). It appears that Camel is the preferred EIP implementation but it does not yet support the Static Routing Slip pattern while servicemix-eip does so we'll go with it.

The Components
The next question is what components do we actually need? Lets go throught the use case and make a list:

A JMS Service Unit(SU) to act as a Binding Component(BC) and provide the protocol translation required to get the message on to the Normalized Message Router(NMR). We'll use servicemix-jms.
A Static Routng Slip SU to control the flow of our message through the NMR. To do this we'll use the Service Engine(SE) servicemix-eip.
A SU for each of our services (S1, S2 and S3). If we were going to talk to real external services we would need a BC SU for each that described the protocol for communication with each of the services. In this case, however, we are going to keep it simple just to demonstrate what we want to accomplish. We will use a simple POJO implementation. Our POJO will simply append some text to the input message to demonstrate that the message has been acted upon by each service in order. The POJOs will be SE components. No BC component is needed for them because they are hosted on the NMR.
Finally there will be a Service Assembly (SA) which pulls all this together into a deployable unit.

Configuration Strategy
Now how do we need configure ServiceMix? Well there's the old static method using servicemix.xml and the new JBI method. The JBI method has several advantages. First, each SA is independent and hot deployable. An other is that the JBI method seems far more JBI compliant. Finally, it seems that the static method, while not deprecated, is certainly falling from favor. We'll go with the new JBI strategy.

Get The Stuff
Okay, we're clicking along pretty good here but hold on. We need a few things before we move any further. We need, if we haven't already, to download and install:

Maven - I'm using version 2.0.8
ServiceMix - I'm using version 3.2.1

Let's Get Started
ServiceMix comes with a number of Maven archetypes which automatically construct the structure of the various types of ServiceMix projects you may need to work with. This is what the Fuse version of Eclipse is doing under the cover when you're clicking through the tutorial. Doing it this way, however, forced me to realize what was happening instead of just going along for the ride. I guess its a question of learning styles and what works for you. At any rate this worked for me (or at least I think it did).

We're going to be working from the command line. For me that means a Linux shell. If you're on windows it should be rather easy to adjust.

Housekeeping
- Create a directory

tpurcell@tpurcell:/data> mkdir mySmTest

- Add Maven to our path

tpurcell@tpurcell:/data> export PATH=/data/apache-maven-2.0.8/bin/:$PATH

- Add ServiceMix to our path

tpurcell@tpurcell:/data> export PATH=/data/apache-servicemix-3.2.1/bin/:$PATH

Create Our SU Projects
- We need to create the SU project for our JMS SU using the Maven archetype for the servicemix-jms BC.

tpurcell@tpurcell:/data/mySmTest> smx-arch su jms-consumer -DgroupId=com.chariotsolutions -DartifactId=myJmsSu

- Now our Static Routng Slip SU. We're going to use the using the Maven archetype for the Service Engine(SE) servicemix-eip

tpurcell@tpurcell:/data/mySmTest> smx-arch su eip -DgroupId=com.chariotsolutions -DartifactId=myStaticRoutingSlip

- Next we create a SU for each of our POJO services using the Maven archetype for the servicemix-bean SE

tpurcell@tpurcell:/data/mySmTest> smx-arch su bean -DgroupId=com.chariotsolutions -DartifactId=myS1Pojo
tpurcell@tpurcell:/data/mySmTest> smx-arch su bean -DgroupId=com.chariotsolutions -DartifactId=myS2Pojo
tpurcell@tpurcell:/data/mySmTest> smx-arch su bean -DgroupId=com.chariotsolutions -DartifactId=myS3Pojo

Okay this is where we are at. We found the JBI components, BCs and SEs, we need to perform tasks. They need to be configured to behave so we wrap their configuration into SUs. We just created all SU projects for each of our JBI Components so we have a place to define and build their configuration. But we still have to be pull them all together into a SA so they can be deployed. So...

Create Our SA Project
- Finally we create our SA:

tpurcell@tpurcell:/data/mySmTest> smx-arch sa -DgroupId=com.chariotsolutions -DartifactId=mySa

What Have We Got?
We have a directory structure with some template Java classes and XML files and it all looks like this:
-myJmsSu/
--pom.xml
--src/
---main/
----resources/
-----xbean.xml
-myS1Pojo/
--pom.xml
--src/
---main/
----java/
-----com/
------chariotsolutions/
-------MyBean.java
----resources/
-----xbean.xml
-myS2Pojo/
--pom.xml
--src/
---main/
----java/
-----com/
------chariotsolutions/
-------MyBean.java
----resources/
-----xbean.xml
-myS3Pojo/
--pom.xml
--src/
---main/
----java/
-----com/
------chariotsolutions/
-------MyBean.java
----resources/
-----xbean.xml
-mySa/
--pom.xml
-myStaticRoutingSlip/
--pom.xml
--src/
---main/
----resources/
-----xbean.xml

This gives us a structure for the required components but now we have to configure and package them in order to create a solution for our use case. We'll tackle that next.

ServiceMix: What I Did Not Understand

2008-01-24T09:24:00.000-05:00

JBI. That's what I did not understand. Now this will not be "Everything You Ever Wanted to Know About JBI But Were Afraid To Ask" but ServiceMix is a JBI implementation. If you don't understand some of the basic building blocks of that spec you will likely get lost. I know I did. So lets look at the basic basics.

In JBI land there is a Normalized Message Router(NMR). This is your "BUS". It is the conduit over which JBI Components communicate. We'll talk more about how they communicate at a later date. For now lets stick with the components.

JBI Components? Yes, there are two types of JBI Components:

Binding Component(BC)
These expose a service on your bus (NMR) to the outside world via some standard protocol (HTTP (servicemix-http), JMS (servicemix-jms), FTP (servicemix-ftp), etc)
Service Engine(SE)
These components do work. This is where you put logic. It may be a POJO you write or a rules engine (servicemix-drools) or a third party standard JBI component that provides BPEL support (ODE).

And then there is the Service Unit(SU). This threw me. I understood the first two but I started to get lost in talk about Service Unit(SU) and Service Assembly(SA) and is a BC a SU or an SA and where does the SE come in and is that a JBI Component and who's on first and what's on second and... You get the point.

Okay, so we do not get confused lets start over on the Service Unit.

We've mentioned some BCs (servicemix-http, servicemix-jms, servicemix-ftp) and an SE (servicemix-drools). If you look in the "hotdeploy" directory of the ServiceMix install you'll see that these JBI Components are already installed. They do nothing. They are sitting there waiting to be told how to behave. In order to get them to behave the way you want them to you must configure their behavior.

Now since they are sitting there for everybody to use you don't just unpack them, configure them to your evil purposes and pack them up again. No, you create a Service Unit(SU) with your configuration. That's what an SU is. It configures the behavior you want to get out of a BC or a SE. This keeps the configuration of behavior (which JMS queue to listen to, which rule set to use) separate from the implementation of the service (servicemix-jms, servicemix-drools).

So a Service Unit(SU) packages the configuration of the behavior you want out of a JBI Component. Binding Components(BC) and Service Engines are the two types of JBI components. To use ether one you must create a Service Unit(SU) which configures their behavior.

I hope that's clear.

There is one more item: the Service Assembly(SA). What is that and why do I need it? Glad you asked.

Say we have a BC SU that defines a JMS queue to listen to and a target SE SU which is a Drools rules engine that will process the message. How does the the JBI Container know that the BC SU and the SE SU are related? It knows because they are packaged together in a Service Assembly(SA).

This is good. Say we need to change a rule or the name of the JMS queue or anything else in our little SA. We rebuild the effected SU and then rebuild and redeploy our SA. We touch nothing outside our little world. Life is good.

Okay, that's what I did not understand. Okay, there was (and is) a lot more I didn't (don't) understand but that was a big part of it. In Fuse I was clicking this and dragging that and I had no idea why. It a worked and I had no idea how. If something broke I'd have no idea what. If I had to build something from scratch I'd have no idea where to start.

Now, with some knowledge of what the building blocks are and how they fit together I feel like I can start to begin to commence to try and actually attempt to start something... kind of.

Remember Me?

2008-01-23T09:49:00.000-05:00

April, Friday the 13th, 2007 was my last entry. No, Jason did not get me, but project and personal demands combined to decapitate my spare time. That made it difficult to continue my investigation of Fuse. I apologize for the absence and hope to make a more regular appearance in the blogosphere in the future.

I also want to apologize to those at ServiceMix/Iona. I got some positive feed back from them on the entries and a request to add the content to their site but the same demands interfered with that effort. At this point Fuse is on a new release so rather than post obsolete info on their site I'll eventually try to update my efforts here. If this evolves into something useful I'll certainly make the effort to port it to their more accessible address on the web.

At any rate the project I was involved with used Mule as the ESB. There are some lessons learned there that I'll try to share in the future but I really want to get back to Fuse and ServiceMix. This is because I felt there was a lot that, while I got it to work, I just did not understand. So for the immediate future that is what I'll be doing, trying to understand.

In order to understand I will not be going through a tutorial. In tutorials you download, you click what they tell you, you enter a command and everything works. Well, as indicated with my Fuse tutorial entries, it doesn't always go that smoothly but even though I hit some bumps and figured somethings out what I learned was more about what to click then about WHY you should click it.

So this time I'm not doing a tutorial and I'm not starting with Fuse. I'm going to start with ServiceMix and my own use case and build everything from the ground up. This way the only way I can progress is to understand what I'm doing rather than mechanically moving on to the next click.

So here's the roadmap:

Okay, that's where we're going. Of course I reserve the right to swerve wildly off the road and into a ditch along the way. But, that's the point. When your sitting in the ditch, that's when you find out how to work a winch.

My Lucky Day: Iona Buys LogicBlaze

2007-04-13T20:00:00.000-04:00

Well here it is, Friday the 13th, and I just found out that, after spending the last week looking into Fuse, Iona bought LogicBlaze. What does that mean for ServiceMix? It probably increases it viability. Iona is the big company behind Celtix. Celtix now incorporates ServiceMix and ActiveMq (another LogicBlaze effort) in its stack. This is not case where we are left trying to decide what will survive. At least that is true for ServiceMix and ActiveMq but what about Fuse?

Celtix lists the Eclipse STP (SOA Tools Platform) plugins as the tooling apparatus of choice. So, is Fuse dead?

Too soon to tell and, frankly, I have not asked but my gut says Fuse will survive. It seems, from the little I know about about Fuse and STP, that they address very different areas. STP seems to be more SCA and BPEL modeling (drag and drop GUI stuff). Fuse seems to be more about JBI installation and deployment.

There is some overlap in the area of code generation but that will get resolved. At any rate it looks like Iona bought LogicBlaze more for the talent than the business. The talent likes Maven, which is the prime ingredient in Fuse, so I suspect that will stay.

Will Fuse and STP play nice together? Good question, I was wondering about that too...

Fuse Tutorial: Dumb Stuff I Did (Chapter 2)

2007-04-13T19:25:00.000-04:00

Okay, so this was dumb too, but at least I was able to figure out what I screwed up. After figuring out the first dumb mistake I ran the Maven2 install on the PricingAssembly project and got this:

[ERROR] project-execute :
    com.mycompany:PricingAssemply:jbi-service-assembly:1.0-SNAPSHOT
         (  task-segment: [install] )
Diagnosis: Missing:
----------
1) com.mycompany:PricingService:jar:1.0-SNAPSHOT

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=com.mycompany -DartifactId=PricingService \
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

Path to dependency:
1) com.mycompany:PricingAssemply:jbi-service-assembly:1.0-SNAPSHOT
2) com.mycompany:PricingService:jar:1.0-SNAPSHOT

Early in the tutorial, when I created the PricingService, I poked around and looked at the pom.xml. I noticed the groupId element had the value "com.mycompany" . I decided to get tricky and changed it to "MY" company (com.chariotsolutions) and promptly forgot about it. I did not change the groupId element on the PricingHttp project's pom and, more importantly, I used "com.mycompany" as the groupId entries for both PricingHttp and PricingService in the pom for the PricingAssemply.

This meant that my PricingService got created in the "$HOME\.m2\repository\com\chariotsolutions" directory but the Maven build for the PricingAssembly was looking for it in "$HOME\.m2\repository\com\mycompany".

So I went back to the PricingService project pom, changed "com.chariotsolutions" back to "com.mycompany", ran install on the PricingService project, ran install on the PricingAssembly project, ran publish on the server and then, finally, all was well.

Fuse Tutorial: Dumb Stuff I Did (Chapter 1)

2007-04-11T18:45:00.000-04:00

Well, nobody's perfect. In going through the "Create Contract First Web Services In Fuse" tutorial for Fuse two error conditions were raised that were probably my fault. Okay, strike that, I screwed up. I know YOU won't make these mistakes but I thought I'd share them here in case someone else screws up.

First Dumb Mistake:
On the first one I have to say I honestly do not know what went wrong. I think I followed the instructions pretty well but I did jump around a little (curiosity and the cat). If your PricingAssemply deploys and you do not get a 404 when you run the Web Service Explorer you can skip over this. Anyway this is what happened.

I made it all the way to the end of the tutorial. The Maven build said the PricingAssembly deployed. When I went to the server console (http://localhost:8080/group/fuse/servicemix) my PricingAssembly was listed in the "JBI Upload" portlet and its status was started. I went back to Eclipse and followed the instructions for launching the Web Services Explorer and testing the PricingService. This is what I got:

IWAB0135E An unexpected error has occurred.
404
Not Found

Well, that's not good. I checked the server logs and found nothing. Checked all my source files and found nothing. I started to, being a Java kind of guy, check my jar files and realized I was looking in the wrong place.

ServiceMix, and ergo Fuse, is a JBI container. A JBI Service Assembly gets deployed as a zip file. Where's my PricingAssembly zip file? Its not in my Eclipse workspace. Its not in the hotdeploy directory under my Fuse server. Wait a minute, its in my "home" directory. In windows that means:

C:\Documents and Settings\<yourIdHere>\.m2\repository\
    com\mycompany\PricingAssemply\1.0-SNAPSHOT\
         PricingAssemply-1.0-SNAPSHOT.zip

I was a little surprised to see it there but, okay, whatever...

According to JBI spec, and what we did in the tutorial, there ought to be two zips inside my Service Assembly zip: PricingHttp (binding component) and PricingService (service engine). When I checked PricingAssemply-1.0-SNAPSHOT.zip, however, there were no zips. There was a pom.xml and it had the following in the dependencies element:

<dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>3.8.1</version>
   <scope>test</scope>
</dependency>

That is not what I had in my source. Remember that in creating the PricingAssembly project we were instructed to add the PricingHttp and PricingService as dependencies and to take Junit out. That's what I did. My pom.xml looked like this:

<dependency>
   <groupId>com.mycompany</groupId>
   <artifactId>PricingHttp</artifactId>
   <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
   <groupId>com.mycompany</groupId>
   <artifactId>PricingService</artifactId>
   <version>1.0-SNAPSHOT</version>
</dependency>

Somewhere along the line I must have done something out of order and deployed the PricingAssembly before making the change. Anyway, I needed to redeploy?

Redeploy With Maven:
I found it a little difficult to figure out exactly how to get Maven to really redeploy. And, in fact, it doesn't. What you want in the end is to rebuild and redeploy the "1.0-SNAPSHOT\PricingAssemply-1.0-SNAPSHOT.zip" that is in your windows home directory (C:\Documents and Settings\... See above).

The Maven "Clean" phase does not help. It will "clean" out what is in your Eclipse workspace but the zip you want to rebuild is in your your windows home directory. There are a number of other phases exposed through the IDE (test, generate sources, etc) however, the ones that looked most promising were build and install. So I gave them a whirl.

Guess what, they both do the same thing. Launch either one and this is what you'll see:

[INFO] -------------------------------
[INFO] Building A custom project
[INFO]    task-segment: [install]
[INFO] -------------------------------

Which is okay because they do most of what you want. They rebuild the "1.0-SNAPSHOT\PricingAssemply-1.0-SNAPSHOT.zip". They do not, however, redeploy.

After you run one of them you'll notice that your server's state in Eclipse is "Republish". Right click on the server and select "Publish". There you go. Your brand new "1.0-SNAPSHOT\PricingAssemply-1.0-SNAPSHOT.zip" is up and running.

Unless, of course, you made the other dumb mistake I made. More on that in the next post.

Code Display Apologies

2007-04-10T13:39:00.000-04:00

If you've been following this blog for a while you've probably realised that I've blogging for less than a week. I'm trying to get used to the constraints of what can be displayed. If your just ranting about your neighbor's barking dog then the text formatting that is available here is just fine. If, on the other hand, you are trying to show an excerpt from a log or an XML snippet or something where line wraps or a missing </ mean something, well, its a bit challenging.

I've tried using <pre> tags and fiddled with fonts but I'm still not happy with the result. I will say it comes out a little better in IE then FireFox but that's not great since I prefer Linux.

Well that's the end of my format rant for now. I promise I'll try to get better with the code stuff.

Now, about that dog...

LogicBlaze Fuse (ServiceMix): Tutorial 1

2007-04-09T15:22:00.000-04:00

When you launch the Fuse IDE (another Eclipse with plug-ins) for the first time you get an Eclipse "Welcome" window. One of the choices is "Tutorials". Seemed like a good choice.

I decided to start with the "Create Contract First Web Services In Fuse". This launches a Macromedia Captivate presentation (pretty slick). So I made some popcorn, grabbed my dollar store headphones and followed along.

It became apparent pretty quickly that things were a little out of sync. It appears the presentation was done using an older version (1.2?) than what I was running (1.3). Its okay. I got through it but there were some differences that needed some figuring out. The following list details what they were and how I got around them:

When creating the first project you are instructed to select a "JSR-181 Service based on WSDL" project from the "New Project" wizard. That selection does not exist in the 1.3 version of the Fuse IDE. Choose "Contract First Service" instead.

In creating the WSDL you are instructed to add a "getPrice" method. In the presentation the service Input changes to "getPriceRequest" and the Output changes to "getPriceResponse". In my IDE the Output changed to "getPriceResponse" but the Input changed to "getPrice". The difference had no long term effect on the assembly or running of the tutorial but it did cause me to stop and scratch my head for a bit. Clearly I did something wrong. I did not. Neither did you.

The next thing really got me. When the WSDL is done and its time to generate source the presentation moves really quick and its difficult to see exactly what gets clicked. The presenter right clicks on the PricingService project , goes down to the "Build Phase" menu item and selects "generate-sources". In Fuse IDE 1.3 "Build Phase", and therefore its sub-selections, do not exist. Instead of "Build Phase" select "Run As". Then select "Maven2 generate sources".

Shortly after that you run into another menu issue. You're told you need to "Synchronize with Maven" after you create a folder named "java". There is no "Synchronize with Maven" in the menu. I could not figure out what to do so I went into the pom.xml for the project and added the following to the resources element:

<resource>
<directory>src/main/java</directory>
</resource>

Things go pretty well up until you finish creating the PricingHttp consumer. There you'll run into another descrepacncy in the Maven2 implementation. You are instructed to select a project, right click, go down the list of actions to "Build Phase" and select "install". Instead, select the project, go down the list of actions to "Run As" and select "Maven2 install". As instructed do this for both the PricingHttp and the PricingService projects.

In running the install on the PricingService project I got some ugly build errors:
```
Unable to locate the Javac Compiler in:
C:\Program Files\Java\jre1.5.0_06\..\lib\tools.jar Please ensure you are using JDK 1.4 or above and...
```
Note the "jre". I'm running the standard Sun 1.5.0_6 JDK. There is no "tools.jar in the "jre" but there is one in the JDK. So, in Eclipse, I went to Windows, Preferences, Java, Installed JREs and added the "jdk1.5.0_6" by navigating to "C:\Program Files\Java\jdk1.5.0_06". I reran the "Run As", "Maven2 install" and all was well.

One last issue popped up: deployment failed. This is what I saw in the projectDeply console:

[INFO] PricingAssemply is not deployed
[INFO] Deploying jbi-service-assembly from C:\Documents and Settings\tom\.m2\repository\com\mycompany\PricingAssemply\1.0-SNAPSHOT\PricingAssemply-1.0-SNAPSHOT.zip
[ERROR] mojo-execute : jbi:projectDeploy
Diagnosis: Unable to deploy project, Error accessing ServiceMix administration
FATAL ERROR: Error executing Maven for a project
[ERROR] project-execute : com.mycompany:PricingAssemply:jbi-service-assembly:1.0-SNAPSHOT (  task-segment: [jbi:projectDeploy] )
Diagnosis: Unable to deploy project, Error accessing ServiceMix administration
FATAL ERROR: Error executing Maven for a project

I wasn't sure that was helpful so I went to the server console and found a pretty long stack trace with xml snippets and IllegalArgumaentExceptions and all kinds of other nastyness but I'll cut to the chase. Here was the important part:

Caused by: java.net.URISyntaxException: Illegal character
  in path at index 16: file:/C:/Program Files/FUSE-1.3.0/FUSE-1.3.0/data/s....

We don't need the whole line because if we count to 16 we find out the "Illegal character" is the <space> in "Program<space>Files" of the windows directory where the Fuse install placed the server. I copied the entire "FUSE-1.3.0" directory structure up one level (so that "Program Files" was no longer part of the path) and from that point on it was smooth sailing.

Well, almost smooth. I did some dumb things along the way that caused some consternation. The dumb things I did and what I learned from them will be my next topic.

LogicBlaze Fuse (ServiceMix): Get and Install

2007-04-08T11:38:00.000-04:00

Fuse has been put together by our friends at LogicBlaze. It is a packaging of several open source initiatives (ServiceMix, ActiveMQ, etc) and is itself open source. It addresses an area that has been lagging up until now in the open source SOA offerings namely tooling. Before we get started let me point out that there is a very active ServiceMix community. It appears that their user forum is the appropriate place to seek help. Now lets take a look at Fuse.

Get It:
First you need to know that you must download two pieces for Fuse:

The server: http://www.logicblaze.com/content/view/63/81/
The IDE: http://www.logicblaze.com/content/view/88/151/

Install the Server:
My development platform is a Dell Inspiron 6000 running Suse Linux 10.1. So, naturally, I downloaded the Linux installs. First hurdle: the install bombed. This is not an "untar and cd to bin" install but an actual install process. I tried all of the Linux installs and all resulted in something similar to the following:

Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
awk: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/bin/ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
hostname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

Launching installer...

grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/tmp/install.dir.21727/Linux/resource/jre/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

Not what I was hoping for so I posted the problem on the forum and moved on. I have access to a Windows machine (ugh!) so I remote desk topped to it, downloaded the FUSE-1.3_win.exe and ran it. This worked flawlessly and installed the server.

I guess I should say right now that it probably is not totally correct to call it "The Server". What you are really installing is a Jetty server configured to run Fuse. You can also get one that will run WASCE. Presumably it will run on tomcat or anything else but that's a challenge for some future date. At any rate the I now had a "server" to work with, on to the IDE.

And Then the IDE:
The IDE IS an "untar and cd" install. I was able to launch on Suse with no trouble but since I did not have a local server I decided to stick with Windows for the time being. It launched okay there too. Looks like its time to kick some tires.

Evaluate

2007-04-07T11:50:00.000-04:00

Okay so lets get started. We all know how well the "Hello World" app works in most software products. Its easy, it scales, it performs and has there ever been an app that has enjoyed more reuse than "Hello World"?

But what happened when you changed it to say "Goodbye World"? How easy was it to change? When you and your pair programing partner logged on at the same time did it scale? Did it continue to perform when you both hit enter at the same time? Could you reuse the example to do anything at all in the real world?

That's what this evaluation is going to be about. Once through the "Hello World" is the thing usable? I will go through the examples shipped with a product for two reasons. The first is that it probably is the best place to kick the tires and find out what the product's approach is.

The second is that experience indicates that examples are usually put together by some one who is intimately familiar with the product. They now you should NEVER hit the F8 key in the middle of step 13 in the process or you'll format your hard drive. So they don't. Me, on the other hand, well... you get the point.

So we'll start with the examples and I'll let you know what did not go exactly according to the script. It may be that I'm an idiot and missed something. Actually I am an IDIOT and I WILL miss something. If that's the case please comment and together, hopefully, we'll save some of our friends and colleagues some time and effort.

Once past "Hello World" we'll try some "Real World" and see how things work out when we actually use the software. This, off course, will all be subjective. As stated above I may be missing something. If I'm wrong let me know. Please don't let me go blindly along formatting hard drives. Thanks.

Day 1

2007-04-06T12:41:00.000-04:00

Okay, my current focus is Service Oriented Architecture (SOA). Of course, given the nature of IT, that could change at any moment but that's what it is right now. I'm going through an evaluation of products in this space and I'll try to share my experience here. I'll start with what I think I know so far.

First SOA is a concept and not a product. There are products that will aid in the implementation but no product will deliver SOA. I've written enough bad code in the past to know that any framework can be abused. You can construct poorly performing, smokestack applications that are brittle and inflexible in Ruby or Java or C or Rexx or PL1 or COBOL or ... (don't make me date myself).

So what is important about SOA is not the SOA "product" you chose but the architectural approach. Essentially there is really only one commandment:

Thou shalt not commit point to point.

Well, okay, its not that simple. But the point is that you need to start thinking of your applications in terms of reusable services and not as one-offs. This means establishing clean interfaces and using standard protocols. These techniques result in the elusive "loosely coupled" services that provide an IT infrastructure that is more responsive to business needs.

This sounds simple but it meets with a great deal of resistance because old habits die hard. The imperative is usually to get it done yesterday. So instead of all this highfalutin SOA stuff we wind up FTP'ing a file from IBM mainframe A to WinTel box B, cook up a script to translate EBCDIC to ASCII and then go to the bar, pat ourselves on the back and marvel at our innate abilities.

The beer flows and were all happy till the CIO sends a text messages saying we need to do the same thing again. But its UNIX box C that needs to talk to WinTel B... and its a csv file... and some missing data has to be added to it... and that's in the DEC box we've been trying to retire. Ssh, what a buzz-kill!

If we service enabled the apps on IBM mainframe A, WinTel box B, UNIX box C and the DEC older than dirt box we pay a price because it requires some real thought. It requires embracing some standards and technologies that have a learning curve. It requires an investment in infrastructure. And it requires adding some cycles to the development effort initially to reap efficiencies down the road.

If we are willing to pay that price, however, IBM mainframe A, WinTel box B, UNIX box C and the DEC older than dirt box are then all exposed via standard protocols as services on a message bus. Then, when we swap out the DEC older than dirt box for an app on our slick new Linux machine, no one needs to know. As long as the interfaces are honored we're good. If the CTO and CFO dream up some new scheme we can just bang out some BPEL and go back to the bar.

Well, that's the promise of SOA. Lets see how it works out.

My Picture (A Work In Progress)

2007-02-28T12:35:00.000-05:00