Announcement Announcement Module
No announcement yet.
Suggestions for Integrating Non-Java Apps Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Suggestions for Integrating Non-Java Apps

    In our enterprise most of our applications are written in Java, but a large number of them are written in other languages--particularly Cold Fusion and .NET. While I am aware SI can communicate with these applications through file exchange, I was curious if anyone here has tackled this issue yet and/or has any suggestions/best practices for how to allow messaging among these applications.


  • #2
    Web Services would be a common approach here since this is supported in most languages.

    ActiveMQ also has support for a large number of clients and protocols ActiveMQ cross language clients. This includes support for Stomp which allows a simple text + socket approach to messaging where there is no client provided.


    • #3
      I'd also suggest web services or at least an XML schema defined exchange. You can add a simple layer on all of your other applications in other languages and use XML as the transport. It makes things so much easier to debug and it allows you to plug in transformations in the future if the APIs change.

      Spring integration supports HTTP invoker and web service calls. You can use Spring-WS for more advanced web service support using your own implementations of channel adapters.

      Another option would be JMS. I believe there are connectors for other languages but I wouldn't want to be the one configuring and maintaining them.

      Yet another option would be communication through the DB through a message exchange. You could use any message format (again, think XML) and let the DB handle all the network/persistence/transactional stuff. You can find DB drivers in almost any language.



      • #4
        Thank you both for your thoughtful responses.

        Before I ever knew about SI, I was planning on taking precisely the web services approach. But after studying SI and using it to implement a fairly trivial chain that allows a Java app to make a synchronous web service call to another app as a proof of concept, I was really impressed with the way SI formalizes the Hohpe patterns even down to the nomenclature. That is why I was looking into a way that non-Java apps could take advantage of this formalization the way Java apps can.

        When I first posted, I was wondering, for example, if I could get a .NET app to talk to the web service through SI in precisely the manner described above. That way I could apply a consistent approach to all apps regardless of the platform. It seems from your responses that the answer is both of the following:
        • That I cannot use SI to do it but it's OK since a conventional web service call is a perfectly acceptable and perhaps even optimal messaging strategy
        • That maybe I could use SI if I wrote my own channel adapter

        I will also look into the other approaches you mentioned--ActiveMQ cross language clients and database messaging.

        Thanks again.


        • #5
          You may also be interested in this Spring Integration for .Net


          • #6
            Web services as an 'optimal' solution depends on your point of view. From a CPU and data point of view it is usually very much less than optimal, but the advantages gained through readability and transformability are well worth it IMHO.

            I'd still recommend using Spring Integration to hide the WS calls if that works in you architecture. This gives you the flexibility of swapping the underlying transport if needed. For example, you could start with file exchange and if that is too slow you can move to WS or DB exchanges without having to modify the Java app.

            Good luck,


            • #7
              For interoperability I would look at Spring WS. Spring integration is very expressive in implementing the patterns, but Spring WS and OXM are tools you will need to make the payload of your message interoperable.

              Of course there is some overlap, but you shouldn't expect SI to be a replacement for Spring WS. Spring Integration focusses on routing, transports and is more or less payload agnostic, where Spring WS focusses on interoperability and is more or less transport agnostic.

              If you need both the expressiveness in terms of EIP of SI and the interoperability of SWS, there is no harm in using both.


              • #8
                Whether you need to add Spring Web Services in also depends on what you mean by Web Services. If you just mean Plain Old XML over email or JMS transport then there will not be much gain since the SI XML module integrates with Spring OXM, XSLT and XPath to offer routing and transformation for XML payloads.

                If you are thinking SOAP or HTTP transport then SWS will offer a great deal of benefit.


                • #9
                  You may also want to consider messaging. Spring .NET would allow you to use the same approach on the .NET side as when you use Spring's JMS support on the Java side. Sometimes messaging is a better approach than Web Services (easy to achieve reliability etc), and it's almost always going to be a better option than file sharing - at least when the problem requires a "transport". Here is an article that you may find interesting (and the Spring .NET support has evolved considerably since this was written):


                  • #10
                    I really appreciate the thoughtful responses from everyone. I now have a lot of options to consider in terms of what is easiest to implement as well as what is the most flexible--particularly given the diversity of the applications we have. There has been a lot of .NET talk in this thread, but in our enterprise, we also have a lot of ColdFusion and a little PHP as well to go with our Java.

                    It seems to me some combination of JMS/ActiveMQ and web services will be my choice. It is nice that SI (in tandem with Spring proper and Spring .NET) offers so many ways to ease the pain.

                    Thanks again. And Happy New Year.