IssueNet supports two types of connections to the IssueNet database: Direct and Web Service. A direct connection establishes a SQL connection directly between the client application and the database as well as other required services such as MSMQ. A web service connecton establishes a communication link between the IssueNet web service, which in turn, establishes a SQL connection link to the database and other required services on behalf of the client application. In most cases, a user wants to use the web service connection.

IssueNet applications communicate with several different services during operation. These services include the database where the information is persisted, the license server where the user is authenticated, and Microsoft Messaging Queue (MSMQ) from which notifications are sent, as a result of notification actions. Additional services may be required as well depending on the solution. Each of these services imply both a security relationship and the ability to address the computer between the connecting application and the computer fulfilling the service. In many cases these relationships are very simple to configure and manage, but as more and more people are granted access to the IssueNet solution, the more these relationships can become points of failure.

In the case where only users within a secure domain are going to be acessing a particular IssueNet solution an administrator can enable access to these domain users fairly easily and can provide access to the services at a routing level by simply making sure the hosting machines are on the domain.

As the complexity of relationships between end user machines and these IssueNet required services increase, so does the administrative complexity that allows these users to work with the IssueNet solution reliably. To simplify this problem in a secure and supportable way, IssueNet uses a web service connection which places the authentication and addressable issues into a common shared portal for data and service fulfillment.

In the case where only users within a secure domain are going to be using a particular IssueNet solution an administrator can enable access to these domain users simply by enabling access to the particular service for Domain Users. As an example, the administrator may configure the machine running the MSMQ service for the IssueNet solution to have write permissions for domain users. This enables the IssueNet user to write notifications for the IssueNet notification service to format and send.

In the case where users are either working remotely or the administrator does not want the users to have direct access to the machines running these services, we recommend configuring a web service that is configured to access exactly those resources needed to be successful while restricting access to all else.

The web service connection will run in the security context as specified in the web.config file located in the web services root directory. This can be edited using the IssueNet Web Configuration Utility installed with the web services.

Though direct connections are not recommended for use for normal IssueNet client connections, there are several situations where the direct connection is either required or helpful.

Defining Web Service Connections
The direct connection is used when configuring the machine that will be running the web service for all other users. When the web service connects to the database on behalf of the IssueNet client applications, the web service connection is simply using a locally defined direct connection. An administrator will configure a direct connection for each IssueNet database that should be made available through a web service. The web service caches the known direct connections that a remote user may access, so any changes to the connections will require a restart of the web service.

Using the IssueNet Architect
The IssueNet Architect makes use of parts of the IssueNet platform that no other applications access. These portions of the platform are not exposed through web services. For this reason, the IssueNet Architect must always use a direct connection.

Using IssueNet without IIS
A direct connection can be used in the case where the user does not have access to IIS 5 or better to run web services. It is possible to install, configure, and operate IssueNet solutions without running any web services. This is typically done if the user is evaluating or wants to pre-configure the solution while waiting for access privileges to a web server. The user will be limited to using the administrator user which is the only user not authenticated against the license service. You may also use the direct connection as a mechanism to determine if there are special security or installation issues with the web service applications.