Geeks With Blogs
Scott Lock Thoughts on .Net, and Windows Phone

We (Amercian Red Cross) recently spent several months deciding and implementing a broker for ecommerce transactions for the enterprise, lovingly name TQE or Transaction Queing Engine.  I know...I know...really original.  One thing that I am actually not taking credit for.  Basically this system allowed any application that wished to publish transactions to the broker using the correct schema process a credit card or some other finanical payment.  The first two clients for this broker are two very different applications.

The first is the Online Donation System.  This system is a .Net application with an ASP.Net front end a .Net Windows Service running in the background.  The second is a J2EE based Health and Safey Course scheduling application.  This system runs on Weblogic and communicates with our PeopleSoft implementations.  Both of these applications must send credit card transactions to TQE for processing.  TQE then makes external calls to various gateway systems for processing and internal systems for logging, etc. 

After spending a good deal of time meeting and meeting and meeting about meetings, we decided that this was the perfect fit for a service based application.  Each step in the process made sense as a service.  And that this was not your typical spoke and wheel scenario.  That each application would post messages to endpoints as necessary and not necessarily be tied into the system. 

So how do you build this thing?

That was the magic question.  We orginally went the Microsoft route with Biztalk 2004 (Early adopter program).  that had great promise and was going very well.  We had awesome support from Microsoft and our internal development team.  No worries...right?  We would have be able to leverage all the greate SOA features that BizTalk provided.  We could expand the services using Web Services and other components.  All written in any language that supports SOAP.  Sounds too good to be true...

Well, shortly after getting things rolling our Archicitecture commitee decided that BizTalk 2004 could not be used due to the fact that it was not released yet.  Don't get me started on this one.  BizTalk 2004 has been released for 4 months now and we are still not in production. 

So enter Sonic.  Sonic ESB and Sonic MQ.  If  you are not familiar with Sonic, its a company that is focused on Enterprise messaging and the Service Bus concept.  They have been out of the gate for a while now with SOA.

Okay, to make a long story short we used Sonic, wrote Java service containers and functions and have been struggling to implement the thing for the last 3 months.  And how do the ultimately interop with our ASP.Net app?  Through http acceptors.  Not even standard SOAP protocol.  Just plain ole' http posts.  Craziness...

Thank goodness our Architecture Commitee is out there to protect us.

Posted on Sunday, June 6, 2004 6:25 PM | Back to top

Comments on this post: .Net and Java Interoperability with SOA

# re: .Net and Java Interoperability with SOA
Requesting Gravatar...
So did you like Sonic's ESB? How did it compare to BizTalk 2004? I unfortunately only have experience using Microsoft Products for integration and have not had the chance to compare and contrast them against anything.

I would be interested in hearing your comments on this...

Left by Ben Runchey on Aug 24, 2004 2:01 PM

# re: .Net and Java Interoperability with SOA
Requesting Gravatar...
http post are good fast technogy!
Left by god on Jun 16, 2005 11:50 PM

# re: .Net and Java Interoperability with SOA
Requesting Gravatar...
I am pretty much new to SOA, and would appreciate some help with my doubts.
I would like to ask what excatly an ESB is? Is it a Server/Integrator?

How do my clients connect to an ESB (SOAP is fine, but how excatly does it talk - e.g. URL).

Where does my ESB run? Does it run on a Web Server?

Please help me with this.

Peace be upon us,

Left by Kris on Jan 02, 2006 8:47 AM

Your comment:
 (will show your gravatar)

Copyright © Scott Lock | Powered by: