Re: To BizTalk Team: Why need the Promoted Properties? Distinguished Properties?
From: kr_jck (kr_jck_at_yahoo.com)
Date: 03/21/05
- Next message: Scott Colestock: "Re: BizTalk 2004 Orchestration."
- Previous message: Scot S: "810 and 855 document coming in on same receive location"
- Maybe in reply to: Jon Flanders[DevelopMentor]: "Re: To BizTalk Team: Why need the Promoted Properties? Distinguished Properties?"
- Messages sorted by: [ date ] [ thread ]
Date: 21 Mar 2005 13:39:40 -0800
While promoted properties do give performance gains, I am not sure how
elegant or functional they are. I think it can be argued that limiting
promoted properties to non-repeating node values, not fully supporting
XPath or XQuery to set promoted properties and context only based
routing is restrictive, and thus not elegant to me.
I would like to see the ability to assign MessageContextPropertyBase
properties to a schema. Then populate the assigned property with any
valid xpath. This would allow you to route some situations I think are
basic in EAI. For example, routing on non-existence of a node, routing
on the count of a node or a boolean result of an xpath. Finally, and
most likely, routing based on the contained characters of a node such
as starts-with, substring and contains xpath functions.
I had someone from Microsoft say BizTalk 2004 supports content based
routing. I don't agree with that statement. I would say that BizTalk
2004 supports context based routing. If BizTalk really supported
content based routing we should be able to route based on any content
which exists or does not exists in a message. Since the context is
essentially a sub-set of the content for MessageDataPropertyBase
propertied I'll agree that BizTalk 2004 partially supports content
based routing.
I also heard someone use the argument that content based routing is
supported since you can write a custom pipeline to accomplish this.
OK, it's supported, but it is not out of the box support. Let me be
clear what out of the box support means to me. Writing code to do this
is not out of the box support. Out of the box support means it does
not require custom code. To me if you extend the definition of out of
the box support to .Net code then essentially BizTalk 2004 supports
anything .Net can do out of the box. That definition is a little broad
for my taste.
I understand there might be performance implications for those
properties I assign to a schema that run complex xpaths. However, this
is not the primary issue Microsoft should be addressing. They are
essentially saying, "We will limit what you can do out of the box since
any content based routing that is complex will hurt performance". Of
course they go on to say that I can write custom code to solve the
issue which hurts in other ways such as maintenance, deployment, etc...
This is especially relevant since my custom code will still have bad
performance compared to the single valued promoted properties and
comparison operators Microsoft supports out of the box. Meaning, I
will be writing code anyway that will have essentially the same
performance that it would if Microsoft provided me true content based
routing functionality out of the box. So by not supporting out of the
box content based routing I now have to deal with more that just
performance related issues since I am implementing custom code.
So why then do they not support true content base routing? I can't
see a good reason. The only reasonable explanation for just supporting
context based routing is performance. Well that only addresses one
type of EAI issue, which normally is not my biggest concern. Many
times performance is not the driving factor in EAI implementation, for
example, low volume interfaces which are very complex. I don't think
context based routing is capable of supporting these interfaces out of
the box. I don't think you can make an argument that the context based
routing that you can do out of the box is as flexible as true xpath or
Xquery content based routing.
I really don't mind writing the code. I love that stuff. Too bad that
every piece of custom code has to go through justification, approvals,
reviews, be incorporated into deployment, etc... As a developer,
writing a pipeline is fun. However, in terms of the development
process, custom code is always slower to deliver than out of the box
functionality. The real time and costs are not necessarily due to the
time to implement the code. Many other factors play into the time and
costs associated with custom code due to the project management
practices surrounding custom code. I can't believe Microsoft would not
support full content based routing for this reason alone.
In conclusion, I think Microsoft should provide more flexibility out of
the box and let us determine what performs well enough for any given
interface.
P.S. Then throw in the fact that you could do much more with content
based routing using channel filters in BizTalk 2002 and it makes no
sense at all that at least that functionality is not supported.
- Next message: Scott Colestock: "Re: BizTalk 2004 Orchestration."
- Previous message: Scot S: "810 and 855 document coming in on same receive location"
- Maybe in reply to: Jon Flanders[DevelopMentor]: "Re: To BizTalk Team: Why need the Promoted Properties? Distinguished Properties?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
