Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Looks like I need to setup a new Java environment for some interfaces we need to build.

Say our system is X and we need to interfaces to systems A, B and C. Then we will be writing interfaces X-A, X-B, X-C. Our system has a bus within it, so the publishing on our side will be to the bus and the interface processes will be taking from the bus and mapping to the destination system.

Its for a vendor based system - so most of the core code we can't touch.

Currently thinking we will have several processes, one per interface we need to do.

The question is how to structure things.

Several of the APIs we need to work with are Java based.

We could go EJB, but prefer to keep it simple, one process per interface, so that we can restart them individually.

Similarly SOA seems overkill, although I am probably mixing my thoughts about implementations of it compared to the concepts behind it...

Currently thinking that something Spring based is the way to go. In true, "leverage a new tech if possible"-style, I am thinking maybe we can shoe horn some jruby into this, perhaps to make the APIs more readable, perhaps event-machine-like and to make the interface code more business-friendly, perhaps even storing the mapping code in the DB, as ruby snippets that get mixed in... but thats an aside...

So, any comments/thoughts on the Spring approach - anything more up-to-date/relevant these days.

EDIT: Looking a JRuby further, I am tempted to write it fully in JRuby... in which case do we need any frameworks at all, perhaps some gems to make things clearer...

Thanks in advance, Chris

share|improve this question
"one process per interface"? What? You'll have to define "interface" in a way that "one process per interface" makes sense. Is this just a SOA? Why aren't you using an established SOA framework? –  S.Lott Feb 11 '11 at 10:54
Have you looked at JCA? That's the canonical Java-based system integration approach. –  TMN Feb 17 '11 at 19:21
@TMN - thanks, JCA sounds like something I should be wrapping around the specific communications - stackoverflow.com/questions/4157776/use-cases-for-jca/… –  Chris Kimpton Feb 18 '11 at 7:40
add comment

1 Answer

up vote 2 down vote accepted

Your description of the problem sounds like a job for JMS (Java Messaging System). Essentially your application sends the proper message to the JMS queue, and you can configure the queue to route the message wherever you want--even across processes.

Essentially A, B, and C would each have their own JMS client. The JMS client reads the message and performs its processing. It then sends the response message in the format that your application desires. NOTE: this is completely asynchronous so it will scale as needed. The beauty of this solution is that you can scale up by having multiple A systems or B systems, and the JMS queue would load balance between the available targets.

Your X system defines what the messages look like, and what messages it is expecting. If you can get away with making the messages for A, B, and C identical, the only thing you need to change is how you route the messages. This approach will allow you to expand by adding systems D, E, and F when the situation calls for it without having a tremendous corresponding amount of work in X.

As to using tech for the sake of tech, that is how systems become brittle and unstable. Incorporate tech when there is a clear need for it.

share|improve this answer
Thanks Berin - our core system has a "bus", which is effectively a message system with pub/sub and queuing features, so I think that helps us with the scaling side of things. As for the new tech, I am think that wrapping the business mapping logic in Ruby should mean its more succinct/user friendly.. Will probably try with/without and assess pros/cons. Also need to refresh my Java6 - maybe that helps me too :) –  Chris Kimpton Feb 18 '11 at 7:44
The internal bus you spoke of is precisely why I suggested building the interface around JMS. Additionally with JMS you get the following for free: multi-VM/server distribution of your messages, and the ability to not lose messages if someone unplugs the server. You don't have to rip out the existing bus to incorporate it. Just add a subscriber to your personal bus to move the outbound messages to JMS. It's a great fit. –  Berin Loritsch Feb 18 '11 at 11:12
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.