The Server
| The Flash Communication Server is intended to be installed as a stand-alone server, in that it does not require a web server or application server to run. It does, however, require additional elements to make it function. Flash SWF movies are usually accessed through a web server. Databases and external server resources can be accessed though application servers. For development, the server should be installed with a web server already installed because this arrangement makes managing scripts and other application elements easier for developers. When a server is ready for public access, you should move application scripts away from the web server access, separating the SWF movies and the ASC, FLV, and FSO files. Macromedia built the Communication Server server architecture with two things in mind: scalability and security. A model similar to the relationship of your network card and IP addresses or domain names is used. Communication Server employs adaptors and virtual hosts to isolate users and applications. This model is also used to provide domain-level restrictions and access control. The Communication Server has many internal security provisions for its operation and for accessing the applications that run within it. It is, however, the responsibility of the individual developer (you) to achieve security of your data and the integrity of the application. The Server can connect and can accept connections to a number of components , including other Flash Communication Servers, application servers, web services, or Macromedia Flash 6 Players. Flash Communication Server applications can communicate with these resources in two ways:
Both RTMP and HTTP protocols use the Action Message Format (AMF) to transport ActionScript objects. AMF is available with most application servers (.NET and J2EE) that support Flash Remoting MX. The server is a collection of adaptors, virtual hosts, and applications. A Flash Communication Server application might consist of streams, users, and SharedObjects. The Macromedia Flash MX authoring environment and Macromedia Dreamweaver MX are the integrated development environments (IDE) of choice. For Dreamweaver MX, however, you can substitute most JavaScript or simple text editors. You can develop Communication Server applications on either Macs or PCs, but the 1.0 server is available for Windows platforms only. The server is installed with one adaptor and one virtual host. Defining new adaptors and new virtual hosts involves the management of folders and configuration XML files. Figure 14.2, displays the folder structure of the _defaultRoot_ adaptor, and its _defaultVHost_ virtual host. Each folder and configuration file will be discussed in detail later in the chapter. Figure 14.2. The conf configuration folder located in the root of the Communication Server install path . This tree is the installed default. UsersA server user assumes the role of system administrator. This user has the control to interact with and restart all aspects of the server including applications, virtual hosts, adaptors, and the entire server. The server user is sometimes referred to as the root user. You can have multiple root users on a server. Root users are managed in one of two ways:
There is no advantage to using one way or the other. Configuration: Server.xmlLocated in the root of the conf folder, the Server.xml file controls registration of root users, adaptors, and virtual hosts. The Administration Console can manage users and will overwrite this file. You also use Server.xml when declaring new adaptors and virtual hosts. Below is an overview of a default Server.xml file. This XML description includes nodes that were not included in the original documentation of the Communication Server. <Root> <Admin> <Server> The <UserList> node then defines each user that has root-level access to the Administration Console and the Administration API: <UserList> <User name="admin"> <Password encrypt="true">YWRtaW4=</Password> <Allow></Allow> <Deny></Deny> <Order>Deny,Allow</Order> </User> </UserList> </Server> The <Allow> and <Deny> nodes specify the IP addresses or domains from which the user can and cannot access the Administration Console. The <Order> node determines how the server processes the values declared within the <Allow> and <Deny> nodes. If Deny precedes Allow in the <Order> node, as the previous listing shows, access will not be granted from any host listed within the <Deny> node and is not listed in the <Allow> node. When the <Order> node is reversed (Allow, Deny), then the same user can access the Administration Consoles only if the host is listed within the <Allow> node. In the next portion of the file, the <Adaptor> node defines each adaptor on the server. Adaptors contain virtual hosts that are defined within the <VirtualHost> node. You can set domain restrictions on each virtual host. Virtual host users are defined within the <User> node. <Adaptor name="_defaultRoot_"> <VirtualHost name="_defaultVHost_"> <User name="admin"> <Password encrypt="true">YWRtaW4=</Password> <Allow></Allow> <Deny></Deny> <Order>Deny,Allow</Order> </User> </UserList> </VirtualHost> </Adaptor> </Admin> Finally, the <Server> node defines the serial numbers used and the port to access the Administration Console. The <ResourceLimits> node gives you some control over which resources the server can consume on the server. This node was not included in the original documentation for Flash Communication Server. <Server> <LicenseInfo>FSW100-XXXXX-XXXXX-XXXXX</LicenseInfo> <AdminServer> <HostPort>:1111</HostPort> </AdminServer> <ResourceLimits> <CPUMonitor>1</CPUMonitor> <ThreadPoolGC>20</ThreadPoolGC> <ApplicationGC>5</ApplicationGC> <FLVCacheSize>40</FLVCacheSize> </ResourceLimits> </Server> <ServerDomain></ServerDomain> </Root> Note The node tree, <ResourceLimits> , was omitted from the Flash Communication Server manual. These nodes declare the resource limitations available to the server:
SecurityFlash Communication Server provides system administrators with an excellent architecture for security. The default installation is not intended as a locked-down install, and you should become familiar with some of the options you have to tighten security. Flash Communication Server security is achieved through the server configurations files (XML) and the application you develop. In particular, the <ALLOW> and <DENY> tags in the configuration files let you declare either IP addresses or domains that access the server. By default, the server communicates using port 1935, which was assigned to the Flash Communication Server by the Internet Assigned Number Authority (http://www.iana.org). The administration API is accessed through port 1111. It is up to you to protect this port through firewall or VPN technology. You can change this port in the Server.xml file within the <HostPort> domain. The <USER> tags give you control over root-level users who have full operational control over the server. These users are the only users who can connect to the Administration Console. You can use the <ServerDomain> tag to inform other component servers (such as a Flash Remoting MX-enabled server) of the domain from which the server is communicating.  |
EAN: 2147483647
Pages: 200