Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


Microsoft Announce Windows Store Details

By Steve Ives, Posted on December 9, 2011 at 12:49 pm

Steve Ives

Since the //BUILD conference in September many developers have been eagerly awaiting the details of how the new “Windows Store” will operate. The Windows Store will be the primary mechanism by which Windows 8 users will find and acquire Windows Metro-Style Apps.

In addition to the information provided during the event, a new BLOG called Windows Store for Developers was also launched. The BLOG will be worth watching if you’re interested in building and deploying Metro apps.

By the way, if you’re wondering what the time-line looks like on the Windows Store, and on Windows 8 generally, at the end of the video Microsoft confirmed that the Windows Store will open at the same time as the Windows 8 Beta is released, which will be in Late February of 2012.


Windows Reimagined

By Steve Ives, Posted on September 14, 2011 at 12:18 am

Steve Ives

Well, all I can say is “WOW”! The first day of the Microsoft BUILD conference is over, and it’s been a LONG day, and it’s been a BUSY day, and it’s been an EXCITING day. Wow!

I’m buzzed … and I’m really quite surprised by that statement. I arrived in Anaheim a little over 24 hours ago, and to be quite honest I was a little skeptical about the whole thing. As you may know from a couple of recent posts, I had started to do some research about what Windows 8 might mean to Synergex, and to our customers, and to our customers customers … and to be quite honest I had more questions than answers. I was more than a little concerned that Microsoft were all set to try to change the Windows world … which they are … but perhaps with less than the amount of (in my opinion) required consideration for existing customers, and applications, and technologies, and tools.

Specifically, I was concerned that there was a lot of talk about HTML5, and of CSS, and of JavaScript … but very little talk about XAML, and C#, and third-party languages like Synergy .NET, and so on. I was concerned that Microsoft were set to not only reimagine Windows, but also reimagine all of the development tools that are used to build Windows applications.

But … big sigh of relief … from me and several thousand other people in the room … although there is a definite emphasis on new development tools which will soon be available within the Microsoft development toolset, i.e. extended support for tools like HTML5, CSS and JavaScript,  there is also a consistent message that existing .NET toolsets are still completely valid and will continue to be so.

On the platform side … WOW! Most of the information to date has centered around videos of demos dating back to early June, and those demos were pretty impressive, Well, I can tell you that things have moved on quite significantly since then, and although Windows 8 is still only in a “Developer Preview” (i.e. pre-beta) state … it’s looking REALLY GOOD!

Of course there are bugs, of course there are glitches, but on the whole people at this conference are pretty excited about what is coming. And that includes the four Synergex employees that are here … after a long day at the conference, and a pretty good stint in the bar afterwards, we’re bouncing ideas around, and coming up with all of these “what if’s”, and seeing the real possibility of Synergy developers being able to fully participate in these exciting new technologies.

Of course some of the reason for this is as a direct consequence of the tens of thousands of man hours of work that have been invested in the various Synergy products in recent years. But also it is with the realization that there is more work still to be done, because the goal posts just got moved in a fairly significant way. But … because of where we know we are now, where we now know we need to be actually doesn’t seem that far away … WOW!

There are exciting times ahead … there are challenges also, but I firmly believe that we’re on the right track.

If you’re interested in the future of Windows then I would strongly recommend that you watch the keynote speech from todays conference, you can find it and many other interesting videos here:

https://www.buildwindows.com

By the way, I am writing this post on my new Samsung Windows 8 “Slate” PC. Those who know me would tell you that I develop on Windows, and Unix, and Linux, and OpenVMS … but I’m an Apple guy at heart. I have an iPhone, and an iPad, and a couple of Macs … and I LOVE those things. But … I think that Microsoft Windows 8 might just change the world. It’s an operating system for the PC, and that PC might just be a Slate (tablet). The point is that today I was convinced that the best of both worlds really can be built into one operating system that can run equally well on different types of devices. I LOVE my iPad but I can’t run hundreds of thousands of existing desktop apps on it, and despite good intentions iOS is jus WAY too restrictive. What Microsoft showed us and gave us today is really cool … it’s a tablet, but it’s also a PC … WOW!


Windows 8 and Screen Resolution

By Steve Ives, Posted on September 8, 2011 at 4:10 pm

Steve Ives

If you’re thinking of purchasing a new laptop, or a new flat-panel monitor for your desktop PC, you might want to think a carefully about the resolution of the screen that you select. Because if you’re purchasing new hardware now, you’re likely to want to run Windows 8 on that hardware before the end of its useful life.

According to early information from Microsoft, both the resolution and aspect ratio of the screen will become more important if you want to be able to take advantage of all of the new features available in the new Metro UI.

For the best experience with Windows 8, and in order to be able to take advantage of all of the new Metro UI features, you need a wide-screen with a 16 x 9 aspect ratio and a minimum pixel resolution of 1366 x 768. If your system meets or exceeds these specifications then you should be in good shape, and most will.

However, if your display does not have a wide-screen aspect ratio then you won’t be able to use all of the features of the Windows 8 Metro UI. Specifically the “Snap” feature which allows two “tailored” metro applications (or one tailored application and the traditional Windows Aero desktop) to be docked side-by-side will not be available. By the way, the term tailored application seems to be what Microsoft are using to refer to apps designed to take advantage of the Metro UI under Windows 8. I can’t help wondering if the choice of this term is to make us lowly software developers think that we just need to do a little “tailoring” here and there to support the new UI … in the same way that cell-based applications had to be “tailored a little” to move to Windows under UI Toolkit! Time will tell I guess.

By the way … don’t confuse the windows 8 “Snap” feature with another feature that they introduced in Windows 7 called … “Snap”!!! Although similar, they are not the same thing. Note that the Windows 7 desktop snap feature will still work on the traditional desktop, even if your system doesn’t support the Windows 8 Snap feature. All very confusing!

Finally, although uncommon some netbook PC’s are equipped with displays with less than 768 vertical pixels (e.g. 1024 x 600). Apparently displays this small will not support the new Metro UI at all, although the traditional Windows Aero UI will still work on these systems.

This information was taken from a video of a Microsoft event for various hardware partners which was held during the Computex 2011 in Taipei during early June 2011. If you’re interested in the full video, I’ve embedded it below.


Exposing WCF Services using Synergy .NET

By Steve Ives, Posted on at 12:54 pm

Steve Ives

In this post I will explain how you can use Synergy .NET to expose a WCF service. I’ll be showing you how to create WCF service and data contracts totally from scratch, using Synergy .NET. We’ll be defining new classes, not working with existing routines and records. That’s not to say that you can’t work with existing routines and records, in fact you may well chose to do so WITHIN a service that you create, but the focus of this post is on writing new code for the future.

This is the sixth in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET (this post)

 

In earlier posts I demonstrated how it was possible to expose WCF services using existing source code, either by transforming an xfNetLink .NET assembly into a WCF service, or by adding the traditional Synergy subroutines and functions that existed “underneath” an xfNetLink .NET assembly to a new Synergy .NET Interop project. There are valid use cases for both of these strategies, depending on what you’re starting with, however there are also some disadvantages to both approaches.

Perhaps the most significant disadvantage is that the external interface of the WCF service contracts that get exposed are defined by the parameters and return values of one or more traditional Synergy routines. And the data contracts are defined by Synergy record layouts defined in a repository. Also the actual WCF contracts that are exposed are under the control of the code generators that create the contracts, either GENCS, or the logic within the Interop project. This means that as a developer you’re kind of stuck with the defaults that those tools provide.

WCF has diverse capabilities which are defined and controlled through a large number of code and configuration options, and many of these are controlled via in-code attributes which are applied to the service and data contracts that make up a service. But when you work with services that are generated for you you don’t get to determine what options are used. So in some cases you might find that working with generated services is a little too restrictive.

This post will show how to create your own WCF services from scratch, in a way that makes all of the capabilities of WCF available to you.

The WCF Service Library Template

Although it has been possible to create WCF services with Synergy .NET since the product was introduced in version 9.5.1, the process became a lot easier in 9.5.1a. This was because we added a new project template called WCF Service Library. To create a new WCF service we simply start Visual Studio and create a new project based on the WCF Service Library template:

image

When you use the project template you create a new class library which is pre-configured appropriately for the development of WCF service and data contract classes.

imageOver and above a regular class library, a WCF Service Library development project will include:

  • References to the following .NET Framework assembles
    • System.Core
    • System.Runtime.Serialization
    • System.ServiceModel
    • System.Xml
  • An example of how to define WCF service and data contracts.
    • IService1.dbl
  • An example of how to implement the service defined by a service contract.
    • Service1.dbl

 

Before we go too much further let me make it clear that I don’t particularly like the example code that is provided by the project template, despite being the one who actually provided it for the distribution! But there is a good reason why the example code is the way that it is. That reason is that the example implements in Synergy the the exact same example that Microsoft provide when you create a new WCF Service Library using either C# or Visual Basic.

Service Contracts

So what do we have in the example? Most developers agree that it is good practice to separate the definition of a service contract from the actual implementation of the contract, and for service contracts this is achieved using an interface. In the example file called IService1.dbl you will find code like this:

