Sonic 7.5.1
My company is moving strongly in the Microsoft direction. There is a big push to replace Sonic with BizTalk. In my mind the only compelling argument for BizTalk is that it is Microsoft and will integrate easily to the other products in the Microsoft technology stack (primarily WCF).
We already have experience integrating Sonic to .NET using web services and the Sonic C# client. Also, we have purchased the Sonic MSMQ adapter so WCF can bind directly to messages on MSMQ.
Can somebody provide me good reasons to retain Sonic instead of migrating to BizTalk? From my reading BizTalk can not scale and does not have software failover (CAA). What are the other strengths of Sonic over BizTalk?
Thanks,
Richard.
The Sonic BPEL support looks to be significantly better than what's in BizTalk.
BizTalk only uses BPEL for import/export of logic.
The question here is what are you trying to do. Sonic ESB has two forms of orchestration one being BPEL as previously discussed in this thread, but also the itineraries/ESB Processes. The later allows reuse of logic and deployment options that BizTalk cannot as well as availabilty that cannot be matched. If you like we can discuss this in more detail offline, just say so in this thread
I have developed in BizTak 2004 and Sonic ESB 7.01. I have not used Sonic BPEL, however BizTalk Orchestrations and Sonic BPEL processes seem very similar when you view the source XML.
Generally, I beleive that BPM platforms have their place but are grossly over sold with promises of developer productivity. I have found them to be a one-step forward, two-steps back. Also, integration is not the strong suit of MS. In the integration space, it's BizTalk against the rest of the world.
Here are a few things I would consider:
1. Writing custom code within Processes. In BizTalk 2004, you could add chunks of code to perform various tasks, however, you had to write them in XLANG. With Sonic, you can use Custom Java Services to perform tasks. Of course I cannot speak to BizTalk 2006. Maybe they have allowed for custom services. Sonic seems to be much more flexible here. In my opionion, striking the right balance custom code and Orchestration is the key to a successful BPM integraiton. Advantage: Sonic
2. Development Experience
I found BizTalk development to be very tedious. I thoght I was going to get carpal tunnel syndrome from all the mouse clicking after the first day of deveopment. Building, enlisting, unenlisting orchestrations was very tedious. If I recall, there were also lost of dependency issues with BizTalk. I find development in Sonic to be much easier. Keep in mind, I have only developed with the ESB in Sonic, not with BPEL Server.
Advantage: Sonic
3. Software Footprint- BizTalk has got to be one of the biggest software installs I have ever seen. It takes hours and hours to get everything installed and up and running. Sonic is much easier to install. BizTalk has a dependency on on SQL Server and IIS. Don't forget hackers love to attack SQL Server and IIS. I also recall there being adependency with an obscure MS Office component that had to be installed. I was floored that BizTalk required something from MS Office. I don't even want to know the details. I can painfully recall how I had to create an install document that had two pages of high-level install steps. I'll try to find the document and post it next week. There are just way too many moving parts in BizTalk.
Sonic has no such dependency on a database, unless one chooses to configure MQ to use a database to store messages. Also, I am amazed at how many messages I can process in Sonic running one container with 256MB of RAM in one JVM. You don't need expensive hardware to run Sonic in Produciton if you do not require it.Advantage: Sonic
4. Cost- BizTalk Enterprise is 35k, plus you have to buy SQL Server and Office if you don't already have it. I think IIS is free. I am no sure how much BPEL server is, but I think ESB and BPEL server can't be more than BizTalk and SQL Server. Advantage: Tie, possible slight advantage for Sonic
5. Functionlaity- I'm sure BizTalk has a few more features(like a rules engine and BAM) that you will never use, so on paper, I'm sure BizTalk would win this, but you could pretty much accomplish the same tasks with either tool. Advantage: Tie
Of course there are about a billion other criteria, but that's all I can think of right now, and I don't think it really matters.
So what does my critique really mean... not much. Let me tell you a story...
At former employer, a client hired us to help them evaluate and choose between BizTalk and BEA WLI. We spent weeks on the project and evaluated every aspect of the two products. At the end of the day, we all realized the choice was not one between BizTalk and BEA, it was a choice between .NET and Java. The client eventually chose BEA because they were an Oracle shop, and they wanted to keep their hardware platform options open. Java was the obvious choice. They didn't have .NET or Java people on staff, so that was not a factor.
So, in short, if you are a .NET shop, then go with BizTalk. If you are a Java shop, or have a mix of skills, keep your options open and go with Java.
Where I work currently, we are about 70% .NET and 30% Java. Java(Sonic) is mopping the floor with .NET in the integration space in our office. Our integration stuff is all Java, and most of the external apps that we integrate with are .NET based. To me, that seems natural. Use each technology according to its strength, and integration is dominated by Java.
Unless you are a pure .NET shop, keep your options open and go with Sonic(Java)
One more thing. Don't use the cheapest/most inexperienced developers you can find to work on the BPM project if you actually want to produce something that works and can be maintained over time.