If you saw the recent announcement about the Adapter Pack 2.0 release, you may have seen the short reference to a tool that migrates “classic” SQL Adapter solutions to the new WCF SQL Adapter. This tool claims to:
Works on the source project files
Generates equivalent schema definitions for the operations used in the existing project
Generates new […]
[Source: http://geekswithblogs.net/EltonStoneman]
WCF bindings provide the MaxReceivedMessageSize property, which lets you block any incoming messages on the client side over a given size (defaulting to 64Kb). If you’re using message-based itinerary processing with ESB Guidance, when a WCF service returns a message larger than this default, you’ll get a System.ServiceModel.QuotaExceededException and the response message will be suspended:
System.ServiceModel.CommunicationException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element. —> System.ServiceModel.QuotaExceededException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.
Setting the MaxReceivedMessageSize property is straightforward in a configured WCF port, but in ESB Guidance the port is configured dynamically and there’s no straightforward way to interrupt it and add your own WCF bindings. To give us access to the message and the port, we replaced the “DynamicSendResponse” port used in the GlobalBank.ESB sample with a simple orchestration.
The orchestration has a direct-bound receive port filtering on the usual properties:
(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == “DynamicResolutionSolicitResp”) &&
(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == “Pending”) &&
(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == “Messaging”)
– it then builds the outgoing message for the service, and configures the dynamic send/receive port. At this point the message has all the properties you need configured by ESB (via the resolver pipeline component in the previous itinerary steps), so you can extract them to configure the port, and add any WCF binding configuration you need.
We store the configuration in the Enterprise Single Sign-On application config store using SSO Config Tool, so the expression to build the outgoing message and increase the received message size looks like this –
//setup port from context properties:
sptServiceProvider(Microsoft.XLANGs.BaseTypes.Address) = ServiceProviderRequest(BTS.OutboundTransportLocation);
sptServiceProvider(Microsoft.XLANGs.BaseTypes.TransportType) = ServiceProviderRequest(BTS.OutboundTransportType);
//set message size from config:
maxReceivedMessageSize = x.y.z.Configuration.X_Y_Z_Config.WCFMaxReceivedMessageSize;
ServiceProviderRequest(WCF.MaxReceivedMessageSize) = maxReceivedMessageSize;
Microsoft.Practices.ESB.Adapter.AdapterMgr.SetMsgProperty(ServiceProviderRequest, typeof(WCF.MaxReceivedMessageSize), maxReceivedMessageSize);
//set timeout from config:
sendTimeout = x.y.z.Configuration.X_Y_Z_Config.WCFSendTimeout;
ServiceProviderRequest(WCF.SendTimeout) = sendTimeout;
Note that the WCF config is set on the message, not on the port. We’re also setting timeout values here. When you’re dealing with large messages, you may get operation timeouts as the default binding config from BizTalk is set to a pessimistic 1 minute. Value WCF.SendTimeout specifies how long the BizTalk client waits for a response, and WCF.ReceiveTimeout how long the BizTalk client allows for the reception of a request. If your WCF service is hosted in IIS and is long-running, you may also have an issue with IIS controlling execution times. See: Why changing SendTimeout does not help for hosted WCF services.
I’m always looking for these binding files so here’s a note to myself:
C:\Documents and Settings\<your account>\Application Data\Microsoft\BizTalk Server\Deployment\BindingFiles
As promised in my last post (http://geekswithblogs.net/cyoung/archive/2009/02/24/129639.aspx), I had a look at the Express edition of Microsoft Solver Framework (http://code.msdn.microsoft.com/solverfoundation), and used it to implement the Einstein puzzle using the built-in CSP solver and C#. Creating the solution proved particularly easyfor the simple reason that Microsoft provides a worked example of a politically corrected ’Zebra’ variant in their documentation (no tobacco or beer in sight). You will find this as Sample 8 in the SFS Programming Primer document that comes with the download.
To read more and see the code, visit http://geekswithblogs.net/cyoung/archive/2009/02/25/129672.aspx
This is really the EDI error version of multiple schemas deployed with identical Namespace#RootNode. Check the deployed schemas under your All Artifacts application
I've previously blogged about cleaning (emptying) the MsgBox database , something that can be useful in some scenarios, like development and test. While looking for something else the other day I found information about an equally useful procedure…(read more)
[Source: http://geekswithblogs.net/EltonStoneman]
Using LoadGen 2007 to submit messages with a complex SOAP header, I had a strange issue with the standard SOAP transport. The SOAP transport has two parameters for wrapping the input file into a SOAP envelope:
<Parameters>
<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>
<SOAPHeader>SOAPAction: “http://microsoft.practices.esb/Process/SubmitRequestResponse”</SOAPHeader>
<SOAPPrefixEnv><?xml version="1.0" </SOAPPrefixEnv>
<SOAPPostfixEnv></Root></SubmitRequestResponse></SOAPPostfixEnv>
<IsUseIntegratedAuth>False</IsUseIntegratedAuth>
<LatencyFileName></LatencyFileName>
<ResponseMsgPath></ResponseMsgPath>
<DstEncoding>utf-8</DstEncoding>
</Parameters>
– note the ellipses above are for brevity and are not in the actual LoadGen config file.
When the transport gets called, it opens an HTTP request and sends the SOAP envelope by writing three sets of byte arrays to the request stream: the value of SOAPEnvPrefix, the contents of the input file, then the value of SOAPEnvPostfix. All the byte arrays are encoded to the value specified by DstEncoding. When I used this configuration to send a message it was being rejected by the endpoint as a bad request. Trapping the request with Wireshark, it looked like this:
It looks as though LoadGen has injected an ellipsis before each part of the message it built – the envelope prefix, the input file contents and the envelope postfix all start with an ellipsis in which is not in the original. The request is malformed and rejected by the service.
Initially I thought this was something strange in how Wireshark was showing the results and wasn’t actually part of the message, so I checked further and found that the XML escapes weren’t set correctly. The SOAP header is an ESB Guidance itinerary which contains escaped XML for CDATA sections – to enter it as the SOAPEnvPrefix parameter meant escaping the escapes, so <!CDATA[]> becomes &lt;!CDATA[]&gt; in the parameter and is rendered correctly. But the issue remained, and so did the ellipses. Copying the full request into Web Service Studio produced the same result, but cutting out the ellipses meant it processed correctly.
With time accumulating on what should have been a simple task, I checked out the SOAPTransport code and could see nothing that was causing this. Debugging the call didn’t show any ellipsis characters being written, and modifying it to produce a single string of the header, body and footer before encoding made no difference. In the end I created a modified transport which takes a full SOAP envelope as the input file, doing away with the envelope parameters altogether.
This worked fine, didn’t render any ellipses – although the code is very similar to LoadGen’s SOAPTransport class – and was happily processed. It has the advantage that you can capture a full message with Wireshark, save it and use it in LoadGen without having to extract the header. It’s on the MSDN Code Gallery here: Sixeyed.Samples (Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport).
Configuration is very similar to the standard transport, just specify the assembly and remove the SOAP envelope parameters:
<Transport Name=”SOAP”>
<Assembly>Sixeyed.Samples.dll/Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport</Assembly>
</Transport>
<Parameters>
<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>
<SOAPHeader>SOAPAction: “http://microsoft.practices.esb/Process/SubmitRequestResponse”</SOAPHeader>
<IsUseIntegratedAuth>False</IsUseIntegratedAuth>
<LatencyFileName></LatencyFileName>
<ResponseMsgPath></ResponseMsgPath>
<DstEncoding>utf-8</DstEncoding>
</Parameters>
But I’m still puzzled about those ellipses from the standard SOAP transport.
Ok, so I’ve finally sucumbed to the Twitter phenomenon and I’m now twittering, or is that tweeting? Eitherway, you can follow me over at http://twitter.com/nickheppleston if you are so inclined…
A few days ago, Daniel Selman of ILOG (now owned by IBM) published a solution to the Einstein puzzle. See http://blogs.ilog.com/brms/2009/02/16/einsteins-puzzle/. He did this in response to a challenge from James Owen who is one of the organisers of the October Rules Fest conference. James invited the various vendors who have involvement in the conference to provide a solution using whatever approach they deemed best. See http://orf2009.blogspot.com/2009/02/puzzle-1-for-conference.html.
Daniel suggests that, if ILOG had used a Rete rules engine, they would have had to implement ‘convoluted rules’ to solve the problem. Daniel is correct, but I thought it would be interesting to look a little deeper at why this is the case.
Read more athttp://geekswithblogs.net/cyoung/archive/2009/02/24/129639.aspx.
With Microsoft's announcement at PDC this fall and with the continued growth of Amazon's EC2 service and Google's AppEngine service, the industry seems to have people's heads up in the clouds. With this shift of focus, though, comes a myriad of questions about reliability, security, and portability. Potential customers of the cloud want to know that it can indeed be depended on. Executives want to know that the security of data in the cloud will not be compromised. Software engineers want to know that if a certain provider evaporates into thin air, minimal effort will be required to move deployed assets and keep mission critical apps moving.
With so many questions about elastic hosted services, and an as of yet unclear track record for the same, I cannot help but wonder if the cloud computing model will really take hold, or if it will just be a bridge to an even more impressive generation of computing architectures to follow. Maybe it will be both. This discussion then begs the question — of what that generation will look like that does follow.
Nearly 10 years ago, a program was created that would compel sci-fi geeks, amateur astronomers, scientists, programmers, and scholars to change their screensaver. SETI@home launched in 1999 and over the next 9 years would bring grid computing into the living rooms and dorm rooms of over 5 million people. The original software was an app and screen saver that would use idle computer time to drive the search for extraterrestrial intelligence. It harnessed the untapped power of millions of computers with unrealized potential. It was built as an experiment, to break free of the constraints imposed by a supercomputer. Even hosted clusters have their limits, and some problems go beyond those limits.
With cloud computing the sky is the limit, but what if this world is not enough? What if a single company's data centers won't cut it? What if you want to maintain your data center, while still being able to tap additional resources on demand? What if you wanted to maximized and monetize under-utilized computational resources, instead of just writing them off as depreciating assets each year?
That seemed to be the aim of now defunct CPUShare. It offered users the opportunity to sell their idle CPU time to people who needed computational resources. What if the spirit of this project was matched with the vision of Windows Azure, or the ease of entry of Amazon's EC2. What if it added storage into the mix, RAM, and even bandwidth? What if each of these was currency in a new economy? This new economy would not be comprised of just one company's slice of the cloud; it would be the whole thing.
Crowd sourcing CPU hours might very well be the future, or it may be a pipe dream that will never be possible. It has the same questions of reliability, security, and portability, and it brings with it the question of control. The way the industry deals with the questions about cloud computing today, could very well pave the way for crowd computing to be the driving force behind Web 4.0 and beyond.