WCF Service Contract
  1. import System
  2. import System.Collections.Generic
  3. import System.Runtime.Serialization
  4. import System.ServiceModel
  5. import System.Text
  6.  
  7. namespace MyWcfServices
  8.  
  9.     {ServiceContract}
  10.     public interface IService1
  11.         
  12.         {OperationContract}
  13.         method GetData, string
  14.             required in val, int
  15.         endmethod
  16.         
  17.         {OperationContract}
  18.         method GetDataUsingDataContract, @CompositeType
  19.             composite, @CompositeType
  20.         endmethod
  21.         
  22.         ;;TODO: Add your service operations here
  23.         
  24.     endinterface
  25.     
  26. endnamespace

 

The example defines a WCF service in a class named Service1 and therefore, following accepted best practices, the name of the interface that defines the external view of the class is prefixed with a capital I. You will notice that the {ServiceContract} attribute is applied to the interface, which essentially means that any class which implements the interface will expose a WCF service contract.

Within the interface you will see that the example code defined two methods, named GetData and GetDataUsingDataContract. Both of these methods have the {OperationContract} attribute applied, which means that the methods will be exposed as operations of the WCF service … or in other words they are methods that a remote client accessing the service may call.

The GetData method accepts a single parameter which is an integer number, and has a return type of string.

The GetDataUsingDataContract method on the other hand has a single single parameter which is an object of type “CompositeType” and also returns an object of the same type. CompositeType is a class representing a complex data type (think OO version of a record) and is defined a little further down in the code:

By the way, you will notice that the methods that are described in the interface do not have accessibility specified. This is because by convention, all members of an interface are considered public. You will also notice that there is no procedure division specified … there is no PROC statement. This is because the role of an interface is simply to DEFINE requirements for a class, or rather for the external interface of a class. Interfaces do not include any logic … that will be added in a class which IMPLEMENTS the interface.

Data Contracts

Data contracts define complex data types (data classes) that can be passed from a client to a service or returned from a service back to a client, and are simply defined via a class with public properties of the appropriate types.

In the example the class named CompositeType has two public properties, one of type boolean named BoolValue, and one of type string named StringValue. As is often the case, the value of the public properties is propagated within the class by storing the actual value of the property in private variables, in this case the mBoolValue and mStringValue fields.

WCF Data Contract
  1. import System
  2. import System.Collections.Generic
  3. import System.Runtime.Serialization
  4. import System.ServiceModel
  5. import System.Text
  6.  
  7. namespace MyWcfServices
  8.  
  9.     ;;Use a data contract as illustrated in the sample below to
  10.     ;;add composite types to service operations
  11.     {DataContract}
  12.     public class CompositeType
  13.  
  14.         private mBoolValue, Boolean, true
  15.         private mStringValue, String, "Hello "
  16.         
  17.         {DataMember}
  18.         public property BoolValue, Boolean
  19.             method get
  20.             proc
  21.                 mreturn mBoolValue
  22.             endmethod
  23.             method set
  24.             proc
  25.                 mBoolValue = value
  26.             endmethod
  27.         endproperty
  28.         
  29.         {DataMember}
  30.         public property StringValue, String
  31.             method get
  32.             proc
  33.                 mreturn mStringValue
  34.             endmethod
  35.             method set
  36.             proc
  37.                 mStringValue = value
  38.             endmethod
  39.         endproperty
  40.  
  41.     endclass        
  42.  
  43. endnamespace

 

What makes the CompositeType class a WCF data contract is the presence of the {DataContract} attribute immediately before the class declaration, and the {DataMember} attributes immediately before the declaration of each of the public properties. The {DataContract} attribute is used to ensure that it is possible to serialize an instance of the class for transmission over the wire between a client and a server, and the {DataMember} attributes define which members of the class will be included in that serialization, or in simpler terms, which members will be visible to client applications.

It should be noted that, despite being the case in the simple example provided by the project template, it is somewhat unusual to define multiple types within a single source file as is the case here. In a real application it is likely that each interface would be defined in its own source file, as would each data class. There is nothing technically wrong with the approach used in the example, and it does keep the definition of all of the contracts for a service together in one place, but you don’t have to do it that way.

Implementing a WCF Service

So in the simple example provided by the WCF Service Library project template we have looked at the definition of the service and data contracts for Service1 in the source file IService1.dbl. Now it’s time to look at the code that actually implements the service itself. That code is found in Service1.dbl.

WCF Service Implementation
  1. import System
  2. import System.Collections.Generic
  3. import System.Runtime.Serialization
  4. import System.ServiceModel
  5. import System.Text
  6.  
  7. namespace MyWcfServices
  8.     
  9.     public class Service1 implements IService1
  10.         
  11.         public method GetData, String
  12.             required in val, int
  13.             endparams
  14.         proc
  15.             mreturn String.Format("You entered: {0}", val)
  16.         endmethod
  17.         
  18.         public method GetDataUsingDataContract, @CompositeType
  19.             composite, @CompositeType
  20.             endparams
  21.         proc
  22.             
  23.             if (composite==^null)
  24.                 throw new ArgumentNullException("composite")
  25.             
  26.             if (composite.BoolValue)
  27.                 composite.StringValue = composite.StringValue + "Suffix"
  28.             
  29.             mreturn composite
  30.             
  31.         endmethod
  32.         
  33.     endclass
  34.     
  35. endnamespace

    

The code above is the code that implements Service1. You will notice that this is achieved by writing a class which implements the interface that describes the service contract that we talked about earlier.

Writing a class which implements an interface is simply a matter of ensuring that the class includes at least the members that are described by the interface … in this case the GetData and GetDataUsingDataContract methods. The class may also include other members not described in the interface, but MUST at least contain the members described by the interface.

You will also notice that both of the methods required by the interface are declared with PUBLIC accessibility. As mentioned earlier this is a requirement when implementing an interface. When we implement an interface we include the code that each method in the interface will execute, so here is where the actual functionality of the service is defined.

In the example code the GetData method simply takes the integer value that was received from the client and uses that value in a string which is returned to the client. So if a client application connects to an instance of this service and calls the GetData method passing a value of 5, the return value of the method call will be the string You Entered: 5.

The GetDataUsingDataContract method checks to ensure that an instance of the CompositeType class was received, than if the objects BoolValue property is set to true it appends the string Suffix to whatever is the current value of the objects StringValue property. The object is then returned via the method return value. Yea, I know, the dev at Microsoft must have been smoking something pretty questionable when they wrote this example. Something more meaningful would have been nice, but it is what it is!

Writing a WCF Service

So, there you have it. Writing a WCF service in Synergy .NET is pretty straight forward. You basically need to:

  1. Create a new assembly using the WCF Service Library project template.
  2. Define the external interface of your service via an interface that describes the service and operation contracts, and any data classes that may be required to define the data contracts that you need.
  3. Create a class which implements the service contract and includes the necessary functionality.

And remember we’re working in Synergy .NET here, so we have the full power of Synergy at out fingertips. If we need to access Synergy data that’s local to where the service will be hosted then we can go ahead and access that data directly, but if the data is remote then we can use xfServer to get to it – regardless of the system it resides on. We could also use an xfNetLink .NET assembly to allow us to get back into our traditional Synergy business logic, for all or part of the logic for the service. And of course we still have access to the SQL Connection API in order to access any relational databases that we may need to use. Of course we could also use other mechanisms in the .NET Framework to access a wide variety of data sources too.

Hosting the Service

If you’ve read the earlier posts in this series then you will already know that creating a WCF service is only part of the story, it also needs to be hosted somewhere. This has already been discussed in two earlier posts, so I don’t intend to repeat the information here.


Self-Hosting WCF Services

By Steve Ives, Posted on September 2, 2011 at 4:17 pm

Steve Ives

Having defined a WCF service in code, and built that code into an assembly, a runtime instance of the service must be “hosted” somewhere in order for other application to be able to connect to and interact with the service. There are several ways to host WCF services. In an earlier post I described how to Host a WCF Service in an ASP.NET Web Application, which is a commonly used approach. But in some situations, for example if the only requirement for an IIS web server is to host a WCF service, it is preferable to host a service in a different way. In this post I will describe how to do just that, by leveraging capabilities of the .NET Framework which allow WCF services to be “self hosted”.

This is the fifth in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF services using Synergy .NET Interop
  5. Self-Hosting WCF Services (this post)
  6. Exposing WCF services using Synergy .NET

What is Self Hosting?

As its name suggests, self hosting a WCF service refers to the ability to host a WCF service within another application that you write, rather than hosting the service in a container such as that provided by Internet Information Services (IIS), or Windows Process Activation Services (WAS).

The .NET Framework provides various classes that can be used to host WCF Services within the context of a .NET application. This could be any type of .NET application, including console applications and desktop applications. However, in most cases WCF services need to be continually available, and it is often not convenient to host a service in a console or desktop application, because those applications typically execute in the context of a logged in user session.

A Windows Service application on the other hand can provide an excellent mechanism for hosting a WCF service. Windows Services are generally designed to automatically start when a system boots, stopped when the system is closed down, be continually available while the system is running, and are not associated with the desktop of any logged in user.

Since 9.5.1a Synergy .NET has included a project template which makes creating a Windows Service very easy, and as you are about to see, adding the code necessary to instantiate and host a WCF service is relatively straight forward.

Creating a WCF Service

In this post I’m assuming that you have already created a WCF service that you wish to host. If you have read the earlier posts in this series you will already know of two ways to create a WCF service, and in a later post I’ll show you another way.

