In Flex 1.5, configuration settings for both the compiler and runtime services are contained in a single configuration file, flex-config.xml. Three sections of this configuration file are used for RPC services: <remote-objects> for the RemoteObject tag, <web-service-proxy> for the WebService tag, <http-service-proxy> for the HTTPService tag. Flex uses the services configuration information at compile time to generate code for the MXML tags and validation of the tag attributes. The following sample shows the structure of the Flex 1.5 configuration file, flex-config.xml.
<flex-config>
<debugging />
<compiler />
<cache />
<flash-player />
<web-service-proxy />
<http-service-proxy />
<remote-objects />
<logging />
<fonts />
</flex-config>
The Flex 1.5 AMF gateway also has its own configuration file, gateway-config.xml. Developers can customize several features by using this file, including service adapters that process RemoteObject requests, and login commands for custom service security. The following snippet shows the structure of the Flex 1.5 RemoteObject configuration file, gateway-config.xml.
<gateway-config>
<service-adapters />
<logger />
<security />
<serialization />
<translator />
<redirect-url />
<lowercase-keys />
</gateway-config>
In Flex Data Services 2 a separate configuration file, services-config.xml, contains services-specific configuration. The three services-related sections from Flex 1.5 were removed from flex-config.xml, however, compiler-specific configuration settings remain in this file. Other web-tier configuration settings, such as caching and Flash Player detection, are in the flex-server-config.xml file. The Flex 1.5 gateway-config.xml file is no longer used. The new, common services-config.xml file contains all relevant gateway features and applies the settings to all services.
The services-config.xml configuration file lets developers include individual service definitions from external files. This helps isolate service-specific destinations and reduce the size of the main services configuration file, which allows easy access to common sections such as security, channels, and logging settings. The following sample shows the general structure of the Flex Data Services 2 configuration file, services-config.xml, with each service defined in a separate include file:
<services-config>
<services>
<service-include file-path="remoting-service.xml" />
<service-include file-path="proxy-service.xml" />
</services>
<security />
<channels />
<clusters />
<logging />
<system />
</services-config>
The services-config.xml configuration file is required at compile time if the Flex application uses Flex Data Services. In the case of RPC services, this applies to all applications that use RemoteObject or proxy-based WebService or HTTPService.
The mxmlc compiler can point to the services configuration file by using the flex-config.xml file or command-line switches. The services configuration information is necessary at compile time because code must be generated to instruct the client which channels should be used for each service destination. The following configuration snippet points the mxmlc compiler to a Flex Data Services 2 configuration file by using flex-config.xml.
<flex-config>
<compiler>
<services>
services-config.xml
</services>
...
</compiler>
</services-config>
The following configuration snippet points the mxmlc compiler to a Flex Data Services 2 configuration file by using the command line:
mxmlc --load-config=flex-config.xml --services=services-config.xml MyApp.mxml
Table 2 shows the differences between the configuration of Flex 1.5 and Flex Data Services 2.
Gateway URL and Proxy URL
Using flex-config.xml for:
{context.root}/flashproxy
The mxmlc command line switches for
-proxyurl=/myapp/flashproxy
-gatewayurl=/myapp/amfgateway
Channels
Services use any number of channel endpoints to process messages. Service-specific endpoint settings are not required; developers create new channels instead. Channels must be defined in the services configuration file, services-config.xml. Channels are defined independently of services:
<channel-definition id="my-amf" ...> <endpoint uri="http://www.abc.com/messagebroker/amf" ... /> </channel-definition>
A set of default channels can be established for a service:
<service id="remoting-service" ...>
...
<default-channels>
<channel ref="my-amf"/>
</default-channels>
...
</service>
A destination can also specify its own specific channel list to override the service's defaults:
<destination id="MyManager">
<channels>
<channel ref="my-amf"/>
</channels>
...
</destination>
Individual channels cannot be specified on the command line; however, an mxmlc command-line switch can point the compiler to a complete services configuration file:
--services=/flex/services-config.xml
Service Whitelist
A whitelist is used to restrict which services are available to clients.
HTTPService and WebService services can be specified in the whitelist based on the URLs of the ultimate third-party endpoints:
<whitelist>
<unnamed>
<url>
http://www1.abc.com/*
</url>
<url>
https://www1.abc.com/*
</url>
</unnamed>
<named>
<service name="MyManager">
<url>
http://www.abc.com/mysvc/10/
</url>
</service>
</named>
</whitelist>
RemoteObject objects can be specified in the whitelist, based on the underlying source of the remote object:
<whitelist>
<unnamed>
<source>*</source>
</unnamed>
<named>
<object name="WeatherService">
<source>
samples.WeatherService
</source>
<type>stateless-class</type>
</object>
</named>
</whitelist>
Service Destinations
The act of adding a destination to a service is equivalent to adding something to a whitelist.
Proxy Service destinations can specify url-patterns and soap endpoints to provide equivalent functionality to Flex 1.5 unnamed services. The default URL for the service is defined in the url property. The dynamic or client-provided URLs are defined in dynamic-url properties.
<destination id="flickr">
<properties>
<url>
http://www.abc.com/mysvc/10/
</url>
<dynamic-url>
http://www1.abc.com/*
</dynamic-url>
<dynamic-url>
https://www1.abc.com/*
</dynamic-url>
</properties>
</destination>
Note that two destinations, defaultHttp and defaultHttps, have been configured for the Proxy Service to allow the developer to use the HTTPService and WebService tags without specifying a destination. However, a dynamic-url must be configured for these default destinations with HTTP based URLs using the defaultHttp destination and HTTPS based URLs using defaultHttps.
Remoting Service destinations using the Java Adapter can no longer specify sources on the client. The developer must register a unique destination for each Java source on the server:
<destination id="WeatherService">
<properties>
<source>
samples.WeatherService
</source>
<stateful>false</stateful>
</properties>
</destination>
Proxy and AMF Gateway Logging
In Flex 1.5, the developer can debug AMF requests by modifying the logging settings in the server gateway-config.xml file. Proxy requests can be debugged by modifying the logging settings in the main flex-config.xml file used by the web-tier compiler.
Logging
The message broker has a unified logging system for all services. The logging section of services-config.xml enables the developer to customize the logging level and restrict information to particular categories.
Client Logging
In Flex 1.5 the developer can debug service requests on the client by setting http-service-proxy-debug, web-service-proxy-debug, or remote-object-debug settings to true in the debugging section of flex-config.xml. The developer can view client logging information by using Flex Builderâ„¢ Network Monitor, Flash Remoting NetConnection Debugger, and the debug Flash Player output of trace information to the flashlog.txt file in the user directory.
Client Logging API and Log Targets
A new client logging library is included with Flex 2 in the mx.logging package. All services report information using this client logging API. The developer can specify the level of log events and filter the category of events. The developer can enable a logging target to view the information in a particular location. The most commonly used target is the TraceTarget (from the mx.logging.targets package), which reports information using the trace() function. The debug version of the Flash Player outputs trace information to the flashlog.txt file in the user directory.