- This topic has 2 replies, 1 voice, and was last updated 9 years, 3 months ago by
.
-
Posts
-
-
This is more of an attempt to gain opinions or best practices on this, assuming the scenario:
— Multiple user applications within the architecture all publishing and consuming XML documents via MSMQ.
— Single BizTalk Server housing many different applications to support to integration of applications and databases.
— Central business logic requirements will span over all BizTalk applications.Given this architecture, do you:
1) Write your BAL within a single .NET assembly and deploy it to your BizTalk Server and have each application reference the BAL?
2) Write your BAL within a .NET Web Service and have each application hit the Web Service?
3) Use BRE and write your applications to consume the business rules?I ask this because I am deeply concerned about the scalability of option #1 in case the BAL component needs to be changed, you may have to take down your entire integration layer for a possible change to only two lines of code then recompile the BTS apps to link up the newer assembly. Option #2 sounds feasible, but do you want your business logic out there on the network for all to see if you are not attempting to go full SOA and allow other non-BTS apps to use it (may not be an argument). Option #3 may be the way to go, but again, if you need to make changes, are you stuck updating all of the applications referencing those BRE components much like option #1?
Thanks in advance and I’m looking forward to hearing the opinions and ideas.
-Rich -
Rich,
I agree with you on Option 1, however it would be possible to deploy a different version of the assembly to the GAC and then have your BTS apps reference that new assembly through Assembly Redirection in the btsntsvc.config file. You would need to ensure that your interface remains consistant however.
Option 2 seems the most sensible given that you can update the web-service without affecting the rest of you integration layer, however bear in mind the latency going over the network introduces and as you rightly pointed out, you are exposing business-logic and implementing SOA where it isn’t really needed.
Option 3 also seems sensible, given that the deployed BRE policies can be accessed by your entire BTS tier and C# codebase if necessary. You get versioning ‘out-of the-box’, but bear in mind that the latest policy version takes precedence. Furthermore, ‘non-techies’ can update the business rules if necessary.
In my opinion, I would stay away from option 2 as it introduces too many additional overheads, so its a toss up between options 1 & 3 – if you want non-techies to update and deploy your business rules go with BRE, otherwise go with assemblies and redirection.
On a final note, be thankful you’re in an organisation where there is healthy debate, I’m currently over-ruled by C# developers who want to throw out BizTalk and do everything as Windows Services. Sigh.
HTH, Nick.
-
I appreciate the input, Nick!
I was hovering over option 1 and wasn’t fully aware of the redirection option so that may have solidifed the argument in my own mind, thanks for that tid-bit. I do have some WS’s out there simply as adapter solutions for third-party apps, but wasn’t sure if it was feasible for an internal hub for such logic.
Funny you mention the challenge you’re encountering…I had the same thing here for the longest time until I was able to finally get them to ‘see’ what I can do in BizTalk that actually made their lives that much easier. It was a hard fought batte, but know that it can be won. 🙂
Thanks again!
-Rich
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.