by community-syndication | Jul 26, 2007 | BizTalk Community Blogs via Syndication
I went to this conference last year in Redmond and it was awesome. I highly encourage you to get along if you have the budget and time.
Microsoft SOA & Business Process Conference 2007
Microsoft is pleased to announce the 2007 Microsoft SOA & Business Process Conference to be held from October 29th through November 2nd, 2007 at the Microsoft Conference Center on the Microsoft Campus in Redmond, WA. During 4 days of breakout sessions, chalk talk discussions, hands-on-labs, peer networking, and social events you will learn about both Microsoft’s current portfolio and long-term strategy for SOA & Business Process initiatives. Whether you are a developer, architect, or business decision maker we will have something for you with tracks spanning technology, architecture, and business value topics.
What You Can Expect:
- Keynote sessions by senior Microsoft executives and technical leaders
- Over 60 breakout and chalk talk sessions
- Hand-on-labs
- Customer case-study roundtables
- Ask The Experts event
- Partner Expo
Thank you and we look forward to hosting you this fall!
SOA & Business Process Conference event team
Register here: https://dynamicevents.emeetingsonline.com/emeetings/websitev2.asp?mmnno=247&pagename=SITE52841
by community-syndication | Jul 26, 2007 | BizTalk Community Blogs via Syndication
It’s update time again!
Soma and Scott have many more details on their blogs.
Soma and Scott have also recorded a Channel 9 video that will be published later today, which overviews these releases.
One thing that Soma mentioned in his post is that Silverlight RC is coming in the next couple of days. I have been using the RC of Silverlight over the last week and there are a few breaking changes that we all will need to address if we want existing Silverlight applications running on the web to continue to work after the RC!
The Silverlight 1.0 RC is “feature complete” and shortly we will also release an updated (CTP) Silverlight Add-in for VS 2008 so that developers can continue to collaborate with designers using the upcoming Expression Blend 2 August Preview to build Silverlight experiences.
Enjoy!
by community-syndication | Jul 26, 2007 | BizTalk Community Blogs via Syndication
My article on BizTalk host throttling appeared in BizTalk
Hotrod Issue 2 – Todd VanNurden and Sal Cincotta have done a great job with
assembling and editing content, so be sure to take a look at the whole issue.
I’m hoping to write a follow-up piece that discusses custom throttling techniques
in a future issue.
(And before you ask, I don’t own a suit nearly half as nice as the one Todd
has photoshopped me into for the magazine.)
by community-syndication | Jul 26, 2007 | BizTalk Community Blogs via Syndication
My article on BizTalk host throttling appeared in BizTalk
Hotrod Issue 2 – Todd VanNurden and Sal Cincotta have done a great job with
assembling and editing content, so be sure to take a look at the whole issue.
I’m hoping to write a follow-up piece that discusses custom throttling techniques
in a future issue.
(And before you ask, I don’t own a suit nearly half as nice as the one Todd
has photoshopped me into for the magazine.)
by community-syndication | Jul 26, 2007 | BizTalk Community Blogs via Syndication
Introduction:
This post is the first in a series of posts that will describe a number of production considerations for Enterprise customers (“Enterprise” loosely defined as those with moderately complex BizTalk implementations)
This is in response to a great deal of confusion that I have encountered in the field and hopefully I can kill about 500 birds with 1 stone by publishing these findings (no offence to bird enthusiasts J ).
Today’s Topic – Starting the Production Infrastructure
BizTalk Server 2006 has a dizzying array of scalability options, but many options can mean complexity. This post will specifically discuss the most common “starting points” for production enterprise BizTalk systems and compare/contrast them so you can hopefully figure out which one best suits your needs.
The X + Y notation means:
X Dedicated BizTalk boxes
Y SQL Server Nodes
Server Configurations
Before we get started here, I have to emphasize that these are all common STARTING configurations. Configurations can (and do) scale out and up depending on your requirements.
Also, all of these configurations have some notion of high availability, no single node failure will kill the infrastructure. Way more options are available if you sacrifice High Availability (but that’s pretty unusual in the Enterprise isn’t it? J )
|
|
This configuration has the minimal number of servers involved but it does present some complexity problems because the BizTalk hosts must be clustered if you are running the ENTSSO service as a clustered service. You either cluster the hosts or live with having an un-clustered Enterprise Single Sign- on Master Secret Server. Either option could be best depending on your requirements.
|
|
|
This configuration is a pretty good starting point for the cost-sensitive enterprise. This allows separation of BizTalk from SQL (a good thing) while maintaining redundancy by having two BizTalk nodes that can “cover for each other” in case one of them goes down. The ENTSSO MSS can be installed as a clustered service on the SQL cluster without creating complications for the BizTalk hosts (i.e. they don’t have to be clustered, which is also a good thing in many cases)
This is probably my favorite starting point. It is the lowest cost, and scaling out with more BizTalk servers is really easy. If you’re not sure which one to pick, take this one. |
|
|
This configuration is an improvement on the 2+2 configuration because it really allows the orchestrations and business logic to become intensive without having much of an impact on the Send/Receive operations (even though the Send/Receive operations can still interfere with each other). This is for enterprise applications with moderate Send/Receive activity and fairly intensive business logic.
|
|
|
Of the configurations being considered in this article, this is the most capable (and most expensive). This allows full separation between BizTalk and SQL, and also between the Send/Receive/Process operations within BizTalk. This configuration is for Enterprises with intensive Send/Receive/Process requirements.
Notice the additional SQL server, a pretty good rule of thumb is a ratio of 3:1 for BizTalk:SQL servers. Although this one is 3:1 with only 2 SQL servers, a failure of one node would change that ratio to 6:1. Seeing as how this configuration is for high volume scenarios, that would be bad. Invest a couple of bucks and have a passive node in the wings to keep things running if a SQL node goes down! |
Comparison Chart
|
0+2 |
2+2 |
4+2 |
6+3 |
High Availability |
Yes |
Yes |
Yes |
Yes |
Performance |
Lowest |
Medium |
Medium |
Best |
Cost (# Servers) |
Lowest |
Medium |
Medium |
Highest |
Ease of clustering SSO MSS |
Hard |
Easy |
Easy |
Easy |
Separation of SQL and BizTalk |
No |
Yes |
Yes |
Yes |
Dedicated Receive Nodes |
No |
No |
No |
Yes |
Dedicated Send Nodes |
No |
No |
No |
Yes |
Dedicated Process Nodes |
No |
No |
Yes |
Yes |
Easy to Scale out |
Complex |
Yes |
Yes |
Yes |
Call to Action
I know what I want to write about, but this blog isn’t for me! What topics do you want to see in the next article? Drop in a request in the comments section below and I’ll review before I start writing the next article (I promise)
by community-syndication | Jul 26, 2007 | BizTalk Community Blogs via Syndication
When my mobile phone contract came up for renewal in December of last year, I decided to move into the 21st Century, abandoning my trusty Nokia 6330 and going for a Windows Mobile device. For my sins, I opted for a T-Mobile contract and the MDA smartphone. Unfortunately, it wasn’t all that smart and should […]
by community-syndication | Jul 26, 2007 | BizTalk Community Blogs via Syndication
Introduction:
This post is the first in a series of posts that will describe a number of production considerations for Enterprise customers (“Enterprise” loosely defined as those with moderately complex BizTalk implementations)
This is in response to a great deal of confusion that I have encountered in the field and hopefully I can kill about 500 birds with 1 stone by publishing these findings (no offence to bird enthusiasts J ).
Today’s Topic – Starting the Production Infrastructure
BizTalk Server 2006 has a dizzying array of scalability options, but many options can mean complexity. This post will specifically discuss the most common “starting points” for production enterprise BizTalk systems and compare/contrast them so you can hopefully figure out which one best suits your needs.
The X + Y notation means:
X Dedicated BizTalk boxes
Y SQL Server Nodes
Server Configurations
Before we get started here, I have to emphasize that these are all common STARTING configurations. Configurations can (and do) scale out and up depending on your requirements.
Also, all of these configurations have some notion of high availability, no single node failure will kill the infrastructure. Way more options are available if you sacrifice High Availability (but that’s pretty unusual in the Enterprise isn’t it? J )
|
|
This configuration has the minimal number of servers involved but it does present some complexity problems because the BizTalk hosts must be clustered if you are running the ENTSSO service as a clustered service. You either cluster the hosts or live with having an un-clustered Enterprise Single Sign- on Master Secret Server. Either option could be best depending on your requirements.
|
|
|
This configuration is a pretty good starting point for the cost-sensitive enterprise. This allows separation of BizTalk from SQL (a good thing) while maintaining redundancy by having two BizTalk nodes that can “cover for each other” in case one of them goes down. The ENTSSO MSS can be installed as a clustered service on the SQL cluster without creating complications for the BizTalk hosts (i.e. they don’t have to be clustered, which is also a good thing in many cases)
This is probably my favorite starting point. It is the lowest cost, and scaling out with more BizTalk servers is really easy. If you’re not sure which one to pick, take this one. |
|
|
This configuration is an improvement on the 2+2 configuration because it really allows the orchestrations and business logic to become intensive without having much of an impact on the Send/Receive operations (even though the Send/Receive operations can still interfere with each other). This is for enterprise applications with moderate Send/Receive activity and fairly intensive business logic.
|
|
|
Of the configurations being considered in this article, this is the most capable (and most expensive). This allows full separation between BizTalk and SQL, and also between the Send/Receive/Process operations within BizTalk. This configuration is for Enterprises with intensive Send/Receive/Process requirements.
Notice the additional SQL server, a pretty good rule of thumb is a ratio of 3:1 for BizTalk:SQL servers. Although this one is 3:1 with only 2 SQL servers, a failure of one node would change that ratio to 6:1. Seeing as how this configuration is for high volume scenarios, that would be bad. Invest a couple of bucks and have a passive node in the wings to keep things running if a SQL node goes down! |
Comparison Chart
|
0+2 |
2+2 |
4+2 |
6+3 |
High Availability |
Yes |
Yes |
Yes |
Yes |
Performance |
Lowest |
Medium |
Medium |
Best |
Cost (# Servers) |
Lowest |
Medium |
Medium |
Highest |
Ease of clustering SSO MSS |
Hard |
Easy |
Easy |
Easy |
Separation of SQL and BizTalk |
No |
Yes |
Yes |
Yes |
Dedicated Receive Nodes |
No |
No |
No |
Yes |
Dedicated Send Nodes |
No |
No |
No |
Yes |
Dedicated Process Nodes |
No |
No |
Yes |
Yes |
Easy to Scale out |
Complex |
Yes |
Yes |
Yes |
Call to Action
I know what I want to write about, but this blog isn’t for me! What topics do you want to see in the next article? Drop in a request in the comments section below and I’ll review before I start writing the next article (I promise)
by community-syndication | Jul 25, 2007 | BizTalk Community Blogs via Syndication
Here are some more syntax examples for the new library version:
3. Using pre-built pipelines:
If you have existing, already compiled, BizTalk pipelines, I currently have two options
for using them:
ReceivePipelineWrapper pipeline = Pipelines.NewReceive(typeof(MyPipeline));
Or:
ReceivePipelineWrapper pipeline = Pipelines.NewReceive<MyPipeline>();
4. Adding Document Specifications:
It’s also important to add any necessary document specifications (schemas) to the
pipeline before executing it so that disassembler and assembler components can find
them. This is now possible as well during construction:
SendPipelineWrapper pipeline = Pipelines.NewReceive()
.AddAssembler(new XmlAsmComp())
.WithSpec<MySchemaType>() .End();
One thing I’m not quite sure about here is with the standard XML pipelines and prebuilt
pipelines. For them, the current factory methods in the Pipelines class don’t
return a builder object (like the one returned by the empty NewReceive() and NewSend()
methods I introduced last
time), so if you want to add known document specifications to those, you still
need to use the old AddDocSpec() method in the ReceivePipelineWrapper and SendPipelineWrapper
classes. It’s not much more complexity, but the asymmetry makes me dislike it a bit.
So I’ll probably be changing the code so that all pipeline creation methods return
builder objects and not the actual pipeline objects. Any objections?
5. Executing Send Pipelines:
One annoying part of the current API is that when executing Send pipelines you need
to explicitly create a MessageCollection instance, add your input messages to it and
then call Execute() with it. Not too bad, but inconvenient if you only have one or
two messages (which is most of the time).
I thought about several possible syntaxes to simplify this, but in the end decided
to do the simplest fix: I added a new overload to SendPipelineWrapper.Execute() that
has a params array of IBaseMessage instances. So you can now do this:
IBaseMessage output = pipeline.Execute(message1, message2);
Simple, but effective!
by community-syndication | Jul 24, 2007 | BizTalk Community Blogs via Syndication
I have uploaded slides and demos I presented at Tech Ed if anyone is interested in taking a look at them. I presented this last month atin Orlando.
The demos show Dynamic Mapping, Self-Correlation Ports, Untyped Messages, and WCF Calls in Messaging. The WCF demos will require BizTalk Server R2. These demos are as is and mayneed someconfiguration changes to work on your system.
To view the power point slides, Office 07 is required.
The slides and demos can be found here.
I was to thank everyone who attended the presentation! I hope to be back next year.
by stephen-w-thomas | Jul 24, 2007 | Stephen's BizTalk and Integration Blog
I have placed the Demos and Slides I presented at Tech Ed online if anyone is interested in taking a look at them. This was presented last month at Tech Ed 2007 in Orlando.
The demos show how to use Untyped Messages, Dynamic Mapping, Self-Correlation Ports, and WCF Calls in pure messaging. The WCF demos require R2. These demos are as-is and may not run on your system without some configuration changes.
To view the power points, Office 07 is required.
The demos and slides can be found here.
Thanks to everyone who attended the presentation!