Creating a Windows Service

Using Synergy .NET it is very easy to create a Windows Service. We provide a project template called “Windows Service”, and when you create a new project from the template you essentially have all of the code that you need to implement the service. Of course, apart from starting and stopping a service the default code that you get from the template doesn’t actually do anything … that’s where you come in!

You’ll need a Windows development system with the following products installed

  • Visual Studio 2010 Professional (or higher / later)
  • Synergy/DE 9.5.1a (or later)
  • Synergy Language Integration for Visual Studio 9.5.1a (or later)

 

Follow these steps to create a new Windows Service:

  • Start Visual Studio
  • From the menu, select File > New > Project.
  • From the installed templates list, select Synergy/DE.
  • From the project templates list select Windows Service.
  • Provide a name for the project and set its location.
  • Click the OK button to create the new project.

 

image

As you can see, in my example I have named my service MyWcfHostService and have created the project below my c:temp folder.

imageOnce the Windows Service project has been created, if you look in Solution Explorer you should see something like this:

You will notice that three source files were added to the project. In my example the file MyWcfHostService.dbl contains the code for the service itself, MyWcfHostServiceInstaller.dbl contains code used when the service is registered (installed), and Program.dbl is simply the main-line program that actually launches the service when the process starts.

Take a look at the main service source file (the one that ends …Service.dbl) and you will see that the code is relatively self explanatory. The class defined in the source file extends a parent class called ServiceBase. This means that our class has inherited a lot of functionality which essentially makes it a Windows Service.

You’ll also see that the class has a constructor method with the same name as the class itself, and the constructor calls a method called InitializeComponent, which sets various properties in order to configure various capabilities of the service.

private method InitializeComponent, void
    endparams
proc
    this.ServiceName = "MyWcfHostService"
    this.AutoLog = true
    this.CanPauseAndContinue = false
    this.CanHandlePowerEvent = false
    this.CanShutdown = false
    this.CanStop = true
endmethod

All Windows services have the ability to be started, and as you can likely derive from the code, by default a new service has the ability to be stopped, but not to be paused and continued, or to respond to changes in the systems power state (mains vs. battery).

So, our new service can start, and it can be stopped. All we need to do is define what code should be executed when the service starts, and when the service stops. And if you scroll down a little you will notice that the code already contains place-holder event handlers where we can add whatever code we need:

