You can include Windows Services as part of your application if your Platform Operator has enabled Windows Service supporton your Apprenda environment.
The structure of an Apprenda Application Archive, including the placement of Windows Services, is discussed in full under the Manually Creating Apprenda Application Archives Developer Topic; however, it should be noted that a service must be placed in a folder at the base of the archive labeled WinServices in order for it to be deployed correctly as a Windows Service.
Archives can also be created from Visual Studio solutions that include Windows Services using the Archive Builder or the Apprenda Cloud Shell, both of which are included in the Apprenda SDK.
If using the Archive Builder, be sure to confirm that Windows Services are placed in the WinServices folder in the Archive Structure section prior to creating the archive, as in certain situations (e.g., WCF elements are detected) the Archive Builder will place the service in the Services folder.
If you need to relocate a project to a folder in the Archive Structure, simply drag it from the Project list on the left-hand side of the screen to the appropriate folder on the right; any extraneous projects can be removed from the Archive Structure by deselecting them.
If using the Apprenda Cloud Shell, it is advisable to use the -WS optional argument to designate Windows Service projects when using the NewPackage or NewApplication command to build an archive from a Visual Studio solution, as this will ensure that the project is correctly packaged in the WinServices folder.
Any archive that includes one more Windows Services must include a Deployment Manifest with the required windowsServices information as per the example below:
Sample DeploymentManifest.xml for Windows Services
<?xml version="1.0" encoding="utf-8"?> <appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/8.2/DeploymentManifest.xsd"> <!--Required: service name, nameOfExecutable--> <windowsServices> <service name="MyAwesomeApp.WindowsService" requires32Bit="false" nameOfExecutable="MyAwesomeApp.WindowsService.exe"> <ports> <staticPort num="5555" /> <staticPort num="5556" /> </ports> </service> </windowsServices> </appManifest>
If a Windows Service requires specific ports, those ports must be specified as “static” ports in the Deployment Manifest. The values allowed for the specified ports, as well as the maximum number of ports that can be specified for each Windows Service, are configured by your Platform Operator; “ports” values that exceed these limits will result in a failed archive upload.
Please Note: Within an application archive, the name of each Windows Service as specified in the name of its individual Windows Service folder within the WinServices folder must match the service name specified in the Deployment Manifest included with the archive. The name of the executable must also match that specified in the Deployment Manifest.
The Apprenda Platform does not support autodeployment of Windows Services, which means that all instances of a Windows Service component must be deployed manually. This can be done by Developers through the Developer Portal or the SetInstanceCount command in the Apprenda Cloud Shell. A Platform Operator can deploy Windows Service instances through the Applications page in the SOC.
When a Windows Service is deployed to an application server, all ports specified in the Deployment Manifest will be reserved for the use of that Windows Service instance. This means that you cannot deploy more than one instance of a given port-dependent Windows Service component to an application server. This also means that Windows Service components from two different guest applications (or different versions of the same application, if port usage has not been changed) cannot be deployed to the same server if their port requirements conflict. On multi-node environments, the Platform will filter deployment targets for Windows Service instances based on port need and availability. It is strongly suggested that Developers consult Platform Operators regarding port usage expectations in order to avoid port usage conflicts.
It should be noted that Windows Services are subject to any and all Resource Throttling and Allocation Policies, Application Deployment Policies, or Custom Property requirements put in place by your Platform Operator.
Calling the method below (with the name of your Windows Service) will return a list of the deployed instances of that service:
Information returned includes the host names where the service is deployed along with the ports it has requested. Once you retrieve the information of where the instances are deployed, you can use this information to establish a connection to your services and communicate with them. Keep in mind that communication with Windows Service instances does not flow through the native Platform routers since the goal is to enable communication protocols that don’t have to be SOAP or WEB-based.