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

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



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.


"Jon Flanders[MVP]" wrote:

> Shawn - BizTalk doesn't use the schemaLocation attribute in that way
> (AFAIK) - it only loads schemas which are "BizTalk Schemas" - Schemas which
> have been built into a BizTalk assembly and deployed. (Some circumstances
> when they aren't deployed as well - but they always have to be part of a
> BizTalk assembly)
>
> --
> Jon Flanders
> http://www.masteringbiztalk.com/blogs/jon/
>
> "shawnk" <shawnk@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:922D9B51-A99D-4392-8EA3-4B914A28A8ED@xxxxxxxxxxxxxxxx
> >I think the following is a bug.
> >
> > Given
> > (1) a schema instance document with
> > (2) the schema locator (<xsi:schemaLocation>) using
> > (3) a server name in the Hosts file
> >
> > we have a schema locator statement as;
> >
> > ....
> > xsi:schemaLocation="http://My_server/My_nsp";
> > http://My_server/My_nsp/The_imported_schema.xsd"; >
> > ...
> >
> > The Hosts file has the entry;
> >
> > 192.168.1.20 My_server # NETBIOS alias name of the LAN XML namespace
> > server of XML schemas
> >
> > As far as I know the use of the Hosts file as a schema relocation and
> > alias
> > mechanism is valid.
> >
> > Is this true? If so this is a bug.
> >
> > Thanks in advance for any response.
> >
> > shawnk
>
>
>
.



Relevant Pages