I will be attending the last three days of SD West 2008 next week, stuffing my brain with all the good things this conference always delivers!
Should you want to discuss NxBRE, the Mule JCR Transport or any other stuff, please shoot me an email and we will arrange a meeting.
Friday, February 29, 2008
Wednesday, February 27, 2008
Canonical Implementations
A few days ago, a colleague made a tongue-in-cheek remark about the fact that I am directly using some Spring Framework helper classes (in this case: FileCopyUtils). First, I started to wonder if this was really bad: after all, are we not we supposed to avoid direct dependency to any framework?
Then it struck me as an evidence: the Spring Framework provides canonical implementations for almost anything.
Sure, it is all bound together thanks to the dependency injection kernel. But, whether it is via direct access to helper classes or via configuration, Spring implements state of the art and rock solid implementations of most of the tricky things you want to do.
Like copying streams while handling all the checked exceptions correctly. Or reading from a JMS destination with a configurable pool of consumers. Or creating and applying aspects. Or registering MBeans. Or... whatnot...
So why writing code when you can re-use one that has been so many times read, executed and improved over the past few years?
Why not tapping this huge source of canonical implementations?
Then it struck me as an evidence: the Spring Framework provides canonical implementations for almost anything.
Sure, it is all bound together thanks to the dependency injection kernel. But, whether it is via direct access to helper classes or via configuration, Spring implements state of the art and rock solid implementations of most of the tricky things you want to do.
Like copying streams while handling all the checked exceptions correctly. Or reading from a JMS destination with a configurable pool of consumers. Or creating and applying aspects. Or registering MBeans. Or... whatnot...
So why writing code when you can re-use one that has been so many times read, executed and improved over the past few years?
Why not tapping this huge source of canonical implementations?
Happy Bus Ride
I am happy to announce the second milestone release for the version 1.1.0 of the JCR transport for Mule.
There are some new cool stuff so check the updated user guide and examples to discover what. You can also check the road map to see what is cooking for the next milestones...
Make your bus content: connect it to JCR!
UPDATED 09-FEB-2008: Version 1.1.0 is finally out!
UPDATED 27-FEB-2008: Michael Marth of Day, the company who is leading the JCR specification, has interviewed me about this transport.
There are some new cool stuff so check the updated user guide and examples to discover what. You can also check the road map to see what is cooking for the next milestones...
Make your bus content: connect it to JCR!
UPDATED 09-FEB-2008: Version 1.1.0 is finally out!
UPDATED 27-FEB-2008: Michael Marth of Day, the company who is leading the JCR specification, has interviewed me about this transport.
Friday, February 15, 2008
Pragmatic ESB Use Cases
After four years fiddling with ESBs, I thought it could be interesting to share what I have found to be pragmatic use cases for that tool. But, first, what do I mean by pragmatic?
By pragmatic, I mean free of any vendor kool-aid or SOA hype ; and driven by concrete needs instead of general fantasies of "business processology and ontological governance" (you get the picture). I also mean cases where an ESB did not feel overkill for the job and where its inherent drawbacks were acceptable compared to the features it brought.
So here are some use cases grouped by themes, with highlights of what particular virtues an ESB brings in them.
The external world outreach use case
Isolating corporate software from the pesky details of calling third party services over the internet is a very good use case for an ESB. Indeed, these services tend to have bizarre authentication schemes, IP range or access count limits and random down times. It is then worthwhile to hide these remote services behind an abstraction layer that allows developers to invoke them without having to learn about their particularities.
Consuming feeds is also another task for which it is more desirable to write configuration instead of code, something an ESB offers natively.
Reaching servers inside a DMZ with non-HTTP protocols is also another good usage for an ESB, with nodes installed in each firewalled subnet. I have talked about this before.
ESB virtues: Distributed, Content base routing, Configuration over code.
The instant legacy integration use case
Though I have been lucky enough to be spared the traditional legacy integration consulting gigs, I had to perform some stunts in the realm of instant legacy integration. This kind of software does not consider that standards carry any value, hence often opt for weird invocation protocols or communication mechanisms.
The message transformation and protocol adaptation features an ESB offer come very handy in this kind of scenario: a remote synchronous mambo-jumbo talking service can then be exposed as a SOAP or MQ one to the interested applications.
The versatility of an ESB, which allows it to come into play with various systems without having to modify them or needing them to know anything about the bus, compensates the black box middleware it can appear to be. It is in fact often desirable to keep the ugly details of talking the crazy talk of some systems in a black box to preserve the sanity of the software developers who need to use them.
ESB virtues: Message transformations, Protocol adaptation, Non invasiveness.
The fast talker use case
An interested case I was once faced with involved dealing with high performance communications alongside with a more standard database oriented web application. Even the hip J2EE application server I was using at that time was not designed to handle this kind of traffic: EJB, SOAP or CORBA were fine but not bursts of data packets over POTCPIP (Plain Old TCP/IP).
This was another good use case for an ESB, as it offered not only an excellent support for even such a low level protocol, but also the capacity to configure and manage pools of threads and components used to process the particular load of this side of the application. Acting as a "heat shield", the ESB was then analyzing, aggregating and pre-chewed data packets in messages ready to be sent to the rest of the J2EE application over standard EJB and JMS channels.
ESB virtues: Configurable behavior (threading/polling), Protocol support, Message aggregation.
Now to the real expert
So where is the "ESB in the middle of all remote service calls" use case? Well, though very satisfying for the mind, this kind of deployment very often ends up as a not so great idea. Jim Webber, who is a real expert, can explain you why.
By pragmatic, I mean free of any vendor kool-aid or SOA hype ; and driven by concrete needs instead of general fantasies of "business processology and ontological governance" (you get the picture). I also mean cases where an ESB did not feel overkill for the job and where its inherent drawbacks were acceptable compared to the features it brought.
So here are some use cases grouped by themes, with highlights of what particular virtues an ESB brings in them.
The external world outreach use case
Isolating corporate software from the pesky details of calling third party services over the internet is a very good use case for an ESB. Indeed, these services tend to have bizarre authentication schemes, IP range or access count limits and random down times. It is then worthwhile to hide these remote services behind an abstraction layer that allows developers to invoke them without having to learn about their particularities.
Consuming feeds is also another task for which it is more desirable to write configuration instead of code, something an ESB offers natively.
Reaching servers inside a DMZ with non-HTTP protocols is also another good usage for an ESB, with nodes installed in each firewalled subnet. I have talked about this before.
ESB virtues: Distributed, Content base routing, Configuration over code.
The instant legacy integration use case
Though I have been lucky enough to be spared the traditional legacy integration consulting gigs, I had to perform some stunts in the realm of instant legacy integration. This kind of software does not consider that standards carry any value, hence often opt for weird invocation protocols or communication mechanisms.
The message transformation and protocol adaptation features an ESB offer come very handy in this kind of scenario: a remote synchronous mambo-jumbo talking service can then be exposed as a SOAP or MQ one to the interested applications.
The versatility of an ESB, which allows it to come into play with various systems without having to modify them or needing them to know anything about the bus, compensates the black box middleware it can appear to be. It is in fact often desirable to keep the ugly details of talking the crazy talk of some systems in a black box to preserve the sanity of the software developers who need to use them.
ESB virtues: Message transformations, Protocol adaptation, Non invasiveness.
The fast talker use case
An interested case I was once faced with involved dealing with high performance communications alongside with a more standard database oriented web application. Even the hip J2EE application server I was using at that time was not designed to handle this kind of traffic: EJB, SOAP or CORBA were fine but not bursts of data packets over POTCPIP (Plain Old TCP/IP).
This was another good use case for an ESB, as it offered not only an excellent support for even such a low level protocol, but also the capacity to configure and manage pools of threads and components used to process the particular load of this side of the application. Acting as a "heat shield", the ESB was then analyzing, aggregating and pre-chewed data packets in messages ready to be sent to the rest of the J2EE application over standard EJB and JMS channels.
ESB virtues: Configurable behavior (threading/polling), Protocol support, Message aggregation.
Now to the real expert
So where is the "ESB in the middle of all remote service calls" use case? Well, though very satisfying for the mind, this kind of deployment very often ends up as a not so great idea. Jim Webber, who is a real expert, can explain you why.
Saturday, February 09, 2008
JCR + ESB = You Decide!
After two milestone releases, I have finally released the latest version of my JCR Transport for Mule.
If you are looking for new ways to leverage JCR, then consider this transport that allows you to benefit from Mule ESB numerous transports for integrating content repositories into your infrastructure.
If you are looking for new ways to leverage JCR, then consider this transport that allows you to benefit from Mule ESB numerous transports for integrating content repositories into your infrastructure.
Subscribe to:
Posts (Atom)