protected override method OnStart, void
    byval args, [#]String
    endparams
proc
    ;;TODO: Add code to execute when the service is instructed to start
endmethod
		
protected override method OnStop, void
    endparams
proc
    ;;TODO: Add code to execute when the service is instructed to stop
endmethod

Our task is relatively straight forward. All we need to do is add whatever code is necessary to create and expose an instance of a WCF service in the OnStart method, and to stop the service in the OnStop method.

Referencing a WCF Service

The WCF service that we will be hosting has already been created in a separate assembly, so to get access to it we need to add a reference to that assembly in our Windows Service project.

  • In Solution Explorer, right-click on the References folder and from the context menu select Add Reference.
  • Wait for the Add Reference dialog to be displayed and load it’s data, which usually takes a few seconds.
  • Click on the Browse tab, then browse to the location of the assembly that contains your WCF service.
    • If your WCF service is defined in an xfNetLink .NET assembly then this is whatever folder you created the assembly in.
    • If your WCF service is defined in a Synergy .NET Interop project, or some other Visual Studio project, then you will generally find the assembly below that projects “bin” folder.
  • Select the assembly and click the OK button to add the reference to the assembly containing the WCF service.

Additional Steps for xfNetLink .NET WCF Services Only

If your WCF service is defined in an xfNetLink .NET assembly then there are two additional steps that you will need to complete.

Add a reference to xfNetLink .NET

Because your WCF service is defined in an xfNetLink .NET assembly, that assembly will require that your project also has a reference to the xfNetLink .NET assembly.

  • In Solution Explorer, right-click on the References folder and from the context menu select Add Reference.
  • Wait for the Add Reference dialog to be displayed and load it’s data, which usually takes a few seconds.
  • Click on the Browse tab, then browse to the location of the xfNetLink .NET assembly (xfnlnet.dll).
    • The assembly will normally be found under your Program FilesSynergexxfNLNet folder.
  • Select the assembly and click the OK button to add the reference.

Supply xfNetLink .NET Connection Information

Because your WCF service uses xfNetLink (to connect to xfServerPlus in order to execute your Synergy methods), you must tell xfNetLink where the instance of xfServerPlus is listening (host name or IP address, and port number). The best way to do this is via an application configuration (app.config) file.

  • In Solution Explorer, right click on your Windows Service project and from the context menu, select Add > New Item.
  • Select Application Configuration File and click the Add button.

Having added the configuration file to the project you need to specify the required configuration information, something like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <sectionGroup name="xfnlnet">
      <section name="default" type="System.Configuration.NameValueSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    </sectionGroup>
  </configSections>
  <xfnlnet>
    <default>
      <add key="host" value="192.168.1.10" />
      <add key="port" value="2356" />
    </default>
  </xfnlnet>
</configuration>

Note: You can also use the Synergy .NET Configuration Utility to add this information to the file. Clearly you should replace the IP address and port number with the correct values for your own instance of xfServerPlus.

Hosting an Instance of the WCF Service

In the most basic form, self-hosting a WCF service in another application essentially turns that application into a web server. The web server capabilities are provided by a class in the .NET Framework called ServiceHost. This class is found in a namespace called System.ServiceModel, and is provided the System.ServiceModel.dll assembly.

The code that we’ll be adding will use these web server capabilities to expose a “WCF Endpoint” at a specified HTTP address.

In addition to exposing an endpoint which is an instance of your WCF service, you will usually also want to expose a second “metadata endpoint”. This allows other applications that may need to interact with your WCF service to download the metadata for your service. The metadata fully describes the service and its capabilities, and is made available automatically by WCF. Clients applications can use a standard protocol called Metadata Exchange (often referred to as MEX) in order to download a WCF services metadata from a metadata endpoint. In code, we use a second class called ServiceMetaDataBehavior to expose our services metadata. This class is in the System.ServiceModel.Description namespace, and is also in the System.ServiceModel.dll assembly.

If all of this is starting to sound really complicated, well it is! Luckily the .NET Framework hides most of these requirements from us, and does most of the work. Despite sounding really complicated, the code that we need to write is remarkably simple.

To self host a WCF service there are generally three main things you will need:

  • The URI for the endpoint for the service.
  • An instance of the ServiceHost class to expose your service at that URI
  • An instance of the ServiceMetaDataBehavior class to expose a metadata (MEX) endpoint.

 

So, lets write this thing:

  • Use the Add Reference dialog that you used earlier to add a reference to the Frameworks System.ServiceModel assembly.
  • At the top of the code in your …Service.dbl file, add the following two import statements:
import System.ServiceModel
import System.ServiceModel.Description
  • Somewhere inside the class, but NOT inside any method, add the following data declarations:
private baseAddress ,String
private host        ,@ServiceHost
private smb         ,@ServiceMetadataBehavior

In the procedure division of the OnStart method, add code like this:

protected override method OnStart, void
    byval args, [#]String
    endparams
proc
    ;;Define the URI for the service endpoint
    baseAddress = "http://" + Environment.MachineName + ":8080"

    ;;Create a ServiceHost instance for the WCF service
    host = new ServiceHost(
    &       ^typeof(spc2011.SynergyServer),
    &       new Uri(baseAddress))

    ;;Add a BasicHttp endpoint
    host.AddServiceEndpoint(
    &       ^typeof(spc2011.ISynergyServer),
    &       new BasicHttpBinding(),
    &       "SynergyServer")

    ;;Create a ServiceMetaDataBehavior instance
    smb = new ServiceMetadataBehavior()
    smb.HttpGetEnabled = true
    smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy15

    ;;Add a MEX endpoint
    host.Description.Behaviors.Add(smb)

    ;;Start the listener
    host.Open()

endmethod

In my example, the namespace in which my WCF service is defined is “spc2011” and the name of the WCF service class is “SynergyServer”. You would need to:

  • Replace the reference to spc2011.SynergyServer with the namespace and class of your WCF service.
  • Replace the reference to spc2011.ISynergyServer with the namespace and interface of your WCF service.

IMPORTANT: When GENCS –W is used to create a WCF service, it applies the ServiceContract attribute to the CLASS that is created, rather than to the INTERFACE. So for xfNetLink .NET WCF services both of the above references should point to the CLASS.

Other than that, the code should work for any WCF service.

Now all that remains it to add the code to stop the WCF service when the Windows service stops. In the procedure division of the OnStop method, add this code:

protected override method OnStop, void
    endparams
proc
    host.Close()
    host.Finalize()
endmethod

Build the Windows Service

It’s time to build the application and see how good your typing is!

  • In Solution Explorer, right-click on your Windows Service project and select Build.
  • Check the output window to make sure your application built correctly. You’re looking for something like this:

 

------ Build started: Project: MyWcfHostService, Configuration: Debug Any CPU ------
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

If your application does not build correctly then you’ll need to review the instructions above and make sure that you completed the required steps.

Registering and Starting the Windows Service

Now that you have a Windows service there are only two more steps that you’ll need to complete before the service can be tested. Those steps are:

  • Register the service with Windows.
  • Start the service.

To register the service you’ll need to open a Visual Studio command prompt window and then go the the folder that contains your applications executable. This will generally be the binDebug or binRelease folder below your project. Once you’re there you should be able to register your service like this:

..binDebug> INSTALLUTIL MyWcfHostService.exe

Look for messages that indicate that the service was successfully installed, then start your service like this:

..binDebug> NET START MyWcfHostService

Look for messages indicating that the service was started correctly.

Testing the WCF Service

If your Windows service started correctly then your WCF service should now be running. To verify that it is, open a browser and navigate to the URI that was specified in the code.

http://localhost:8080

You should see a WCF service home page similar to this:

image

 

If you see a service page like this then you should be able to start using the service. Of course we haven’t talked about how to do that yet … that’s for another day!

Remember to Stop The Service

You probably want to stop and unregister your Windows Service before you forget that it’s running. To do do, return to the Visual Studio command prompt and use commands like these:

..binDebug> NET STOP MyWcfHostService
..binDebug> INSTALLUTIL /u MyWcfHostService.exe

Exposing WCF services using Synergy .NET Interop

By Steve Ives, Posted on at 11:20 am

Steve Ives

In this post I will explain how a WCF service can be created using a Synergy .NET Interop project. In my earlier post I explained how to use xfNetLink .NET to create a WCF service, which provided an easy way to create a WCF service for developers who were already using xfNetLink .NET and xfServerPlus. Now I want to show you an alternate approach that is somewhat similar in nature, but which does not require the continued use of xfNetLink .NET and xfServerPlus in final solution. Of course this might not be what you want if your Synergy server is a non-Windows system.

This is the fourth in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF services using Synergy .NET Interop (this post)
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

What is Synergy .NET Interop

Before we get started we better make sure you know what a Synergy .NET Interop project is. In a nutshell an Interop project is a way of creating a .NET assembly containing various classes, where the external interface of those classes is defined by a collection of Traditional Synergy xfServerPlus methods, and the Synergy records that are referenced by the parameters of those methods. The idea is that the classes exposed by the assembly created by an Interop project have the exact same external interface that would be created if those same methods were defined in a Method Catalog and exposed via xfServerPlus and xfNetLink .NET. So the primary use case for an Interop assembly is to allow developers with existing applications which use xfNetLink .NET and xfServerPlus to factor those tools out of their solution, resulting in a pure .NET application.

In the same way that GENCS has an optional –W command line switch which essentially transforms the resulting .NET assembly into a WCF service, the Synergy .NET Interop project has a project option which does the exact same thing.

So let’s get started. Here’s how to do it. Remember, an Interop project allows you to expose a Synergy .NET assembly based on one or more traditional Synergy methods and records, but there are some prerequisites:

  1. The Synergy methods must make use of the recently introduced attributes and documentation comments, so that the external interface of the method is entirely defined within the code. The Interop project does not use a Synergy Method Catalog. For more information on this you can refer to a blog post that I wrote back in 2009 called Wave Goodbye to the MDU.
  2. The records that are referenced by the parameters of the methods must be defined in a repository, but this would always have been the case if you were using xfServerPlus.
  3. Generally the data files that are accessed by your methods should be moved to the Windows server where the WCF service will be hosted, so that the files can be accessed locally. If your data files need to stay on a non-Windows server then of course you could use xfServer to access the files remotely.
  4. You’ll need to have a copy of the source code for the Synergy methods available on the Windows development system where you are using Synergy .NET.

These are the steps that you’ll need to complete in order to create a Synergy .NET Interop assembly from your existing Synergy methods and repository structure definitions:

Create an Interop Project

The first step in the process is to create a new Synergy .NET Interop Assembly project:

  • Open Visual Studio and create a new Synergy .NET Interop Project.
  • From the menu, select File > New > Project.
  • In the Installed Templates list select Synergy/DE > Interop.
  • Set the name and location of the new project as required (here I’m naming the project MyInteropAssembly and setting the location to my c:temp folder).
  • Click the OK button to create the new project.

 

image

When you create an Interop project a new source file called SynergyRoutines.dbl is automatically included in the project. This file contains various utility routines that are used by the interop project in order to expose the same interface that xfNetLink .NET does. You shouldn’t need to be concerned with this code, and shouldn’t modify it. Simply close the file.

Add Synergy Method Source Files

Having created the Interop project the next step is to add the source code for your Synergy methods to the project. Remember that the methods that you include in an Interop project are Traditional Synergy subroutines and functions that include whatever {xfMethod} and {xfParameter} attributes are required in order to completely document the external interface of the methods within the source files.

imageFor clarity when creating an Interop project I also like to include my method source files in a folder within the project, and I generally name the folder “Methods”. This is entirely optional though.

  • In solution Explorer, right-click on your Interop project and from the context menu select Add > New Folder.
  • Change the name of the folder to Methods and press enter.
  • Right-click on your new Methods folder and from the context menu select Add > Existing Item….
  • Use the resulting open file dialog to browse to the location of your Synergy method routines, select them all, and then click the Add button to add the routines to your project.

In Solution Explorer your project should now look something like the image on the right.

Before we move on let me make a couple of things clear. Firstly it is important that you know that when you add existing files to a project using Add > Existing Item, those files are COPIED into your project folders. If you prefer to leave the source files in their existing location then you can use Add > Reference Existing Item.

The second thing that you need to understand is that in the example I am using here the nature of the methods that I am using is relatively simple, and the methods don’t have external dependencies on other routines in libraries, don’t use include files, etc. If your methods do have such dependencies then you will need to decide how best to resolve those dependencies.

Set Environment Variables

It is likely that you will need to set some environment variables in order for your code to be able to compile and run. It is almost certain that you will need to at least set the environment variables that allow your repository to be located and accessed, and in the case of the code that I am using, at runtime an environment variable named DAT is used to specify the location of the data files that are accessed by the code.

Synergy .NET development projects include the ability to set environment variables in the development environment via properties of the project:

  • In Solution Explorer, right click on your project and from the context menu select Properties.
  • In the project properties dialog, to the left side, select the tab named Environment Variables.
  • Set whatever environment variables are required in order for your code to compile and run.
  • Save your changes by selecting File > Save from the menu.
  • Close the project properties dialog.

In the case of the code I am using for this example I needed to set the following environment variables:

image

By the way, the tools in Synergy .NET also honor the same mechanisms for setting environment variables as Traditional Synergy on the Windows platform. So if the environment variables that you need are already present in your system environment, or are provided by the synergy.ini or synuser.ini files then you won’t need to set them here.

Build an Interop Assembly

You should now be able to build your interop assembly.

  • In Solution Explorer, right-click on your project and from the context menu select Build.
  • Check the output window, you should see something like this:
------ Build started: Project: MyInteropAssembly, Configuration: Debug Any CPU ------
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

 

imageIf your assembly did not build then you’ll need to resolve any errors that you may have before you proceed. The most likely cause for errors at this point will be external dependencies that are not catered for.

Check out what happened in your project. If you look in Solution Explorer you will notice that a new folder called GeneratedCode was created, and some new source files were added to the folder. These new files are at the center of how Interop projects work.

The method source files that you added to the project, in the Methods folder, were Traditional Synergy subroutines and functions. The job of an Interop project is to expose the functionality of those methods in the same way that xfNetLink .NET’s GENCS utility does, and GENCS creates .NET classes that represent the Synergy methods, and the data structures exposed by those Synergy methods.

The Interop project essentially does the same thing, except that where GENCS created C# code which uses xfNetLink .NET and xfServerPlus to call the Synergy methods, the Interop project creates Synergy .NET code which calls the Synergy methods directly.

In the code used in my example the Synergy methods that I added to the project were all part of an interface named “SynergyServer”. This was defined by the {xfMethod} attributes that were present in each of the source files that I included into the project. You will notice that the GeneratedCode folder now includes a source file named SynergyServer.dbl, and if you were to look in the source file you would see that it contains a class named SynergyServer, which in turn contains methods named GetAddressForUpdate, GetAllCustomers and so on. These methods correspond to the Synergy methods that I originally included in the project.

Additionally you will notice that the GeneratedCode folder also contains several source files which represent the record definitions which are exposed by the parameters of my methods. For each record that is exposed the interop project has created a class to represent that data structure. These classes are named Address, Address_type, Contact and so on.

However, if you were to look in the source files that have been generated into the GeneratedCode folder you might notice that these generated classes do not contain any ServiceContract, OperationContract, DataContract or DataMember attributes. In other words, the classes can’t currently be exposed via WCF.

Note: You should not make changes to any of the code in the GeneratedCode folder, because this code will be recreated each time you build the project. 

Expose a WCF Service

As I briefly discussed in an earlier post, in order for classes to be exposed via WCF it is necessary to apply various attributes to those classes:

Nature of ItemRequired Attribute
Class containing callable methodsServiceContract
Callable methodOperationContract
Class defining a data structureDataContract
Accessible member in a data structureDataMember

 

In an Interop project, these attributes can be automatically added to the generated classes by enabling a project option called “Generate WCF Contracts”.

  • In Solution Explorer, right-click your project and select Properties.
  • In the project properties dialog, to the left side, select the tab named Interop.
  • Check the Generate WCF Contracts option.
  • In most cases it’s also a good idea to set the Generate out parameters property to out instead of the default value of “ref”.
  • Save your changes by selecting File > Save from the menu.
  • Close the project properties dialog.
  • In Solution Explorer, right-click on your project and from the context menu select Build.
  • Check the output window and make sure that your assembly built correctly.

 

Note: The default behavior of generating out parameters as ref is to maintain compatibility with what GENCS does by default, but when exposing a new WCF service to a new client application you would always want output parameters defined as type out.

 

Now take a look at the various source files in the GeneratedCode folder. You should notice that the ServiceContract, OperationContract, DataContract and DataMember attributes are present as required.

Host the Service

That’s it, you just used a Synergy .NET Interop project to define and create a WCF service. Of course before you can actually do anything with the service you will need to host it somewhere. One option is to host the service in an ASP.NET Web Application as described in my earlier post.

However, sometimes developers don’t want to have to setup and maintain an IIS web server simply to host a WCF service. Luckily there are other ways of hosting a WCF service that do not require IIS, and that will be the topic of the next post in this series.


Building Windows 8

By Steve Ives, Posted on August 29, 2011 at 1:50 pm

Steve Ives

As Microsoft’s new Build Windows conference draws ever closer the rumor mill about what the focus of the conference will be is gathering momentum. This is due in no small part to the fact that with the conference only two weeks away there is still no published agenda. But that doesn’t seem to have deterred people from attending, I would estimate that there are generally over 10,000 delegates at these events, and this conference has been sold out since early August!

That being said it’s not too hard to figure out from the name of the conference that the focus will be on the next version of the Windows operating system, which Microsoft have “code named” Windows 8! What might be a surprise to a lot of people however is the scale of the change that is on the way next year, because from all available information it’s looking like the default Windows 8 experience will be VERY different from anything that Windows users have experienced in the past.

This suspicion was confirmed recently when Microsoft posted a video entitled “Building Windows 8 – Video 1” on one of their development team blogs. The video was also uploaded to YouTube, and I’ve embedded it in this post … take a look:

As you can see the default Windows 8 experience is very different, and is sure to bring some new challenges for developers who want to deploy applications that take advantage of the new capabilities of the platform. From Microsoft’s demonstration it is clear that traditional Windows applications will continue to be supported, so there is no need to panic, but as software developers we all need to be thinking about how a change of this magnitude could affect our businesses.

For some time now Microsoft has touted WPF and Silverlight as the flagship technologies of choice for building UI’s for .NET applications. But with Windows 8 is all that about to change? The video makes it clear that the primary UI technologies used to build Windows 8 applications are HTML5 and JavaScript, neither of which have a particularly strong toolset presence in Visual Studio 2010. So for many of the developers at the Build Windows conference the main question will be “what’s new in Visual Studio 2012 and .NET Framework 4.5 that will help me build applications for Windows 8?”.

Clearly Microsoft believe that mobile and tablet devices are going to become far more predominant in the future, and are actively planning for this by merging the various operating systems that are used on the various types of computing platforms. And of course they are not alone in this endeavor as Apple’s recent release of OS X Lion also somewhat takes this approach, although not quite to such a radical degree.

Of course there is another group of people who also have a bunch of work to do, and that’s the hardware vendors. If Windows 8 is to be successful one would assume that the default for personal computer and laptop screens will need to change to be predominantly touch-enabled devices. While it is clearly stated in the video that the new UI will work just fine with a mouse and a keyboard, I for one am very skeptical about how WELL it will work in that mode! And of course the availability of the hardware is only a part of the story … we must also consider how long it will take companies to replace existing hardware with new touch-sensitive devices.

Now don’t get me wrong … I’m not suggesting for one minute that there will be a big rush to do so, and I’m absolutely suggesting that a major change of this type could take many years … but for some of us, with certain types of applications, in certain market places, adopting these new capabilities could offer significant rewards.

By the way, I’m not a betting man but I’d lay good money on the fact that there will be a setting to disable the new Windows 8 UI in favor of reverting to Windows 7’s Aero UI, and I’d also be comfortable predicting that many corporations will be doing just that. So again, don’t panic! While the new UI may make for a fabulous demo, and may be a fantastic way of interacting with photos and videos, and browsing the web, will it really provide a suitable platform for presenting business software to commercial users? Actually, in some cases the answer will be a resounding YES … but in other cases the more traditional approach to presenting applications will continue to be far more appropriate.

Of course in order for Synergy developers to be ready for Windows 8, Synergex must be ready first. I will be attending the Build Windows conference, as will three of my colleagues from the Synergy Development team. We’ll do our best to keep you informed about what we learn.

By the way, if you’re interested in keeping track of what’s going on with Windows 8 then a good place to start is Microsoft Development’s Building Windows 8 BLOG. The blog has some interesting articles, and already has several more videos discussing these new features.


All Hooked Up. (Circa 1957, Elvis Presley)

By Richard Morris, Posted on July 19, 2011 at 9:25 am

Avatar

Back in the day, Elvis Presley shook up a bit of a stir when his gyrating hips and dulcet tones came over the airways onto our little black and white TVs (so I was told, I’m not old enough!).  Today, Synergex is defining a development that will shake the Synergy world when it’s released with an upcoming version!  And it’s a development that we’ll all be hooked on.

In the specification phase at the moment is the ability to “hook” user definable logic against operations within the SDBMS file IO system.  This proposal offers the ability to perform logic when any operations on any SDMBS file (index or relative)  are executed.

For example, you can hook up a Synergy method that will be called “before” a record is read from a file, or before a record is stored into a file.  A method can be hooked up and executed when a record lock is encountered, records deleted or updated.

The possibilities are truly endless.  You could use this capability to debug your applications.  For example, you may have a system that occasionally encounters corrupt data – and you have no idea when the data got corrupted.  By implementing pre-store and pre-write event hooks you could validate the data and log to a file if it’s not valid.  Because it’s a Synergy method, in the calling stack, you can use routines like MODNAME to record the full stack trace and pinpoint the problem.

Implementing hooks for the pre-store and pre-update events can allow you to ensure that default data is correctly set.

Hooking up post-events could allow you to record modifications to your SDBMS data that you wish to replicate somewhere – in a third party relational database for example.  Or you could actually record the data being sent to a file for transaction/logging purposes.

All hooks will be on a per-channel basis, so if you currently have a generic file open routine you’ll be well placed to begin to implement this new exciting capability.  If you don’t, now’s the time to start thinking of adding one!

One thing to remember, performance!  Once you have bound a hook to an event then every operation of that type will cause your logic to be executed, so keep the code concise, specific and efficient!!

This development, for me, is on a par with the .NET API – it’ll open up a whole new world of possibilities.  I can’t wait to get hold of the alpha release so I can blog about it, and watch out for the early videos showing you the full power of this great new development.  And the best bit is that it’ll be supported on ALL platforms, so you won’t have to be a .NET guru to take full advantage!  I can already feel an SPC session in the making.

I’m hooked, line a sinker!


Hosting WCF Services in an ASP.NET Web Application

By Steve Ives, Posted on July 1, 2011 at 3:39 pm

Steve Ives

There are several ways that you can use Synergy/DE tools to expose WCF services, but regardless of which way you decide to create a service, the next decision you have to make is how to host it. By hosting a WCF service you expos the service and make it possible to use it from other applications. In this post I will introduce you to one way that WCF services may be hosted, via an ASP.NET web application and an IIS web server. In a later post I will show you how to host WCF services without this requirement for an IIS web server.

This is the third in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application (this post)
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

 

A WCF service is simply a collection of one or more classes in an assembly, but the whole point of implementing a WCF service is to make those classes available to be used by other applications. And those applications will often be located on different networked systems from the service itself. So, in order for a WCF service to be useful, it needs to be “hosted” somewhere, and that somewhere needs to be available on a network.

There are three basic ways that WCF services can be hosted:

  1. Inside a Web application located on a Web server.
  2. Using Windows Process Activation Services (WAS). This mechanism was introduced in Windows Server 2008 and provides a mechanism for hosting WCF services without requiring a Web server.
  3. Services can be “self” hosted by some custom .NET application. For example, developers often host WCF services inside a Windows Service application.

In this post I will show you the basics of hosting a WCF service in an ASP.NET web application. In a future post I will go on to show how to self-host services.

Setting up basic hosting for a WCF service inside an ASP.NET Web application is very easy, but as Synergy .NET doesn’t have support for creating Web applications. You’ll have to use another .NET language, either C# or VB.NET. However, don’t worry about that too much, because there won’t actually be any code in the Web application!

  • Start Visual Studio 2010 and create a new ASP.NET application:
    • From the menu, select File > New > Project.
    • Under Installed Templates, select Visual C# > Web > ASP.NET Empty Web Application.
    • Chose the name and location for your new Web application.
    • Click the OK button to create the new project.
  • Add a new WCF Service to the project:
    • From the menu, select Project > Add New Item.
    • Under Installed Templates, select Visual C# > Web > WCF Service.
    • Enter the name for your new service. The name will be part of the service endpoint URI that the client connects to, so pick something meaningful. For example, if your service allows orders to be placed then you might name the service something like OrderServices.svc.
    • Click the Add button to add the new service to the project.

You will notice that three files were added to the project:

image

 

In addition to the service (.svc) file that you named, you will see two C# source files. These files were added because Visual Studio provided all of the files that you would need in order to expose a new WCF service that would be manually coded in these files. But what we’re trying to do is host a WCF service that already exists in another .NET assembly.

  • Delete the two C# source files by right-clicking on each and selecting delete.

In order to expose a WCF service that exists in another assembly, the first thing we need to do is add a reference to that assembly, to make the classes it contains available within the new Web application.

  • From the menu select Project > Add Reference and then select Browse.
  • Locate and select the assembly containing your WCF service and add a reference to your project.
  • If the assembly you selected was created using xfNetLink .NET then you will also need to add a reference to the xfnlnet.dll assembly, as is usual when using xfNetLink .NET

You’ll need to know that namespace and class name of the WCF service in your assembly. If you can’t remember this that double-click on the assembly that you just referenced and then use Object Browser to drill into the assembly and figure out the names. All that remains is to “point” the service file at your WCF service class.

  • Double-click on the service (.svc) file to edit it. You should see something like this:

image

Edit the file as follows:

  • Change Language=”C#” to Language=”Synergy”.
  • Change Service=”…” to Service=”YourNamespace.YourWcfClass” (obviously replacing YourNamespace and YourWcfClass with the namespace and class name of your WCF service).
  • Remove the CodeBehind=”…” item … there is no code-behind, the code is all in the other assembly.
  • Save the file.

So you should now have something like this:

image

If your service is based on an assembly created using xfNetLink .NET then you have one final configuration step to perform. You need to tell xfNetLink .NET how to connect to xfServerPlus. You can do this by using the Synergy xfNetLink .NET Configuration Utility (look in the Windows Start Menu) to edit the new web applications Web.config file. If your xfServerPlus service is not on the same machine as your new web application then you must specify a host name or IP address, and if xfServerPlus is not using the default port (2356) then you must also specify a port number. When you’re done, the Web.config file should contain a section like this:

image

That’s it, you’re done. You should now have a working WCF service!

  • To see if the service has really been hosted, right-click on the service (.svc) file and select View In Browser.

You should see the service home page, which will look something like this:

image

If you see this page then your service is up and running. By the way, the URI in your browsers address window is the URI that you would use to add a “Service Reference” to the service in a client application … but we’ll get on to that in a later post.

Of course, all we have actually done here is set up a web application to host a WCF service, but we’re using Visual Studio’s built in development web server (Cassini) to actually host the service. If you were doing this for real then you’d need to deploy your new web application onto a “real” IIS web server.

We’re not done with the subject of hosting WCF services; in fact we’ve only really scratched the surface. One step at a time!

In my next post in this series I will show you how to Expose a WCF services using Synergy .NET Interop.


Exposing WCF Services using xfNetLink .NET

By Steve Ives, Posted on at 1:40 pm

Steve Ives

Following a recent enhancement to the product in Synergy 9.5.1, developers can now use xfNetLink .NET to create and expose Windows Communication Foundation (WCF) services. In this post I will describe how to do so.

This is the second in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET (this post)
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

 

The basic approach is pretty easy; in fact it’s very easy. In 9.5.1 we added a new -w command line switch to the gencs utility, and when you use the new switch you wind up with a WCF service. I told you it was easy!

So, what changes when you use the gencs –w switch? Well, the first thing that changes are the procedural classes that are generated, the ones that correspond to your interfaces and methods in your method catalog, change in the following ways:

  1. Three new namespaces (System.Runtime.Serialization, System.ServiceModel and System.Collections.Generic) are imported.
  2. The class is decorated with the ServiceContract attribute. This identifies the class as providing methods which can be exposed via WCF.
  3. Methods in the class are decorated with the OperationContract attribute. This identifies the individual methods as being part of the service contract exposed by the class, making the methods callable via WCF.
  4. If any methods have collection parameters, the data type of those parameters is changed from System.Collections.ArrayList to System.Collections.Generic.List. Changing the collection data type is not strictly necessary in order to use WCF, but results in a more strongly prototyped environment which is easier to use, and offers more benefits to developers in terms of increased IntelliSense, etc.

The next thing that changes are any data classes, the ones that correspond to the repository structures that are exposed by the parameters of your methods, that are generated. These data classes change in the following ways:

  1. Two new namespaces are imported. These namespaces are System.Runtime.Serialization and System.ServiceModel.
  2. Each data class (which corresponds to one of your repository structures) that is generated is decorated with the DataContract attribute. This identifies the data class as a class which can be used in conjunction with a WCF service, and which can be serialized for transmission over the wire.
  3. Each public property (which corresponds to a field in the structure) is decorated with the DataMemeber attribute. This attribute identifies each property within the class as one which will be serialized, and as a result will be visible to client applications which use the WCF service.

By the way, if you use a Workbench “.NET Component Project” to create your xfNetLink .NET assemblies then there isn’t currently an option in the component information dialog to cause the new –w switch to be used. So, for the time being, what you can do is add the switch to the Workbench “Generate C# Classes” tool command line. To do this you would go into project properties for the component project, go to the Tools tab, select the “Generate C# Classes” tool, then add the –w at the end of the command line, like this:

image

We’ll be adding a new checkbox to the component information dialog in 9.5.3 later this year.

By the way, by using the gencs –w switch you make it possible to use the resulting classes as a WCF service, but you don’t have to do so … you can continue to use the classes as a regular xfNetLink .NET assembly also. Why would you want to do that? Well, I sometimes use gencs –w just to turn my collection parameters into generic lists!

I have submitted a working example to the Synergy/DE CodeExchange, contained within the zip file called ClientServerExamples.zip. Within the example, the following folders are relevant to exposing and consuming a WCF Service using xfNetLink .NET:

Folder / Project

Description

xfServerPlus

Contains the Workbench development environment for xfServerPlus and the exposed Synergy methods. If you wish to actually execute the examples then you must follow the setup instructions in the readme.txt file.

xfNetLink_wcf

Contains the Workbench project used to create the xfNetLink .NET client assembly with the WCF attributes.

3_xfpl_xfnl_wcf_service

Contains the Visual Studio 2010 solution containing an ASP.NET web application used to host the WCF service, as well as three example client applications, written in Synergy .NET, C# and VB.

So, the gencs –w command line switch you make it possible to use the resulting classes to directly expose a WCF service, but there is still the matter of how to “host” the service in order to make it accessible to remote client applications, and that’s what I will begin to address in my next posting.


Optimizing your Visual Studio 2010 Experience

By Steve Ives, Posted on June 22, 2011 at 3:52 pm

Steve Ives

Visual Studio 2010 is one of the best IDE’s I have ever seen and worked with, and provides, out of the box, a truly impressive array of tools to make developers lives easier and more productive. But, as good as it already is, there is still room for improvement.

Luckily Microsoft has provided an extensible platform and an easy way for people who develop extensions to be able to publish those extensions to developers. Check out the “Extension Manager” utility that you will find on the Tools menu.

emThe extension manager, as suggested by its name, provides a simple UI which allows you to locate, download and install all kinds of Visual Studio extensions. The actual extensions are hosted on-line at a web site called the Visual Studio Gallery. Some extensions are written by Microsoft, some by third-parties. Some provide additional functionality throughout Visual Studio, while some are specific to a particular language. Some add new project or item templates to Visual Studio, while others add complex capabilities in a range of scenarios.

Go take a look, there are a lot of extensions to choose from. If you’re looking for recommendations then personally I think that there are two extensions that no Visual Studio 2010 developer should be without … apart from the Synergy Language Integration for Visual Studio extension of course. You’ll find these extensions in the gallery, and if you sort the list by “Highest Ranked” then they should be close to the top of the list … they are VERY popular! My favorite extensions are both published by Microsoft, and both are free. They are called:

· Productivity Power Tools

· PowerCommands for Visual Studio 2010

I won’t even attempt to go into detail about what these extensions do, because the list of enhancements is a long one. You can click on the hyperlinks above and read all about them in the gallery. Suffice it to say that if for some reason I wind up working on a system other than my own laptop, and these extensions are not installed, I miss them both terribly!


Building Distributed Apps with Synergy/DE and WCF

By Steve Ives, Posted on at 1:22 pm

Steve Ives

At the recent SPC’s in Chicago and Oxford several of the sessions that I presented were focused on networking, and in particular on the various tools and technologies that are available to Synergy developers to allow them to build and deploy distributed software applications. In particular I spent quite a bit of time talking about a technology called Windows Communication Foundation.

This is the first in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF (this post)
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

What is WCF

WCF is a part of the .NET framework that provides a powerful and flexible way to implement network communication between the various parts of a distributed software application. For many years Synergy developers have been able to build distributed applications using xfServerPlus and xfNetLink. Many have done so, and have deployed a wide variety of applications based on these technologies. When developing a new .NET client application developers would use xfNetLink .NET to gain access to their Synergy business logic and data.

This approach has served us well over the years, will continue to do so, and is still the most appropriate solution in some scenarios. But in some other scenarios using WCF might now be more appropriate, and could help developers to broaden the capabilities of their applications in several key areas, some of which are:

WAN Communication

Because the communication between xfServerPlus and xfNetLink uses a custom protocol which operates on a “non-standard” port, it may not be appropriate for use over wide area networks and the Internet. The primary problem here is that there is a high chance that this communication would be blocked by firewalls, some of which may be outside of your control. WCF supports multiple network transport protocols, the most basic of which is HTTP. This means that it is designed with the Internet in mind, and is very suitable for implementing applications which communicate over the Internet.

Multiple Endpoints

Another advantage of WCF is that the same WCF service can be exposed via multiple “endpoints”, and each of these endpoints can be configured to use different communication protocols and mechanisms. For example a single service could be exposed via one endpoint which uses HTTP and SOAP which would be suitable for a wide variety of client applications to be able to access from anywhere (including via the Internet), while at the same time being exposed by a second endpoint which uses low-level TCP/IP communications and binary messaging protocols suitable for use by applications running on the same local network as the service, at much higher performance. A single client application could even be configured to dynamically switch between these endpoints based on the current location of the user.

More Client Options

When using xfServerPlus and xfNetLink, client applications must be written in a programming language which is able to use one of the supported xfNetLink clients (COM, Java or .NET), but because WCF services can be interacted with via “standard” protocols such as HTTP and SOAP there are many more client application possibilities, because almost all development environments and programming languages are able to use these basic protocols.

Asynchronous Support

WCF also provides the ability to easily support asynchronous communication between clients and servers. When a client application calls an xfServerPlus method the client must wait for the execution of the method to complete, and for any resulting data to be returned, before performing any other processing. Using WCF it’s easy to support asynchronous method support, where the client application can call a method and then continue with other processing, later receiving an event when the remote method has completed its operation and when any resulting data is ready for use. This approach can make client applications appear to be much more dynamic and responsive.

Bi-Directional Communication

In many distributed software applications interaction between the client and the server is initiated by some event in the client application which requires some subsequent processing in the server application. But in some situations it is necessary for the server application to be able to, at will, initiate some processing in the client application. Unfortunately xfServerPlus and xfNetLink don’t really address this use case, but it can be addressed with WCF, because WCF service endpoints can be “self-hosted” within any type of .NET application. This means that as well as a client application having the ability to interact with a WCF service on some server somewhere, the client can also expose a WCF service, which the server application (or in fact any other application) could interact with.

WCF is an extensive subject area, and in this BLOG I’m not even going to attempt to teach you about the specifics of using WCF. Instead I’m simply going to try to make you aware of some of the reasons that you might want to explore the subject further, and make sure that you know about the various ways that you can get started.

There are several ways that Synergy developers can utilize WCF in their applications, and I’ll briefly describe each of these mechanisms below.

WCF via xfNetLink .NET

In xfNetLink .NET 9.5.1 a new feature was introduced which gives developers a lot of additional flexibility in the way that they build their applications, or rather the way that they communicate between the various parts of the application. This new feature is enabled through a new command line parameter to the gencs utility (-w). When you use this new option, two things change.

When you use gencs –w, the first thing that changes is that various attributes are added to the wrapper classes that are created by gencs. These attributes in turn allow those generated classes (and the assembly that they are compiled into) to be directly exposed as a WCF service. Previously, if a Synergy developer wanted to expose a WCF service which in turn exposed their Synergy business logic and data, they have to manually “wrap” their xfNetLink .NET procedural and data classes in other classes which in turn exposed a web or WCF service.

The second change when using gencs -w is that any collections which are exposed by the application API are transformed from un-typed “ArrayList” collections, to more useful and flexible “Generic List” collections. This change will require a small amount of re-coding in any existing client applications, but results in a significantly enhanced development experience.

This mechanism is likely to be of interest to developers who already have an existing solution using xfNetLink .NET and xfServerPlus, and want to take advantage of some of the additional capabilities of WCF, or to developers who wish to expose a new WCF service where the server application exposes code running on a UNIX, Linux or OpenVMS server.

WCF via Synergy .NET Interop

Another way that Synergy developers can expose WCF services is via Synergy .NET’s “Interop” project. The primary purpose of an Interop project is to allow developers with existing xfServerPlus applications to migrate their existing Synergy methods to a native .NET environment. By adding their method source code to an interop project they are able to execute those methods directly in the .NET environment, instead of using xfNetLink .NET and xfServerPlus to execute the methods with traditional Synergy on a remote server.

The Interop project works by generating Synergy .NET “wrapper classes” for your traditional Synergy methods (subroutines and functions) and data structures (records). The external interface of these wrapper classes is very similar to that of the C# wrapper classes produced by xfNetLink .NET’s gencs utility. The primary goal of the Interop project is to allow developers to migrate existing applications from a mixed .NET / traditional Synergy environment to a 100% .NET environment, with only minor changes to the code of existing client applications.

When you create an Interop project in Visual Studio, one of the options that you have (via the project properties dialogs) is to “Generate WCF contracts”, and as discussed earlier in this article, the effect of this is to add various attributes to the generated wrapper classes so that they can be directly exposed as a WCF service.

So again, for Synergy developers, this approach can provide a quick-and-easy way to expose a WCF service based on existing code. Again, this approach is likely to be primarily of interest to those who already have xfServerPlus based applications running on the Windows platform.

WCF via Synergy .NET

Both of the previous approaches were primarily focused on those who already use xfServerPlus, and both provide an easy way to get started with WCF. However in both of the previous scenarios, the external interface of your WCF service is directly defined by the interface to your underlying traditional Synergy methods (subroutines and functions), and the WCF data contracts that are exposed are defined by the repository structures exposed by the parameters of those methods. So, while the WCF capabilities provided by xfNetLink .NET and by the Synergy .NET Interop project are easy to use, you don’t get full control over the exposed interface and data. If you want that finer level of control, or if you’re just getting started with server application development and don’t have existing xfServerPlus methods, there is a better way to go.

The third way that Synergy developers can leverage WCF is by using Synergy .NET to create an all-new WCF service with native .NET code. This task was possible in 9.5.1 when Synergy .NET was first introduced, but has been made much easier through the introduction of a new “WCF Service Library” project template in 9.5.1a.

Creating a new WCF service via a WCF Service Library is the way to go for developers who want to write an all-new service application, or who don’t mind a little extra effort to re-work some existing code in order to factor out some of the “wrapper” layers involved with the previous two approaches. As a result you will have full control of the resulting WCF service, and the contracts that it exposes.

Wrapping Up – For Now

So, as you can see, Synergy/DE is now providing you will all kinds of new and exciting things that you can do in your Synergy applications, and I firmly believe that WCF is one of the most important, and powerful. In the near future I will be writing several additional BLOG posts which will explain these three ways of exposing WCF services in more detail, and I’ll also try to provide more detail about WCF generally. So for now, be thinking about how your existing distributed applications are built, and what things you might wish to improve about them. Or be thinking about that all-new distributed application that you’ve wanted to get started on. If you’re thinking of enhancing or implementing a distributed application, then using WCF is almost certainly the way to go.


Shameless plug

By William Hawkins, Posted on March 28, 2011 at 4:38 pm

Avatar

I’ve just come back from the UK, where Richard Morris and myself attended DevWeek 2011.   The DevWeek conference was hosted at the Barbican center in London, and covered a multitude of various Microsoft / Windows technologies. As it wasn’t hosted by Microsoft, there were no significant goodies/toys given away, but we did gain a lot of great info on developing state-of-the-art user interfaces, and lose a few pounds climbing 4 flights of stairs between sessions.
After the conference, Richard and I visited a couple of customers and had planned to spend a couple of days performing analysis work for a prospective PSG project.  However, a few hours into this analysis task, we got a cry for help from another UK customer that Richard had been working with.
This customer was in the process of moving their application from OpenVMS to Windows.  They had already moved the executables to Windows and were using xfServer to access the data on OpenVMS.  Over the weekend that followed DevWeek, Richard had helped them do a test migration of the data from OpenVMS RMS files to Windows SDBMS isam files, and it all appeared to be working fine.  However, during their testing, a few files were showing spurious data in a few fields – hence the cry for help.
It turns out that the bad data was actually caused by integer fields, that everybody had assumed were decimal fields.  Now, when you unload data files, most people just use the standard isload/fconvert (or Convert on OpenVMS) to generate a sequential file, which works great for Synergy alpha and decimal fields, but when you have integer (aka binary) fields, regular sequential files no longer “cut the mustard”.  One of the issues you have to deal with is this.  If you have an integer field that contains the value 13, (aka a Carriage Return character) in a sequential file, the operating system assumes that it’s an end-of-record character and treats the record as truncated.  So now the next part of the same record is now treated as a new truncated record, and you have two “bad” records in the file, instead of one “good” one.
The way to resolve this class of issue is to use a “counted” file.  This is a special form of sequential file where the length of the record is included with each record, so when re-loading data, the application knows how many characters there are in the record, and it will ignore any “spurious” control characters in the middle of the record.   Job done, you would think, but no.  Being OpenVMS it wasn’t as simple as that, as we also had to use the OpenVMS Convert utility to change the sequential file into a stream file, so we can preserve the file as a counted file after it was FTP’d to Windows.

With Synergy version 9, the language supports several new data types (e.g. boolean, enum) which are really integer fields, so if you start to store these new data types in your Synergy DBMS files, you need to start using counted files, instead of regular sequential files when loading/unloading data.  Fortunately, (in this case) both OpenVMS and Windows are little endian systems, so there was no issue about changing endian type, but this is something that you may need to consider, should you consider moving integer data between systems.
Now, to come back to the topic I started with of “attending conferences” (and to issue a shamless plug), if you come to the 2011 SPC in Chicago or Oxford, you’ll be able to hear all about managing binary data in Synergy DBMS files.

Hope to see you there.


Free Stuff!

By William Hawkins, Posted on March 14, 2011 at 2:46 pm

Avatar

It’s a rare occasion where anything is truely free. Most of the time it’s simply a way for a marketing company to obtain information about you, so they can provide (or bombard) you with information about products that you have no interest in purchasing. However, there are some occasions when “free” really does mean that there’s no additional cost. The Synergex CodeExchange is (IMHO) one of those gems.
In may last blog, I discussed the process of validating a large number of the CodeExchange submissions with Synergy 9.5 and Synergy for .Net. In this blog, I want to highlight a couple of new submissions that you may find useful.

SynArrayList – this submission contains a couple of subroutines that allow you to sort an ArrayList in Synergy, either using a bubble sort or dynamic memory/qsort. You probably won’t need to use both methods of sorting, but they provide code examples to allow you to create custom sort routines of your own. This submission also contains an example of extending the ArrayList class, and creating a new class that processes Synergy alpha types natively.  This allows you to avoid the requirement to box/unbox your alpha variables as you process a collection.  Of course, the underlying arraylist still requires object types, but you don’t have to be concerned about that. And it has sort() and reverse() methods and some other ArrayList method that are part of the ArrayList class in .NET

SourceTree – this submission builds a utility that will parse your source code, and generate a data file that records the subroutine/functions in your application that call other subroutines/functions.  This allows you to create documentation on where routines are used in your application.  It can also be used to generate a list of routines called by a particular subroutine/function/mainline and all the routines that are called by those routines.

I’m also working on some other CodeExchange submissions – examples include a file I/O class and a utlity to create the xfNetLink attributes that can decorate your code.  Watch this space!!!


Mapped drives and Synergy

By Roger Andrews, Posted on January 31, 2011 at 4:27 am

Avatar

Some recent posts on our synergy-l listserv made me realize there are still some misperceptions about Microsoft network shares (mapped drives), so I thought I would address those here.

Microsoft designed network shares for single-user access to shared resources such as Word documents. The locking and caching algorithms they use assume that a local cache is desirable since multiple users are unlikely to do concurrent updates (though the algorithms try to cope with this situation). Of course the use of network shares has grown to much more than single-user systems. Many of our customers have used them and are still using them, and many of these customers have unfortunately encountered performance and file corruption issues. Most of these issues are associated with concurrent updates and cache flushing, and using mapped drives (as opposed to UNC paths) seems to exacerbate the problem. With older Windows versions–prior to Vista and Server 2008–you can mitigate file corruption issues by disabling oplocks on the server (which disables the local caching). (Syncksys, a utility we used to check settings on these older Windows systems, always checked for this.) Unfortunately, you can’t disable oplocks with SMB2 redirectors on the newer Windows systems.

Because of the number of issues our customers have encountered, Synergex can provide only very limited support for Synergy database access through network shares. (See the Synergex KnowledgeBase article listed below.) We have traced these problems to errors in the Microsoft SMB (mrxsmb10.sys, mrxsmb20.sys, mrxsmb.sys) and Redirector (rdbss.sys, srv.sys) subsystems.  We find that these problems get worse with network shares over a WAN and with multi-user access. It is fair to say that Microsoft has fixed many problems with Windows XP and Server 2003 over the years, but the problems have resurfaced with newer Windows operating systems. And now many organizations are using Windows Vista and Windows 7 machines as clients (alongside their Windows XP clients) to Server 2003 or Server 2008 servers, introducing newer operating systems with mapped drive subsystems that have regressed in functionality and performance.

Here is a great link to a Microsoft article for the latest hot fixes available for the network share subsystem: https://support.microsoft.com/kb/2473205 (for Windows Vista onwards)

https://blogs.technet.com/b/yongrhee/archive/2011/06/12/list-of-post-sp3-related-hotfixes-for-windows-xp-sp3.aspx (Windows XP)

Synergex has published the following KnowledgeBase article on the subject of network shares: https://resourcecenter.synergex.com/devres/kb-details.aspx?id=1811

This same information (from the KB article) was also published as an article in the 26 August 2010 edition of Synergy-E-News: https://www.synergex.com/ecards/20100826.html#mapped

We recently (and mistakenly) used a mapped drive internally for a project, and the ISAM files for the project were continually corrupted. (We have logged a premier support call to Microsoft for this issue.) We fixed the corruption with the recommended solution, xfServer, which not only solved the issue but improved performance.

File corruption issues aside, in most cases xfServer will significantly outperform a mapped drive in commercial situations with multi-user access when it’s set up to correctly use SCSCOMPR and SCSPREFETCH in conjunction with correctly opening files for input when just reading data sequentially. The known cases where xfServer is slower than a mapped drive is when a file is opened for update with a single user or exclusive access, or for output when the file is not large and/or the records are small (or ISAM compression makes them small), allowing the redirector to cache the data blocks locally. If oplocks are turned off on Server 2003, as recommended, this caching is disabled and performance degrades, though reliability increases. We are investigating an xfServer performance improvement that would provide comparable or better performance than a mapped drive in additional scenarios by allowing users to enable the cache on stores and writes to a file opened for output, append, or exclusive access.

We have provided a test utility in CodeExchange, IsamBenchMark, to help you test performance with your own physical files and network.  Using this utility, we saw the results described below.

The following tests were made on a Windows 7 machine connected to another Windows 7 machine over a 1 GB network. The machines each had 6 GB of memory and Core 2 3GHz CPUs. The Windows operating system cache was flushed using the Sysinternals CacheSet utility before each run on the server machine. Neither machine had an antivirus program running or any other software that accessed the network. Both machines were connected on the same physical switch.

Two files were used: one with eight keys and 128-byte records and the other with eight keys and 512-byte records. Each file was filled with 100,000 records during the test, and the files were created without ISAM file compression. We used Task Manager’s networking tab to generate the diagrams below (though we’ve added red vertical lines in one diagram).

Diagram 1 shows network overhead for our first test, which used xfServer to access the file with 512-byte records. The file was first accessed without compression and then with compression (i.e., with SCSCOMPR set). 

 

Using 4-5% of a gig link is equivalent to 50% of a 100 MB Ethernet, so the performance gained by setting compression for xfServer would be even greater on a slower Ethernet or WAN.

Diagram 2 shows network overhead for our second test, which accessed the 512-byte-record file in three ways:

  • via a mapped drive
  • using xfServer without compression
  • using xfServer with compression and READS prefetch support enabled (i.e., with SCSCOMPR and SCSPREFETCH set)

The test program stored 100,000 records, re-opened and used random read for 100,000 records, re-opened and used reads for 100,000 records. Note the change in scale from the previous diagram, and note the overhead of the stores is high (with the flush-on-close peaking with the mapped drive). The next segment is the random read, and then the next peak is the reads. Also notice the setup with SCSCOMPR and SCSPREFETCH makes the reads almost as fast as a local disk access and far faster than the mapped drive.

 

If this had occurred over a slower network, the stores would be slower on a mapped drive than xfServer and the SCSCOMPR form would outperform all other methods, given records with some degree of compression. If you have an ISAM file with ISAM compression, isutl –v can give you an idea of how much compression of the data can help with xfServer.

Diagram 3 shows network overhead when accessing the file with 128-byte records in the same three ways (mapped drive, xfServer without compression, and then xfServer with compression) and with the same program.

 

Diagram 4 shows the network overhead for… Well, there is no diagram 4. Our final test used two systems each with the remote 512-byte-record file opened on the network share. One just had the file open. The other ran the test. This setup used 50 MB of bandwidth constantly for several minutes, so the diagram would run off the page and would show only a pegged green line. Instead, here’s a table that summarizes our findings. The last row documents the results for the multi-user mapped drive setup and illustrates how much worse things get when using a mapped drive in a multi-user environment. Bandwidth is quickly overloaded, and it becomes difficult and time consuming for the network to accommodate large groups of packets. As pointed out earlier, these tests used a physical switch. xfServer becomes even more important when the network involves a hub.

 

Store
(in seconds)

Random read
 (in seconds)

Reads
(in seconds)

Mapped drive 1user

21

7

4

xfServer no SCS_COMPR

24

24

2

xfServer SCS_COMPR

21

20

.90

Mapped drive 2 user

882

193

32

One final thing to be gleaned from this is that running programs that transfer large amounts of data across a network, programs such as month-end or day-end processing or reports, can quickly overload a network. Do what you can on the server by using xfServerPlus, the new Synergy Language Select class, or by running the program on the server.

If your xfServer system is not performing in line with the results described above, I encourage you to contact our Developer Support team so we can assist you in optimizing your system. If you have questions or would like more information on this topic, contact Synergy/DE Developer Support or your account manager.

On this topic, a customer recently reported an ELOAD/System error 64, “The specified network name is no longer available.” When they changed the UNC path to use the IP address rather than the name of the machine, the problem appeared to be resolved. This would suggest poor DNS server performance lookups was causing the error. It appeared the problem was disconnecting client machines on the network, as well as the recovery mechanism used by the re-director after such a failure. In the recovery mechanism, it appears DNS must also work. The problem with DNS is that Microsoft caches “Failures” of DNS, so one failure can cause other issues.

 


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives