The .Net Business Connector (BC.Net) and the IIS

BC.Net client application

The BC.Net is designed to be a client application in a non multithreading context. This is why the assembly is deployed in the bin-directory of the Dynamics Ax client. The following schema describes the standard scenario you might find described on msdn and many excellent articles on the web:

You need to instantiate an Axapta object, logon on the AOS and execute whatever you need on the AOS - but you can't share a connection with different threads because the Axapta-object is not thread safe! Since the instantiation and the logon does take quite a lot of time, you might want to create only one instance, that you reuse whenever you need to execute something on the server. For a simple client-application this is good enough.

BC.Net in a server application

If you now want to use the BC.Net in a process that is hosted by the IIS, then you need first of all an Enterprise Portal license - even if you don't use anything of the Enterprise Portal. Otherwise, the AOS will throw an exception and reminds you, that you don't have a valid license...

The following schema shows a typical architecture of a BC.Net-application hosted by an IIS 6:

The main difference between this architecture and the one described in the first schema is, that the Ax user does not need a local Dynamics Ax client installation. All the necessary components are now installed on the IIS Server. But, and that's important, these components are still client-components and they are designed for that.

Using the BC.Net in a server application changes a lot and if you take the source-code that was written for a client application (as described in the first schema), your application will not perform well (each AOS request will require an instantiation of an Axapta-Class and a logon) or crash if you share one Axapta-instance for different requests. Remember, the Axapta-class is not thread-safe. I saw some application using a mutex in order to protect the one Axapta-instance, but this is really an ugly hack that can't be a solution for a server application...

You might think that the Enterprise Portal uses the BC.Net as an Ax-communication stack and it works fine for a lot of users and does perform pretty well. Well, you're right, and the Enterprise Portal does this because of its quite complex session management layer above the BC.Net. The session-management is implemented in the Microsoft.Dynamics.WebParts assembly and contains a connection pool (that reuses the Axapta-instances) and encapsulates the Axapta-objects from the BC.Net in order to be thread-safe.

If you want to write your own server application based on the BC.Net, you have to write this on your own. So maybe you might prefer using directly the Enterprise Portal, since you already bought the license for it...