-
-
Waaw... Finally got my new paper published. Like I already promised a while ago, I was working on a sample and paper, showing how custom pipelinecomponents can be created. Even better: the paper and sample code will show you how to create a *streaming* pipelinecomponent that is able to put data into the msgcontext based upon an XPath expression.
"How's that possible? XPath only works on a DOM Christof - you never can make this streaming!" Yes I can, because of Dare Obasanjo, who recently published a paper and sample code on so called "streaming xpath", which makes up a subset of XPath that can be handled in a streaming, forward-only, way.
For all those funky things: visit the Belgium MSDN site here!
All feedback is welcome, please enjoy this!
-
-
Microsoft just made the results of the BizTalk Server contest public. I immediately started googling but it appears that Paul Somer's entry is not downloadable yet... (Please drop me a line if I'm wrong.) Neverthless, a few cool cool toys appeared on gotdotnet in the mean time. My selection of these:
Please note: I haven't tested nor downloaded all of these. I do not make any judgement on the quality nor availability of the entries above. My only intention here is to give a short overview of what's currently available.
Have fun!
-
-
Todd Sussman posted a few comments/requests on my Transactional .NET Adapter. One of the things I was asked for several times already is whether it would be hard to make it work in a request/response way. Now, to be honest, I did consider this when implementing. A few random thoughts:
- Since the adapter is transactional, and since .NET remoting does not support transactions: the code called by the adapter would always run in process in the same appdomain. (I would need to do really funky things to do this otherwise.)
- I would advice against doing too much work in the component called by the adapter; remember there's a transaction in progress! Ideally the component would access some queue, database or other transactional backend system. Don't start any actions that take a long time and could risk the transaction to time-out.
- Don't start any new threads in your component unless you don't really need the transaction. Any new threads would not retain the transaction context... (Widbey would do a better job here.)
- I decided not to promote request reponse too much since I felt that would raise the risk of blocking the worker thread too long. I was convinced that people needing this functionality would better use another transport to correlate response messages with their request. For example: dropping messages from within your .NET component back on a queue which is asynchronously read by the MQSeries or MSMQ adapter...
Was I wrong? Probably... I'd like to hear all comments you have on this. If you feel you need to have request reponse on the transactional .NET adapter in a scenario, please let me know!
Note to myself: a few other enhancements that I could make:
- load each custom client assembly in a separate appdomain, this would allow for:
- separate security settings for each assembly
- configurable .NET config file for each assembly
- unloading of the appdomain, would prevent needing to restart the BizTalk Service to release an assembly handle
- the request response I just discussed
- provide user with multiple interfaces so they can choose to receive an XmlDocument, XmlReader or just the plain bytestream
-
-
What my last post demonstrated was actually how element reuse limits your ability to reusing an XML Schema definition. Last few weeks I saw still too many people reusing elements over and over without considering what consequences this can have when later on a schema has to be updated, reused or extended...
Regarding the sample, which was correctly identified as invalid by Martijn, Sachin, Peter and Wilco: indeed the XML Schema spec, paragraph 3.3.3 states that "If ref is present, then all of <complexType>, <simpleType>, <key>, <keyref>, <unique>, nillable, default, fixed, form, block and type must be absent, i.e. only minOccurs, maxOccurs, id are allowed in addition to ref, along with <annotation>."
Unless it is very clear that in each and every situation an element will have the same name and exactly the same structure, an element reference is probably not safe to use. I prefer reusing types, wich allow for much more flexible reuse.
Thanks for the comments - you surprised me :-)
Note: I know of a few people already but if anyone else is planning to use the BizTalk Server 2004 Transactional .NET Adapter I've written in a production environment, please get in contact. I'd like to know how this goes, what you plan to use it for and how any additional needs can be further addressed.
-
-
Good news :-)
I've a couple of GMail accounts to give away. Let's make this a little contest :-) Since I'm curious how deep the average XML Schema knowledge goes, I'll grant GMail access to the first two people that post a comment explaining what is wrong with the XML Schema below.
Note: XMLSpy will mark this schema as valid while it certainly is not! (Has anyone accidently noticed my aversion against this tool? :-))) )
<?
xml version="1.0" encoding="UTF-8"?> <
xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" targetNamespace="myTargetNamespace" xmlns:tns="myTargetNamespace">
<xs:element name="address" type="tns:addressType"/>
<xs:element name="customerDetails">
<xs:complexType>
<xs:sequence>
<xs:element name="firstName" type="xs:string"/>
<xs:element ref="tns:address" nillable="true"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="addressType">
<xs:sequence>
<xs:element name="street" type="xs:string"/>
<xs:element name="number" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>