The BizTalk Server Documentation Team is looking for customer input on the documentation of the operations topics.
Specifically they saidthey “want to know what is missing, incorrect, unclear, or just needs work in any of the Operations topics”.
Go here for the survey:
http://www.surveymonkey.com/s.asp?u=32373055498
Be as explicit and clear as you possibly can.
Don’t miss this opportunity to help improve the documentation.
Mark
We BizTalk developers often get frustrated with this assembly GACking stuff. Here is a cool registry setting which will make our life little bit easier.
Copy and paste the code into a notepad file and save it with extension .reg. Double click on the file and its all done.
——————————————————-
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\dllfile\shell\GAC-It\command]
@=”c:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\gacutil.exe /i \”%1\””
——————————————————-
Then open explorer and navigate to your dll, right click on it, for your surprise you’ll see a shortcut called GAC-It as shown below. You can put whatever name you want as highlighted in RED in the above script.
Found it from here
By Jesus Rodriguez
This article is part of a series intended to illustrate WS-* protocols interoperability scenarios between Windows Communication Foundation (WCF) and different J2EE Web Services platforms. Particularly this article focus on MTOM interoperability between WCF and Oracle Application Server v10.1.3.
Binary data exchange using MTOM is a unique Web Services interoperability case given the specific problems that it tackles. Other WS-* protocols presents a broader set of options allowing one to achieve different levels of interoperability. MTOM on the other hand is an exclusive scenario; services can either be or not be optimized with MTOM, but there is no intermediate level. This is why bidirectional MTOM interoperability between technologies is so important.
The first part of this article illustrated a MTOM interoperability scenario between a WCF client and an Oracle App Server Web Service. The following section presents a complementary scenario using an Oracle App Server client and a WCF Service.
The following code shows a WCF service that returns the contents of a file as a binary array.
|
[ServiceContract()] public interface IFileService { [OperationContract()] byte[] GetImg(string path); } public class FileService : IFileService { public byte[] GetImg(string path) { return File.ReadAllBytes(path); } } |
To optimize the message exchange for this service using MTOM we need to configure the MTOM Encoding Binding element as part of the customBinding. In addition, to guarantee interoperability with Oracle App Server, the service should be configured to use Soap 1.2.
|
<system.serviceModel> <services> <service name="wcfService.FileService" behaviorConfiguration="returnFaults"> <host> <baseAddresses> <add baseAddress="service address…"/> </baseAddresses> </host> <endpoint contract="wcfService.IFileService" binding="customBinding" bindingConfiguration="ProviderBinding" address="wcfmtomws"/> </service> </services>
<bindings> <customBinding> <binding name="ProviderBinding"> <mtomMessageEncoding messageVersion="Soap12" /> <httpTransport manualAddressing="false" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true" maxBufferSize="65536" proxyAuthenticationScheme="Anonymous" realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="true" /> </binding> </customBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="returnFaults" > <serviceMetadata httpGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="true" /> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> |
As we explained in the first part of this article, Oracle Application Server supports MTOM as part of its 10.1.3.1 release. The first step to create an MTOM client for the WCF service created on the previous section is to generate the proxy using the Web Service Proxy Wizard included in JDeveloper or the corresponding command-line tool. In order to interface with WCF using MTOM, the client code should set the MTOM_SUPPORT property to “True” either programmatically or using the configuration file. The following code shows a sample client that interacts with the WCF service created in the previous section.
|
public static void CallWS() { try { wsprj.proxy.WSHttpBinding_IFileServiceClient binding = new wsprj.proxy.WSHttpBinding_IFileServiceClient(); IFileService proxy= binding.getPort(); ((OracleStub)proxy)._setProperty(ClientConstants.MTOM_SUPPORT, true); byte[] result= binding.getImg(file path…); System.out.println(result.length); } catch(Exception ex){} } |
Running this client will produce the following SOAP request and response messages. As you might notice, the response message is optimized using MTOM.
|
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="http://tempuri.org/"><env:Body><ns0:GetImg><ns0:path>c:\temp\test2.file</ns0:path></ns0:GetImg></env:Body></env:Envelope> |
SOAP request produced by the Oracle client
|
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"><s:Body><GetImgResponse xmlns="http://tempuri.org/"><GetImgResult><xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F1%2F633013057872812500" xmlns:xop="http://www.w3.org/2004/08/xop/include"/></GetImgResult></GetImgResponse></s:Body></s:Envelope> |
SOAP response produced by the WCF service
MTOM provides a standard and an optimized mechanism to represent binary data in a SOAP envelope. The two parts of this article explained how to achieve MTOM interoperability between Microsoft WCF and Oracle Application Server. The first part explored an interoperability scenario using a WCF client and an Oracle App Server Web Service. This second part has complemented that scenario using a WCF Service with an Oracle App Server client.
I spent a bit of time today reviewing some best practices for assembly version in BizTalk applications, and wanted to also elicit community feedback.
One of the first things that a new BizTalk developer is told when building up a BizTalk solution is to not cram all the various artifacts into a single .NET project. Often that developer will be told to put schemas in one project, maps in another, pipelines in another, and finally orchestrations in an isolated project. I’ve become less of a fan of this rigid structure. But first, let’s see how I’d do an upgrade of a solution configured this way.
I’m starting with a simple project, containing a single schema file. The message looks like this:
I built and deployed this project and constructed a simple “receive location” and “send port” where the send port had a subscription/filter on BTS.MessageType. I tested it, and everything travels through just fine.
Then I built a simple orchestration that makes a decision and writes to the event log. It looks like this:
I referenced the schema project, built, deployed and tested the orchestration successfully. The next step was to create a new version of the schema. So, I added a “Status” node, and then changed the .NET Assembly Version.
I then rebuilt and deployed the schema project. Now given that you’ve constantly been told that namespace#root has to be unique, the screenshot below may worry you.
If you want to read more about how pipelines resolve schemas, read here. So you may expect that I would get a “ambiguous reference” sort of error when I try and submit the inbound message now. However, when I drop the file, the orchestration still picks it up, processes it and continues on its merry way. But, what happens if I “stop” the orchestration so that I can see the message in flight, and investigate the SchemaStrongName property assigned by the pipeline? What you’d see is this:
Surprise. The schema resolved to the most recent version, and THIS is the one yanked in by the orchestration. This surprised me a bit. I would have expected the send port containing the BTS.MessageType filter to yank the most recent version of the schema since it only cared about “type”, but I had thought the orchestration would only grab the version it explicitly referenced. Now if I try and remove the “1.0” schema assembly via the Admin Console, I get an error stating that the orchestration is referencing it.
So to get rid of the “1.0” schema project, I’d have to reversion the Orchestrations project with an updated build. Then after gracefully transitioning to the new “1.1” orchestration, I could safely remove legacy assemblies.
Now, if I used a custom receive pipeline, THEN it seems I can dictate the schema version the orchestration consumes (old schema or new schema). I tested this by putting a receive pipeline (with XML Disassembler and Validator components) in the project with the schema. I deployed that (version 1.0 again). Then, I upped the version to “1.1” and built and deployed. So, now I have schema/pipeline projects for “1.0” and “1.1” and an orchestration project still built with “1.0”.
By switching the pipeline, the orchestration would grab specific versions of the schema. For instance, if I dropped a “1.0” message (no “Status” field) when the “1.0” pipeline was selected, everything ran fine. If I dropped a “1.1” message with the “1.0” pipeline still in place, I got a suspended message. Same situation when I flipped to the “1.1” pipeline. The orchestration consumed either the “1.0” OR “1.1” message.
So, any conclusions here? Changing .NET Assembly Version has broad impact, regardless of how you’ve factored your projects. One recommendation I’ve seen is to only change the Assembly File Version so that you still have an incremented build number, but the core .NET version stays the same (allowing for lower impact changes). However, that could get dicey if you are truly introducing breaking changes. You’ll also see recommendations to version schemas by changing the namespace#root combination (e.g. changing the namespace to http://Microsoft.Project.BizTalkStuff.v1). Of course then you HAVE to change all the dependent artifacts (maps, pipelines, orchestrations) because you’ve made a core modification.
This leads me to a solution structure that is less segmented by artifact type, but more by artifact relevance. That is, group related artifacts in the same project. You still may have a “base schemas” project, but it’s also ok to have a subsequent project that contains a few schemas, maps and orchestrations. Try and group the items that will change and version together. Now if I have to version the schema, I can fairly naturally version the sibling artifacts and deploy fewer assemblies.
So I ask you: any other versioning strategies that you prefer when you want to lessen the impact of production modifications? How do you like organizing your solution structure? If you only have to make a slight change, how do you prevent the rebuild of every dependent project?
Technorati Tags: BizTalk
We’ll be hosting our first ever live online technical chat with the WPF team at Redmond!
No registration just showup on Friday at 9:30am.
We’ll have a collection of the WPF team on hand to answer your technical questions, hear your feedback on what we should be doing in our next release, share great tips and tricks for using WPF, and just generally connecting with one another.
If you’re interested, you can open this ICS file to add the appointment to your calendar.
Hope to see you there – here’s the URL: http://msdn.microsoft.com/chats
Back in school, someone loaned me a copy of Ways of Seeing by John Berger. Since it is still in my possession, I obviously forgot to return it. I wonder if Jane is annoyed? She would likely be more annoyed knowing that I did not get around to reading…(read more)
Back in school, someone loaned me a copy of Ways of Seeing by John Berger. Since it is still in my possession, I obviously forgot to return it. I wonder if Jane is annoyed? She would likely be more annoyed knowing that I did not get around to reading…(read more)
I was coming across some issues with my WCF Service Clients and not shutting down properly.
They were throwing exceptions for various reasons and while trawling the ether I came
across a great helper class (and this is where I saw the c# where clause) from Erwyn
van der Meer
The problem centers around calling proxy.Abort(); or proxy.Close(); at different stages
in the client proxies lifecycle.
Microsoft
explain why we have arrived where we have on this – great candid discussion from
the internal crew.
He discusses
the problem and provides a great WCF
client proxy helper class.
Here’s a snippet from the Microsoft Discussion
Why
does ClientBase Dispose need to throw on faulted state? (Or, what’s the difference
between close and abort?)
ICommunicationObject
(from which ServiceHost, ClientBase, IChannel, IChannelFactory, and IChannelListener
ultimately derive) has always had two methods for shutting down the object: (a) Close,
and (b) Abort. The semantics are that if you want to shutdown gracefully, call
Close otherwise to shutdown ungracefully you call Abort.
As
a consequence, Close() takes a Timeout and has an async version (since it can
block), and also Close() can throw Exceptions. Documented Exceptions out of Close
are CommunicationException (of which CommunicationObjectFaultedException is a subclass),
and TimeoutException.
Abort() conversely
is not supposed to block (or throw any expected exceptions), and therefore doesn’t
have a timeout or an async version.
These
two concepts have held from the inception of Indigo through today. So far, so good.
In
its original incarnation, ICommunicationObject : IDisposable. As a marker interface,
we thought it would be useful to notify users that the should eagerly release this
object if possible. This is where the problems begin.
Until
Beta 1, we had Dispose() == Abort(). Part of the reasoning was that Dispose()
should do the minimum necessary to clean up. This was possibly our #1 complaint
in Beta 1. Users would put their channel in a using() block, and any cached messages
waiting to be flushed would get dropped on the floor. Transactions wouldn’t get committed,
sessions would get ACKed, etc.
Because
of this feedback, in Beta 2 we changed our behavior to have Dispose() ~= Close().
We knew that throwing causes issues (some of which are noted on this thread), so we
made Dispose try to be “smart”. That is, if we were not in the Opened state, we would
under the covers call Abort(). This has its own set of issues, the topmost being that
you can’t reason about the system from a reliability perspective. Dispose can still
throw, but it won’t _always_ notify you that something went wrong. Ultimately
we made the decision that we needed to remove IDisposable from ICommunicationObject.
After much debate, IDisposable was left on ServiceHost and ClientBase, the
theory being that for many users, it’s ok if Dispose throws, they still prefer the
convenience of using(), and the marker that it should be eagerly cleaned up.
You can argue (and some of us did) that we should have removed it from those two classes
as well, but for good or for ill we have landed where we have. It’s an area where
you will never get full agreement, so we need to espouse best practices in our SDK
samples, which is the try{Close}/catch{Abort} paradigm.
Brian McNamara [MSFT]
Came across some interesting code the other day and I must admit I hadn’t seen the Where clause
used like this before:
using System;
class MyClassy<T, U>
where T : class
where U : struct
{
}
And according to the Microsoft Definition found here
The where clause is used to specify constraints on the types that can be used
as arguments for a type parameter defined in a generic declaration. For example, you
can declare a generic class, MyGenericClass, such that the type parameter T implements
the IComparable<T> interface:
public class MyGenericClass<T> where T:IComparable { }
I recently came across an interesting page – http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS06CoreDocs/html/ea7038dc-4740-4c0a-b6a1-08bc22f42bc2.asp
That talks about what is allowed/not-allowed when consuming (and ultimately exposing)
WebServices for use with BizTalk.
A handy reference – the interesting one is the ‘Any’ element not being allowed.
I suppose the alternative is to look at the BizTalk generated WSDL for WebServices
that expose messages of Type XmlDocument and see what is in the actual
WSDL.
Have fun – 6 more sleeps till Christmas!
Yay!