November 21, 2014
Hot Topics:

A Windows Service Solution for Unreliable Web Services

  • June 28, 2006
  • By Jeffrey Juday
  • Send Email »
  • More Articles »

Loading a Gateway

As discussed previously, the GatewayRouter performs all of the routing functions, including executing the appropriate gateway. To initiate routing, the GatewayRouterExecution calls Init and then DoRouting in GatewayRouter. DoRouting calls RouteMessageFor on each of the configured channels. Each channel can have multiple messages, so RouteMessageFor calls InvokeGateway for each channel message.

GatewayRouter is the heart of the Windows service and the heart of GatewayRouter is the InvokeGateway function:

IXmlServiceGateway gateway = null;
bool tryWSInvocation = true;
int tryCount = 0;
try
{
   gateway = GetGateway(info);
   while ( tryWSInvocation )
   {
      gateway.Run(info.ServiceInstanceID);
      //The assembly can indicate that a retry is possible,
      //the router determines how many times it will attempt to
      //call run.
      if (gateway.CanRetryRun() && tryCount < _wsRetryCount)
      {
         tryWSInvocation = true;
      }
      else
      {
         tryWSInvocation = false;
      }
      ++tryCount;
   }
   //This was added for administration troubleshooting and reporting
   WriteGatewayResultsToDB (dbConn,info,gateway.CurrentMessage);
   if (gateway.IsErrorToReport() )
   {
      LoggingFunctions.WriteToLog_Error(gateway.CurrentMessage);
   }

As you can see, code is included to retry the Run function should some sort of failure occur.

The Windows service assumes all gateways inherit from a common C# interface: IXmlServiceGateway. On a class implementing IXmlServiceGateway, the Run function performs all the actions necessary to invoke the Web service and write the response data back to the application database. Giving the gateway access to a database so it could retrieve parameters and save responses greatly simplified the process, allowed for easier transaction processing, and eliminated the need to pass XML messages between the queues.

Another key section of code is the AddGateway function:

Assembly assm = Assembly.LoadFrom(info.AssemblyName);
//Assembly has no public constructor
IXmlServiceGateway gateway;
gateway = null;
gateway = (IXmlServiceGateway) assm.CreateInstance(info.ClassNameSpace);
gateway.Init(info.ServiceTypeID);
_gateways.Add (gateway);

AddGateway uses functions from the System.Reflection namespace to load the assembly containing the Gateway class, which creates an instance of the Gateway class and assigns the instance to an IXmlServiceGateway interface.

Controller: Multithreading

GatewayRouterExecution executes its StartRouting function on a thread inside GatewayRouterController:

_signal.ContinueRouting = true;
while ( _signal.ContinueRouting )
{
   _router.DoRouting();
   //If discontinue signal was given don't sleep
   if ( _signal.ContinueRouting )
   {
      Thread.Sleep(_delayRoutingInterval);
   }
}

As you can see, StartRouting does not terminate until it is signaled to do so. The class GatewayRouterSignal housed inside the GateRouterController and shared with the other classes is used to signal whether the Windows service must terminate or Routing must cease because it is outside of the service window.

The GatewayRouterControl is the Windows service. The Windows service code calls the Start and Stop functions on GatewayRouterControl to start and stop the service. As stated previously, GatewayRouterControl runs the GatewayRouterExecution on a separate thread. The following snippet of code executes the GatewayRouterExecution class on the thread:

_threadExec = new Thread(new ThreadStart(_routerExec.StartRouting));
_threadExec.Start();
_routingActive = true;

For more information on multithreading, check out following articles: "Multithreading in .NET Applications," "Multithreading in .NET Applications, Part 2," and "Multithreading in .NET Applications, Part 3". For more information on constructing a Windows service, read "Creating a Windows Service in .NET".

Applying the Solution

Before applying the ideas in the solution described here, consider the following ideas:

  • The Windows service can be used to supplement an existing integration solution such as BizTalk. You may have a Web service with a response type that BizTalk can't handle out of the box, or you may simply have an unreliable Web service you want to handle in a specialized way.
  • The solution is a prototype. In your implementation, you may want to build a more configurable service window class.
  • The solution does not reuse SQL Server connections efficiently. Reusing connections efficiently will increase application performance.

Mitigate Web Service Reliability Problems

Web services can be unreliable. A Web service problem can exist on the client side, server side, or the Internet itself. You can mitigate Web service reliability problems by using an asynchronous messaging approach implemented inside a Windows service.

Download the Code

Download the code that accompanies this article.

About the Author

Jeffrey Juday is a software developer with Crowe Chizek in South Bend, Indiana. He has been developing software with Microsoft tools for more than 12 years in a variety of industries. Jeff currently builds solutions using BizTalk 2004, ASP.NET, SharePoint, and SQL Server 2000. You can reach Jeff at jjuday@crowechizek.com.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel