Re: Biztalk Bug schema locator when host file used for server redi

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



My bad! Last post format not good. Here is a repost.

Jon,

Thanks so much for your response.

I knew that, and its a good way to go. I like the packaging of two
messages and their transform (map) in a single assembly. I like the
runtime engine of Biztalk to validate based on the transformer assembly.

Our concern, however, is to deliver a the message architecture in a 'real'
environment. To do this we are using message patterns that provide 100%
testable SOA streams.

In other words every message instance MUST contain a <xsi:schemalocation>
locator to find the schema on some XML namespace schema server. Note that
in a production enviroment you can randomly 'spot check' messages in the
corporate message streams in the same way factories 'spot check' parts on
the assembly line. (PS. I know about schemaLocation as a 'hint').

In the case of SOA you can grab every 100th, 1000th or 10000th message and
just validate it as a random check of message integrity with the same
'mean time to failure' intentions (not statistical results) of modern
manufacturing plants. Some trading partner SOA streams must be 100% valid
(in addition to security requirements). Some integrity solutions use spot
checking of messages.

This is literally impossible with Biztalk for reasons/bugs posted in other
posts in this forum.

I need the schema <import>, <include> and instance <xsi:schemaLocation>
(using Hosts file) to work when I hit the 'validate Schema' and 'Validate
Instance' buttons in VS.NET/Biztalk DURING DEVELOPMENT TIME (not runtime
where the validate ref point is internal to transformer).

BECAUSE THEY DO NOT WORK IN BIZTALK/VS.NET I CAN'T USE BIZTALK TO MEET OUR
CLIENTS REQUIREMENTS.

I am not going to deliver a 'Biztalk project' that is untestable. In
other words my design is using <import> <include> <schemLocation> and when
'tested' in Biztalk it fails. In BEA, IBM, SUN, XMLspy the same design
pattern works.

Now I could be wrong (which is why this post is here) but the message
design pattern is good.

I have a (1) XML namespace server decoupling
development/production/location via the Host file. This allows IT
operations and development operations to be adaptable. Using the same
message schemas on a LOCAL LAN or on a GLOBAL WAN.

I have (2) schema reuse via <import> and <include> that uses the decoupled
hosts. Now several software development workshops (around the globe) can
use the same message catalog in development and production on their own
local servers (via the Hosts file).

Separate from the IT operational and project development issues lets just
return to a simple 'single guy evaluation' of Biztalk 2004 server (my
personal favorite :-).

During development, when I validate the schema (*.xsd) and instance
documents (*.xml) I have other tools that (besides VS.NET/Biztalk) that I
use to design, edit and test message designs.

Biztalk currently prevents me from using these other tools. I was just at
a Microsoft Tech event last Thursday in which several of us discussed this
very (serious) limitation. Here is an example.

In 'shaking down' Biztalk and evaluating it. I want to be able to
validate and verify schemas with XMLspy. To do so I want to put the
<xsi:schemalocation> in the message instance and use XMLspy to validate
the message using an XML name server.

XMLSpy will validate my message design that adhears to '100% valid' SOA
stream quality. (each message has a <xsi:schemaLocation> attribute ). So
will all the other tools I use.

Biztalk, however, does not let me use this design as follows. When I try
to 'validate' the schema the <import> statement fails for the reasons
given in this (and other) post(s). In addition when I use Biztalk to
validate the instance of the message the validation fails on Biztalk but
works on all the other SOA compatible tools and technologies.

If the message lifecycle only existed in Biztalk I could use the non-valid
message design.

Unfortunately ALL messages will have a lifecycle outside Biztalk. Most
(if not in all our deliverables) seek to have 100% valid SOA streams.
Just like any factory we want 100% 'good parts' that are testable as a
standard requirement.

Sorry for the length here but I want to clearly communicate the need to
the Biztalk design/test team as they have been so helpful (and
professional) in previous posts.

To summarize Biztalk 2004 does not support an important class of message
patterns used to insure (1) IT operations decoupling/adaptability and (2)
corporate SOA stream quality.

I agree with you and like (very much as a matter of fact) the biztalk
validation reference point to be centered in the transformer assembly
(*.xsd,*.xslt,*.xsd). Its a beautiful and robust design. Like all
engineers I just more :-)

I need (1) to be able to VALIDATE AT DEVELOPMENT TIME schemas and
instances in VS.NET/Biztalk that support the HOSTS/IMPORT/INCLUDE class of
design patterns.

Remember that (1) above allows me to deliver a TESTABLE solution with
Biztalk.

TESTABLE in development.

TESTABLE in production.

Right now, for these message patterns, Biztalk solutions are not testable.

Furthermore Biztalk prevents testable message streams from existing in the
system because we can't test at development time.

Note that when I say TEST I mean that several components and tools will be
involved in test. I do not want system testing to depend on just one test
tool as a potential single point of failure.

Thank for your patience with this brief disertation on testable SOA stream
message patterns using HOSTS/IMPORT/INCLUDE mechanims to improve the
quality and robust nature of corporate information flow.

shawnk

PS. Jon thank you, again for your input, you are right. I just can't use
Biztalk for this message design pattern.




.



Relevant Pages