Open Menu

Synergex Blog


Using Synergy .NET in Multi-Threaded Applications

By Steve Ives, Posted on October 10, 2013 at 12:28 pm

There are special considerations that must be taken into account when implementing non thread-aware Synergy .NET code that will execute in a multi-threaded environment. As will be explained later, one such environment is when code executes within an ASP.NET / Internet Information Server (IIS) environment.

The Microsoft .NET environment provides a mechanism to allow the isolation of multiple instances of an application from one another. This mechanism is called Application Domains, and is often referred to as AppDomains. Essentially an AppDomain entirely isolates an instance of some piece of executing code from all other executing instances of that, and any other code, so that these instances cannot interfere with one another in any way. AppDomains also ensure that the failure of any code executing within an AppDomain cannot adversely affect any other executing code.

AppDomains are specifically useful in situations where there may be multiple instances of a piece of code executing within the context of a single process, for example where different execution threads are used to perform multiple concurrent streams of processing (perhaps on behalf of different users) all within a single host process. An example of such an environment is ASP.NET Web applications executing on an IIS Web Server.

Synergy .NET provides specific support for isolating non thread-aware code in AppDomains, and in some situations it can be critical that AppDomains are used in order to have your Synergy .NET code behave as expected in several key areas. Those key areas are channels, static data, common data and global data.

If any of the above items are used in a multi-threaded environment without the use of AppDomains, then they are SHARED between all instances of the code running in the multiple threads. By using an AppDomain, code executing within a given thread can isolate itself from code running in other threads, thus returning to the normal or expected behavior in Synergy environments.

If you are implementing Synergy .NET code that does not make use of multi-threading, and will not execute in a multi-threaded application host then you don’t need to worry about any of this.

If you are implementing multi-threaded Synergy .NET code then you have the option of using AppDomains to isolate parts of your code from other instances if you chose or need to do so.

However if you are implementing non thread-aware Synergy .NET code that will execute in an ASP.NET / IIS environment then you are automatically in a multi-threaded environment and it is critical that you use AppDomains to isolate instances of your application code from each other.

The basic problem is this: ASP.NET and IIS isolate different APPLICATIONS within their own AppDomains, but within an ASP.NET application, multiple (potentially lots of) user “sessions” all execute within the SAME AppDomain. This means that by default there is no isolation of executing code between multiple ASP.NET user sessions, and with Synergy .NET that in turn means that channels, and static, common and global data is shared between those multiple user sessions. As an ASP.NET user session is often considered to correlate to a user process in a regular application, the problem becomes apparent. If one “user” opens a new channel and reads and locks a record, that same channel and record lock are shared with all other users. If one user places a certain value in a common field for use by a routine that is going to be called, that value could be changed by code running for a different user before the first users routine gets called.

Clearly it would be very difficult, if not impossible to build and execute reliable code in this kind of environment. Without support for AppDomains in a multi-threaded environment a Synergy developer would need to:

  • Always use automatic channel number selection.
  • Always close any channels before returning from the routine that opened the channel (no persistent open files)
  • Not use static, common or global data unless the nature of that data is that it contains application wide information that does not change during execution.

While it is possible to write code which adheres to these rules, it would be at the least inconvenient to do so, and because of the way that Synergy code has typically been written in the past, existing code would likely require significant reworking.

The solution to this problem is to have each “users” code isolate its self from other “users” code by loading its self into an AppDomain, and this is relatively easy to do. Specifically in the case of an ASP.NET Web application, code can be written to hook the Session_Start event that signals the beginning of a new user session and create a new AppDomain in which to execute, and hook the Session_End event and execute code to clean up by deleting the AppDomain. There are other possible approaches that may be more appropriate, but the principal is basically the same; have the code isolate its self in an AppDomain before any non-thread aware Synergy .NET code executes.

By isolating non thread-aware Synergy .NET code in an AppDomain in a multi-threaded environment you have essentially the same operating environment that you would expect for any other Synergy code executing in a process, with one notable exception. That exception is that environment variables created with XCALL SETLOG are always applied at the PROCESS level. This means that Synergy .NET code executing in any multi-threaded environment should never rely on the use of XCALL SETLOG unless the value being set is applicable to code executing in all other threads. An example of this might be an environment variable that identifies the fixed path to a data file.

Synergex Professional Services Group is in the process of developing code for a sample ASP.NET Web Application that will demonstrate how to use AppDomains to ensure that code executing in one ASP.NET Session is isolated from other ASP.NET Sessions. We will publish this code in the Synergy/DE CodeExchange soon. I will post another article on this BLOG once the code has been published.


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.


Web Browser “Session Merging”

By Steve Ives, Posted on December 8, 2009 at 5:11 pm

