Open Menu

Synergex Blog


Build RESTful Web APIs at the DevPartner Conference

By Steve Ives, Posted on February 23, 2017 at 10:23 pm

Today we published the agenda for the 2017 DevPartner Conference which will take place in Atlanta, GA the week of Monday May 8th; we hope you can join us. The main conference will be a three-day event from Tuesday May 9th through Thursday May 11th. And similar to other recent conferences we will be offering both pre- and post-conference workshops on Monday 8th and Friday 12th respectively. I will be hosting the pre-conference workshop entitled “Building RESTful Web Services with Synergy .NET and ASP.NET Web API”. My colleague Richard Morris will be presenting the post-conference seminar entitled “Building Platform-Independent Mobile Apps with Xamarin Forms”. Of course we hope you can join us for both workshops, but for the remainder of this article I will be focusing on providing information about the pre-conference RESTful web services workshop.

Building and implementing web service APIs isn’t exactly new, but there are definitely some new and exciting technologies in play that can make building, deploying and interacting with web services faster, easier and more powerful than ever. With the relentless increase in demand for mobile applications and solutions the requirement to expose web service APIs is greater than ever. Not that web service API’s are only used to support mobile applications, that is certainly is not the case. In fact almost any new application developed today is likely to either require the use of a web service API, or it will just make sense to architect the application that way for increased flexibility and future-proofing.

I’m developing the content for my workshop right now and I wanted to give you some information about the audience that I am targeting, which is very broad. To be honest, unless you are already implementing RESTful web service APIs then this workshop is for you! And even if you ARE already implementing RESTful web services APIs, but with some technology other than ASP.NET Web API, then this workshop is also for you! In my opinion it is really important that every developer have at least a good understanding of what a RESTful web service APIs are and how they can be used, and it sure doesn’t hurt to know how to build them either! This workshop will teach you all of those things, and more.

We will start with the basics and will not assume any previous knowledge of web services. After an introductory presentation there will be lots of code, so you will need to be comfortable with that. I don’t want to just show you how to build a RESTful web service API, I want you to really understand what it is and how it works. So as well as covering ASP.NET Web API we will also be talking about the basic principles of REST, as well as various underlying technologies like HTTP, JSON and XML. If it all works out as planned it should be an action packed and interesting day.

This year both of the full-day workshops will be lecture and demonstration based; there won’t be any hands-on component. Unfortunately the hardware and software requirements of the underlying technologies that we will be using, particularly in the post-conference workshop, make it virtually impossible for us to offer a hands-on experience this time around. But rest assured that you will have access to all of the code that is developed and demonstrated, and we’ll make sure that you know exactly what hardware and software you will need if you want to work with that code, or perform your own similar development projects.

Time is ticking away and DevPartner 2017 is only about 10 weeks away. We’re all looking forward to seeing you again, or meeting you for the first time, and if you haven’t done so already then it’s time to register. See you there!


Why is That First WCF Operation SO Slow?

By Steve Ives, Posted on June 25, 2015 at 12:06 pm

If you have ever developed and worked with a WCF service you may have noticed that the very first time you connect to a newly started instance of the service there can sometimes be a noticeable delay before the service responds. But invoking subsequent operations often seems almost instantaneous. Usually the delay is relatively short, perhaps even just a fraction of a second, but still noticeable. Well earlier this week I encountered a WCF service that exhibited this behavior, but the delay for the first operation was almost three minutes! Something had to be done.

Some time later, after much debugging, web searching and more than a little head scratching, we realized that the “problem” that we were seeing was actually “by design” in WCF and was related to the generation of metadata for the service. It turns out that if “metadata exchange” is enabled for the service then WCF generates the metadata, regardless of whether anyone is currently requesting it or not, at the time that the first operation is requested by a client. Often the generation of the metadata takes almost no time at all, but as the size and complexity of a service grows (in terms of the number of operations exposed, the number of parameters, the number and nature of complex types exposed, etc.) the time taken to generate the metadata grows. In the case of this particular service there were over 800 individual operations defined, with lots and lots of complex types being exposed, and the service was still growing!

