Fucema

This is probably old news, but I still get excited thinking about all the interesting solutions that are possible now using Mule and Gigaspaces for SOA problems requiring low latency and highly scalable architectures.

Gigaspaces released 6.5 with API integration with Mule 2.0 … this is just plain awesome. You can use Gigaspaces as the transport (e.g. in place of JMS) and quickly get a SBA up and running utilizing the same concepts I used at RHG when we were servicing B2B problems. You also get the advantage of the clustering ability and fault tolerance that comes with Gigaspaces – which is just pure sex – not to mention all the other great features that come with this advanced Javaspaces implementation (i.e. management tools, monitoring tools, data partitioning, performance features like batching).

Gigaspaces would have made a fantastic backend transport and shared data grid in place of ActiveMQ JMS, but at the time it wasn’t as fully integrated with Mule. We would have been able to solve alot of the high availability and clustering concerns regarding single points of failure with the messaging database and JMS brokers. I never felt comfortable with ActiveMQ’s clustering and fail-over features. Configuration seemed a bit fussy and it doesn’t seem to be as easy to scale out as a Gigaspace cluster.

References
• GigaSpaces-Mule Enterprise Service Bus for Stateful Service-Oriented Architectures
• Middle Tier Resilience – Fault-Tolerant SOA using JavaSpaces

Google’s awesome, they release some nifty software to the open source community. Here is the link to Google’s Protocol Buffer and more details are available on Google’s Open Source Blog

From what I can tell, it’s a solid format that can replace XML in most scenarios. It’s not as easily human-readable as XML, but then again from experience not many humans are actively reading the XML anyways. The proto format reminds me of a json structure, minus the curly brackets. Also, from skimming the proto java documentation there isn’t support for primitive arrays (at least for java). You should be using List containers instead along with the proto “repeated” scalar.

They include code for data binding source .proto files to C++, Java and Python. This makes it easier to adopt in your next project. I think this is a good data format for internal use, but you’ll probably still have to deal with XML/SOAP and other RPC formats (JSON, etc) on your external interfaces. This would require transforming the internal data format (.proto) into the external format. There is also stub generating code for producing server interfaces that you can drop into your native rpc server implementations. This is pretty cool also.

Hmmm, I see some useful Mule and Camel transformers that could be made to take advantage of this new format. And possibly service adaptors for Mule and Camel too.

I’ve encountered a typo in the JMS package from Oracle while I was debugging a problem with multicast routing under Camel and Oracle AQ. It seems that Oracle may have slipped up and misnamed the “JMSXRcvTimeStamp” property as “JMSXRecvTimeStamp”. I don’t have access to the source code for the ORacle’s implementation of javax.jms.Message (AQjmsMessage), however I poked through the class file with a hexeditor and found instances of the typo.

According to the Java JMS 1.1 specification, this is a property that is set by the jms provider when a message is dequeued. The spelling of the property is listed as “JMSXRcvTimeStamp” on page 39 of the spec pdf. Oracle Streams Advanced Queuing User’s Guide and Reference 10g Release 2 document referencfes the correctly spelled property in section 11.2.2 however elsewhere in the same document it is incorrectly spelled. I’m pretty sure this is a bug in Oracle’s implementation of the Message interface. The document for Release 11g shows the same errors.

Additionally, I get the feeling that either Camel, Oracle or Spring is incorrectly setting null values for several standard JMS headers and properties when they are not assigned or not present. If null values are allowable under the JMS spec, then Oracle’s AQjmsMessage.setJMSReplyTo(Destination) should accept null parameters without exceptions also. Right now passing a null Destination value to method setJMSReplyTo(Destination) results in this exception:

oracle.jms.AQjmsException: JMS-147: Invalid ReplyTo destination type, or use of reserved `JMSReplyTo agent name, or serialization error with AQjmsDestination org.springframework.jms.UncategorizedJms

Here is the post I created in the Camel users forum relating to this issue.

Here is the JIRA issue I created for camel-jms: https://issues.apache.org/activemq/browse/CAMEL-618

Dan Diephouse (formerly of XFire, now with MuleSource) gave a presentation recently at JavaZone Norway and the PDF and MP3 are now available here.

I haven’t listened to the MP3 but the PDF had some good tidbits and gave some insight into Dan’s approach regarding RESTful services in an SOA environment. He doesn’t go into enough detail for my tastes (I like to see as much nitty gritty detail as possible) but it’s more than just a rehash of management-techno-speak so I appreciated it. There are some sections which are pretty basic (like explanation of SSL). There is also some good information about transactions and why we should approach them differently knowing some technical constraints in the HTTP protocol and stateless web communications. He briefly touches upon security issues also. All in all I wish he went into more detail, but it’s all good; another contribution to the RESTful services discussion and it’s pros/cons.

Update
Dan’s website mentioned in the PDF doesn’t seem to work (http://www.netzooidicom.com/blog).