I just realized something about modern web browsers, and as a long time web developer it kind of took me by surprise! Maybe it shouldn’t have, maybe I should have figured this out a long time ago, but I didn’t.

What I realized is that Internet Explorer 8 shares cookies between multiple tabs that are open to the same web application. In fact it’s worse than that … it also shares those cookies between tabs in multiple instances of the browser! And as if that’s not bad enough, research shows that Firefox, Google Chrome and Apple’s Safari all do the same thing! Internet Explorer 7 on the other hand shares cookies between multiple tabs, but not between browser windows.

If you’re an ASP[.NET] developer you’ve probably figured out by now why I am so concerned, but if you’re not then I’ll try to explain.

ASP, ASP.NET, and in fact most other server-side web development platforms (including Java’s JSP) have the concept of a “current user session”. This is essentially a “context” inside the web server which represents the current users “state”. The easiest way to think about this is to picture a UNIX or OpenVMS system; when a user logs in a new process is created, and (usually) the process goes away when the user logs out. A web applications user session is not a process as such, but it sometimes helps to think of it that way.

Web developers in these environments can, and very often do make use of this current user session. They use it to store state; information about the current user, or application information about what they are doing or have done, and possibly even to cache certain application data or resources to avoid having to repeatedly allocate and free those resources, or to avoid having to obtain a piece of data over and over again when the data doesn’t change.

Now, at this point I want to make it clear that I’m not saying this is a good thing to do, or a bad thing to do. Some would say it’s a bad thing to do because it increases server-side resource utilization and hence impacts the scalability of the application; and they would be correct. Others would say that by caching data or resources it is possible to avoid repeated round-trips to a database, or to an xfServerPlus service, and hence helps improve runtime performance; and they would also be correct. As with many things in software development … it’s a trade-off. Better runtime performance and a little easier to code, but at the cost of lower scalability.

In reality, unless a web application needs to routinely deal with large numbers of concurrent users, the scalability issue isn’t that important. As a result, good practice or not, many web developers are able to enjoy the luxury of using current user session state without significantly impacting anything … and they do!

So … what’s the problem?

Well, the problem is that the web (HTTP) is a connectionless environment. When a user types a URI into a web browser the browser connects to the web server, requests the resource(s) identified by the URI, and then disconnects. In order to have the concept of a user “session” the web server needs to have a way of recognizing that a subsequent “request” is coming from a browser that has already used the application, and is attempting to continue to use the application. The way that web applications usually do this is to send a “cookie” containing a unique “session ID” to the browser, and the nature of HTTP cookies is that if this happens, the same cookie will be returned to the web server during subsequent connections. Web applications can then detect this cookie, extract the session ID, and re-associate the browser with their existing “current user session”.

This is how most server-side web applications work; this is how they make it possible to have the concept of an on-going user session, despite of the fact that the interaction with the browser is actually just a set of totally unrelated requests.

So now the problem may be becoming clear. Early web browsers would keep these “session cookies” private to a single instance of a browser. New browsers would receive and return different cookies, so if a user opened two browsers and logged in to the same web application twice, the web server would recognize them as two separate “logins”, would allocate two separate “current user sessions” and what the user did in one browser window would be totally separate from what they did in the other.

But … now that modern browsers share these session ID cookies between multiple tabs in the browser, and more recently between multiple instances of the browser window its self, server-side web applications can no longer rely on “session id” to identify unique instances of the client application!

At least that is the case if the application relies on HTTP cookies for the persistence of session ID. In ASP.NET there is a workaround for the problem … but it’s not pretty. It is possible to have the session ID transmitted to and from the browser via the URI. This would work around the multiple instance problems, but has all kinds of other implications, because now the session ID is part of the URI in the browser, and affects the ability to create bookmarks etc.

This whole thing is potentially a huge problem for a lot of server-side web applications. In fact, if your web applications do rely on session state in this way, and have ever encountered “weird random issues”, this could very well explain why!

So what’s the answer for existing applications … well, I honestly don’t know what to tell you. Passing session ID around via the URI may be an easy fix for you, but may not! If it’s not then the only solution I can currently offer is … don’t use session state; but if you use session state, then transitioning to not using it is probably a very large task!

By the way, today I read that the proposed HTML5 standard includes a solution to this very issue. Apparently it’s called “Session Storage”. Great news! The problem is that, according to some Microsoft engineers who are definitely “in the know”, it is very possible that the HTML5 standard may not be fully ratified until the year 2022! Seriously!


Silverlight – What’s it all About?

By Steve Ives, Posted on November 18, 2009 at 5:16 pm

Day two at PDC09, and with between ten and twelve concurrent tracks it’s pretty tough to decide which sessions to attend. Luckily there are three of us attending the conference, so with a little planning we can at least attempt to maximize our coverage. But still … so many choices!