The only time you need metadata exchange enabled is when you need to access the WSDL for the service, so in simple terms whenever you need to do an “Add Service Reference” or “Update Service Reference”. The rest of the time having it enabled is just slowing things down at runtime.

I can’t tell you exactly how to enable and disable metadata exchange with your service, because there are several different ways it can be configured, but it’s likely going to be one of these:

  1. A <serviceMetadata/> token used in the <serviceBehaviors> section of a Web.config or App.config file.
  2. An <endpoint/> token that uses the IMetaDataExchange contract defined in a <service/>section of a Web.config or App.config file.
  3. Code that does the equivalent of one of the two options above.

So the lesson learned was to enable metadata exchange only when it is needed, for the purpose of creating or updating client proxy code; the result was an almost instantaneous response from the service once metadata exchange had been disabled. Of course it goes without saying that metadata exchange should NEVER be enabled on production services.


Old Dog … New Tricks … Done!

By Steve Ives, Posted on June 3, 2015 at 3:59 pm

The old adage tells us that you can’t teach an old dog new tricks. But after the last three days, I beg to differ! It’s been an interesting few days for sure; fun, challenging, rewarding and heated are all words that come to mind when reflecting on the last few days. But at this point, three days into a four-day engagement, I think that we may just have dispelled that old adage. For one this “old dog” certainly feels like he has learned several new tricks.

So what was the gig? It was to visit a company that has an extensive application deployed on OpenVMS, and to help them to explore possible ways to extend the reach of those applications beyond the current OpenVMS platform. Not so hard I hear you say, there are any number of ways of doing that. xfServerPlus immediately comes to mind, as do xfODBC and the SQL Connection API, and even things like the HTTP API that could be used to allow the OpenVMS application to do things like interacting with web services. All true, but there was one thing that was threatening to throw a “spanner (wrench) in the works”. Did I mention that the application in question was developed in COBOL? That’s right, not a line of DBL code anywhere in sight! Oh and by the way, until about a week ago I’d never even seen a single line of COBOL code.

Now perhaps you understand the reason that challenging was one of the words I mentioned earlier. But I’m up for a challenge, as long as I think I have a fighting chance of coming up with something cool that addresses a customers needs. And in this case I did. I didn’t yet know all of the details, but I figured the odds of coming up with something were pretty good.

Why all of this confidence? Well, partly because I’m really good at what I do (can’t believe I just said that), but seriously, it was mainly because of the fact that a lot of the really cool things that we developers just take for granted these days, like the ability to write Synergy .NET code and call it from C#, or write VB.NET code and call it from Synergy .NET, have their roots in innovations that were made 30+ years ago by a company named Digital Equipment Corporation (DEC).

You see OpenVMS had this little thing called the Common Language Environment. In a nutshell this meant that the operating system provided a core environment in which programming languages could interoperate. Any language that chose to play in that ball park would be compatible with other such languages, and most languages on OpenVMS (incuding DIBOL and DBL) did just that. This meant that BASIC could call FORTRAN, FORTRAN could call C, C could call PASCAL and … well you get the idea. Any YES it means that COBOL can call DBL and DBL can call COBOL. OK, now we’re talking!

So why is this such a big deal? Well it turns out that Digital, later Compaq, and later still HP didn’t do such a great job of protecting their customers investments in their COBOL code. It’s been quite a while since there was a new release of COBOL on OpenVMS, so it’s been quite a while since OpenVMS COBOL developers had access to any new features. This means that there isn’t a way to call OpenVMS COBOL routines from .NET or Java, there isn’t a way for OpenVMS COBOL code to interact with SQL Server or Oracle, and there isn’t an HTTP API … so don’t even think about calling web services from COBOL code.

But wait a minute, COBOL can call DBL … and DBL can call COBOL … so YES, COBOL CAN do all of those things … via DBL! And that fact was essentially the basis for my visit to Toronto this week.

I’m not going to get into lots of details about exactly what we did. Suffice it to say that we were able to leverage two core Synergy/DE technologies in order to implement two main things:

  1. A generic mechanism allowing COBOL code executing on OpenVMS to interact with Windows “stuff” on the users desktop (the same desktop that their terminal emulator is running on).
  2. A generic mechanism allowing Windows “stuff” executing on the users desktop to interact with COBOL code back on the OpenVMS system.

The two core technologies have already been mentioned. Outbound from OpenVMS was achieved by COBOL calling a DBL routine that in turn used the Synergy HTTP API to communicate with a WCF REST web service that was hosted in a Windows application running in the users system tray. Inbound to OpenVMS was of course achieved with a combination of xfNetLink .NET and xfServerPlus.

So just who is the old dog? Well as I mentioned earlier I probably fall into that category at this point, as do several of the other developers that it was my privilege to work with this week. But as I set out to write this article I must admit that the main old dogs in my mind were OpenVMS and COBOL. Whatever, I think that all of the old dogs learned new tricks this week.

It’s been an action packed three days but I’m pretty pleased with what has been accomplished, and I think the customer is too. I have one more day on site tomorrow to wrap up the more mundane things like documentation (yawn) and code walkthroughs to ensure that everyone understands what was done and how all the pieces fit together. Then it’s back home on Friday before a well deserved vacation next week, on a beach, with my wife.

So what did I learn this week?

  1. I really, really, REALLY don’t like COBOL!
  2. OpenVMS was WAY ahead of its time and offered LOTS of really cool features. Actually I didn’t just learn this, I always knew it, but I wanted to recognize it in this list … and it’s MY BLOG so I can Smile.
  3. Synergy/DE is every bit as cool as I always believed; and this week I proved it to a bunch of people that had never even heard of it before.
  4. New fangled elevators are very confusing for old dogs!

Learning REST Basics

By Steve Ives, Posted on May 23, 2015 at 1:48 pm

One of the sessions that I presented at the recent DevPartner Conference was on the subject of building RESTful web services using ServiceStack. The basic concepts of REST are often difficult to grasp when you’re first getting started, but while browsing this morning I came across a web site that I thought was a great REST resource, and in particular included a video that I thought did a really nice job of explaining the basic concepts of REST.

The site is http://www.restapitutorial.com/ and the video can be found at http://www.restapitutorial.com/lessons/whatisrest.html


Exposing WCF Services using Synergy .NET

By Steve Ives, Posted on September 8, 2011 at 12:54 pm

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

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

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 Item Required Attribute
Class containing callable methods ServiceContract
Callable method OperationContract
Class defining a data structure DataContract
Accessible member in a data structure DataMember

 

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.


Hosting WCF Services in an ASP.NET Web Application

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

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

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.


Building Distributed Apps with Synergy/DE and WCF

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

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.


Counting on Synergy

By Richard Morris, Posted on May 16, 2010 at 9:13 pm

One of our customers, Ibcos Computers, has used Synergy/DE to develop a web server. It may sound a bit bland, but it’s actually quite cool. In simple terms they have a server program running, written in Synergy, which accepts inbound resource requests. Each request then causes a child processes (again in Synergy) to be created to honour the request and return the required data. That data may be a web page, an image, or data as a result of executing some existing Synergy logic from their application.

Well, so far so good. The web server application works a treat. They can host complete web sites, and execute tried and tested logic from their Synergy application accessing their Synergy DBMS data. However, the way the Synergy/DE licensing works means that every time a child processes is created it consumes a Synergy license. This is a very valid situation – you are running a Synergy process, so you consume a Synergy license. Although you are running a Synergy process, that process may simply be locating and returning a resource associated with a web page, for example an image. When a web browser is loading a page from a web server it will asynchronously request many page resources at the same time. This means for a single page the web server may have many child processes executing, so the page can load quicker. It can be argued that although there are a number of live processes, each consuming a Synergy license, there is actually only one user, or client, which is the web browser.

Ibcos also have additional execution models for their web server. They have client applications that “log-in” to the site, execute Synergy logic to process data, then “log-out”. For this model, each connection does, and should, consume a Synergy runtime.