I’ve been involved with Web development for a long time now … in fact I’ve been involved with Web development ever since there was such a thing as Web development, so I decided to spend the day trying to make sense of the choices that are now available to Web developers in the Microsoft space.

If you look across the entire industry there are many and varied Web development platforms available, some well proven, some relatively new. When Microsoft first introduced Active Server Pages (ASP) back in 1996 they changed the game. Web development was taken to a whole new level, and in my humble opinion they have lead the game ever since.

Until recently the choice was clear. The Web development platform of choice was ASP.NET’s WebForms environment. Thanks in part to very rich developer support in Visual Studio, and an absolutely vast array of excellent third-party plug-ins and controls, the ASP.NET WebForms environment was, and still is absolutely dominant in the industry.

However, things are changing. In 2007 Microsoft unveiled a new technology called Silverlight, and while it is fair to say that initial adoption was slow, Silverlight could today be considered to be a key part of Microsoft's vision for the future of computing generally!

Silverlight is essentially a browser plug-in that allows Web browsers to render rich user interfaces. It started out as a relatively simple plug-in which allowed browsers to display streamed video content, much like Adobe Flash, but that is no longer the case today. The technology is less than two years old at this point, and today Microsoft announced the beta for the fourth major release of the product in that short time. Clearly a lot of dedicated effort has been put into into Silverlight … there must be a “bigger picture” here!

Let’s take a step back. A browser plug-in is a software component that allows a Web browser to do something that is not inherently supported by the Web (i.e. by HTTP and HTML). The issue here is that HTTP and HTML were designed as a mechanism for a client system (a browser) to safely display “content” from a server system. That server system could be located anywhere, and owned and operated by anyone. In that situation, how do you trust the publisher of the content? The simple answer is … you can’t. So for that reason early browsers didn’t allow the Web “applications” to interact with the client system in any way … they simply displayed static content.

Of course clever software developers soon found ways around that restriction, but only if the user of the client system gave their permission. That permission is typically granted by allowing the installation of third-party plug-ins on the client system. Once a plug-in is present it can be detected by the browser, and in turn detected by the Web server, which can then take advantage of the capabilities of the plug-in. And because a plug-in is a piece of software that was explicitly allowed to be installed on the client system by the user of the client system, it is not subject to the normal “restrictions” (sandbox) placed on the Web browser … plug-ins can do anything!

Silverlight isn’t the first product that Microsoft has introduced in this arena. Many years ago they introduced support for ActiveX controls to be embedded within Web pages, and the technology was very cool. It allowed very rich and highly interactive user interfaces to be rendered within a web browser, it allowed the web “application” to interact with the “resources” of the client system, and for a while ActiveX in the browser showed a lot of promise. The problem was that the ActiveX technology was only available in the Internet Explorer browser, and at that time IE didn’t have a big enough market penetration for ActiveX in the browser to become a serious player.

Today though, things are different. Internet Explorer is by far the most dominant Web browser in use (although Firefox, Safari and Google Chrome continually eat away at that market lead). But this time around the difference is that Microsoft took a different approach … they made Silverlight plug-ins available for Firefox … and Safari … and today even announced the development of a plug-in for Google Chrome in the up-coming Silverlight 4 release. This is pretty impressive, because the current version of Chrome doesn’t even support plug-ins!

Today during the PDC09 keynote presentations Silverlight was front and center, and I’ll be completely honest here … the demos that I saw totally blew me away! Silverlight can now be used to render fabulous interactive user interfaces which can equal anything that can be achieved in a desktop application, and with appropriate permissions from the user of the client system Silverlight applications can fully interact with the local client system as well. It’s even possible (in the current release) to execute Silverlight applications outside of a traditional web browser, allowing them to appear to the user exactly as desktop applications would … but with no installation required (other than the Silverlight plug-in).

So why is Silverlight so important to Microsoft? And why might it be so important to all of us as software developers, and as software users? Well, the answer to that question is related to my last post to this blog … it’s all about the Cloud! The perfect model for a Cloud application is a Web application, but even with all of the advances in Web technologies it’s still really hard to make a web application that is as feature-rich and capable as a modern desktop application … unless you use a tool like Silverlight.

Now don’t get me wrong, ASP.NET WebForms is still a fabulous technology, and still very much has a place. If you have an ASP.NET WebForms application today … don’t panic, you’re in good shape too. The point here is that you now have options. In fact, there is a third option also … it’s called ASP.NET MVC, and I’ll talk about that in another blog post soon.

If you want to see examples of Silverlight in action then check out the Silverlight Showcase Samples (of course you'll need the Silverlight plug-in installed, but the site will offer it to you if you don't have it), and if you can also get more information about the PDC09 Silverlight 4 (beta) demos.


RSS

Subscribe to the RSS Feed!

Recent Posts Categories Tag Cloud Archives