The challenge here is to reliably and accurately count the number of users actually accessing the web server. From a licence enforcement aspect, each resource is allocating a Synergy runtime license. However, Ibcos require a license entitlement model that would allow them to monitor individual types of connections, and be able to identify when pools of connections actually relate to an individual user.

For a solution Ibcos looked towards Synergex. I wrote a specification and they commissioned us to write the required code to utilise the Synergy/DE Licensing Toolkit to monitor license usage. Ibcos can use the Synergy/DE Licensing Toolkit to create and register licensed products within the Synergy/DE License Manager. As the different user types access the Web server, license slots are allocated and released, as required, around the logic being processed. A background process has been written that monitors license usage every five seconds. This information is stored and a program to report on license usage levels has been created. Synergex can then utilise this information to assist Ibcos with their license entitlement requirements.

Ibcos Computers, based in Poole, England, provides software solutions, written in Synergy, to the Agricultural, Ground Care, Construction, Material Handling, Commercial Vehicle and Industrial Dealer markets. Ibcos Gold, their main Synergy/DE UI Toolkit based application, has an installed base of over 500 customers and utilise the latest version 9.3 capabilities.

If you would like more details about License Enforcement and Entitlement, and the synergy Licensing Toolkit you can comment against this blog, email me at richard.morris@synergex.com, or visit the resource pages at www.synergyde.com.


Now that’s what I call service!

By Richard Morris, Posted on February 23, 2010 at 6:11 pm

Web services have been around for quite a while now.  If you attended the Success Partner Conference back in 2006, in London or Boston, you’ll have completed a hands-on tutorial that walked you through the steps required to consume web services with Synergy code.

During the conference, we wrote Synergy code to consume a number of different web services, from a number of different hosting sites.  The first service we utilised returned an array of valid country names. We then used the returned information to populate a UI Toolkit combo drop-down input control to allow the user to select the required country.  Other services we used allowed us to validate address details and credit card numbers.  The final web service we worked with, that I know several customers have since made use of, gave us the ability to interface with a Simple Message Service (SMS) API and send text messages to a mobile phone number.  Not all web services are free, and if I remember correctly, I believe the cost for sending an SMS was about $0.008!

So, when I saw the request from Rodney Latham on the Synergy-l list server, requesting if anyone had code to determine if a given date was a public holiday, I thought “there must be a web service to determine that”.  After a quick search on the Internet I found one at a site called www.holidaywebservice.com. After a few minutes of navigating the site, and looking at the WSDL (Web Service Description Language), it was obvious that I could write a few lines of Synergy code to consume the web service to determine if a date was a public holiday.  Another great feature of the web service was that it was free!

I knew that Rodney’s Synergy software ran on the OpenVMS operating system, so any fancy MS Windows coding was to be avoided – it had to be pure Synergy.  As long as the machine could access the internet we could execute the web service.

I could have written a regular Synergy subroutine or function, but instead I chose to implement executing the web service within a static method, as part of a SynPSG.DateFunctions class.  By defining the method as static, you don’t need to instantiate an instance of it.  This makes the coding very simple.  Add a reference in your code, using the “import” statement, to the SynPSG namespace and you’re ready.  To determine if the date is a holiday, simply execute the static method, for example;

import SynPSG

proc

    if (SynPSG.DateFunctions.IsHoliday(20100105,

&     SynPSG.CountryCode.EnglandAndWales)

    begin

    ;;we have a holiday, let’s party!

    end

The first argument to the IsHoliday() method accepts a reversed eight digit date and the second is an enumeration which allows you to select the required country code.  The enumeration is defined within the SynPSG namespace;

public enum CountryCode

    Ireland

    EnglandAndWales

    Scotland

    UnitedStates

endenum

Simple, free and the code is available on the Synergex Code Exchange – log into the resource centre and search the Code Exchange directory for IsHoliday.


RSS

Subscribe to the RSS Feed!

Recent Posts Categories Tag Cloud Archives