For many developers, the thought of Macromedia Flash invokes visions of swirling graphics, thumping (and bandwidth-gobbling) techno beats, and intro screens for Web sites that most of us would rather just skip.
Internet application developers want the real deal. They want Java and C#. They want compilers and debuggers, and access to code for building real applications, not playful content.
As you may know, Macromedia recently released the MX product line with the goal of providing developers with an integrated client, server, and tools to develop rich Internet applications—applications that deliver more effective user experiences, at a lower cost, in the context of the infrastructure already in place.
The editors of DevX invited me to take a developer's-eye view of the Macromedia MX product line, walking through some of the major technical features that I believe make it a really compelling development environment—for any developer and not just for those who want to do intense motion graphics.
While there are many big changes in the product line that I could address, I'm going to limit my comments here to the two technologies that have significantly changed the face of Flash and made it a serious environment for serving applications that interact with server logic and instructions: Flash Remoting and ColdFusion Components.
Macromedia Flash Remoting: Client/Server Communications
Designing the user interface layout and behavior is the first step in building an application. But connecting the UI to business logic and data is what brings real value to the application. That's one of the reasons that many traditional application developers might want to take a fresh look at Flash. With MX, Macromedia focused on providing a simple, services-based architecture for connecting back-end services with front-end user interfaces. Macromedia calls this approach Flash Remoting.
Flash Remoting provides a collection of client-side APIs for accessing services provided by an application server or SOAP Web services, for working with recordsets and binding them to user interfaces, and for easily debugging interactions with remote services. Flash Remoting also includes a server component (included free with Macromedia's ColdFusion MX and JRun 4) that works with your application server. Macromedia Flash Remoting includes adaptors for nearly any remote service, including simple scripts created in ColdFusion and ASP.NET, as well as well-formed objects and components such as C# objects, EJBs, plain old Java classes, and ColdFusion Components (see the sidebar "Integrating Flash with the ColdFusion Server" for more on ColdFusion Components). It also supports direct invocation of distributed SOAP Web services. The sample code uses ColdFusion Components, because they provide the simplest and fastest way to create a back-end service.
On the client side, a global function initializes when the application loads, and defines a variable that references the remote server that processes the Remoting requests. The example specifies the remote server location using a relative URL, because the Flash Player automatically assumes that the URL points to the origin server of the executing SWF file. In the following example, a proxy object on the client uses a remote service running in ColdFusion MX.
// Create a connection to the Macromedia Flash Remoting service
MyServer = NetServices.CreateGatewayConnection("/flashservices/gateway/");
// Create a local proxy object called employee using a remote service
Employee = MyServer.GetService("EmployeeDirectory", this);
After defining the remote server, you can write functions that handle user interface events and make calls to remote services. For example, here's a function that handles the click event of the search form push button. The function calls the search function on the remote service.
// Function handler for the search form push button
function SearchEmp (firstName, lastName, Dept) {
Employee.GetEmployees({firstname:firstName, lastname:lastName, Department:Dept});
}
The preceding function uses a single arguments structure that provides named member variables that are then available to an arguments scope in the server component. You could also just pass in an ordered list of parameters, and the arguments would be received in that order on the server, but the server-side developer would need to reference them by their array index value rather than by variable name. Of particular note is that the 'Employee.GetEmployees' method call looks like a local object method invocation, but Flash Remoting transparently maps that to a server function.
In this example, to actually handle the return from the function invocation you need to write a result handler. The Flash Player operates asynchronously with respect to server communication, so you must always write a call back function.
// call back function for the GetEmployees request
function GetEmployees_result (result) {
DataGlue.BindFormatStrings (empList, result, "#FirstName# #LastName#", "#EmpID#");
}
With Flash Remoting, you can either define a specific Result object that handles all returns, or you can write a generic function that uses the name of the method call plus _result, which will also resolve automatically. This function uses one of the included databinding APIs—DataGlue—to bind the result data, which in this case is a database recordset, to the empList listbox component. Simple string formatting commands concatenate the firstname and lastname fields as the display values, and the employeeID field as the data value for the list items in the listbox.
That's it: Two functions that handle the user interface event and server results, and a few APIs that handle remote communications and databinding.
Integrating Flash with the ColdFusion Server
In the past, ColdFusion was a proprietary application server with an easy-to-use server-scripting environment. With ColdFusion MX, Macromedia threw out the proprietary server and replaced it with industry standards. ColdFusion MX provides a rapid server-scripting environment that deploys to any standard J2EE application server, and provides interoperability with .NET through Web services and COM.
ColdFusion scripts and components dynamically compile into Java classes and are deployed into a J2EE container, enabling a much broader group of RAD and scripting developers to easily construct server-side applications, but still benefit from the standards support, integration with, and scalability of J2EE. You can think of ColdFusion MX as an "ease of use layer" on top of the Java platform.
ColdFusion Components
The employee directory example in the Remoting section of this article uses a new feature in ColdFusion MX called ColdFusion Components, or CFCs. As we developed ColdFusion MX, we wanted to help take scripting-level Web application development forward without forcing developers to become full object-oriented programmers or requiring the use of system programming languages such as Java and C#.
In particular, as the Internet moves to Web services and rich clients, scripting developers need to move away from the poor architectures of the first generation of Web applications, where business logic, presentation logic, and data access were all assembled together in pages and templates, creating a reuse nightmare and limiting application scalability.
To accomplish this separation, we introduced CFCs, which provide a script-based and declarative model for defining services using simple text-based templates. These services not only can be consumed as objects from ECMAScript-like languages, but are also exposed as Web services using SOAP and WSDL, and to Flash Player through Remoting. The benefit is that scripting developers can participate in well-designed architectures without having to become full-on enterprise middleware developers.
A very basic component that provides an echo of a helloworld string would look like this:
<cfcomponent>
<cffunction name="HelloWorld">
<cfargument name="theString">
<cfscript>
Echo = "#arguments.theString#";
return Echo;
</cfscript>
</cffunction>
</cfcomponent>
The actual name of the component is based on the filename, much like a Java class file. This simple component provides one function, which takes a string as an argument and returns the string to the caller.
The employee directory example defines an EmployeeDirectory.cfc document, which contains several functions: GetDepartments, GetEmployees, and GetDetails. If you look at the GetEmployees example in isolation, you can see all the code required to provide the server logic:
<cfcomponent>
<cffunction name="searchDirectory" access="remote" returnType="query">
<cfargument name="firstName" type="string">
<cfargument name="lastName" type="string">
<cfargument name="department" type="string">
<cfquery name="q" datasource="exampleApps">
SELECT tblEmployees.FirstName,
tblEmployees.LastName,
tblEmployees.EmployeeID,
tblDepartments.DepartmentName
FROM tblEmployees, tblDepartments
WHERE tblEmployees.DeptIDFK = tblDepartments.DepartmentID
AND tblEmployees.firstName like '#firstName#%'
AND tblEmployees.lastName like '#lastName#%'
AND tblDepartments.DepartmentName LIKE '#department#%'
ORDER BY tblEmployees.LastName, tblEmployees.FirstName
</cfquery>
<cfreturn q>
</cffunction>
</cffunction>
In this CFC, you can see a few additional things. The first is that the cffunction tag code defines two additional attributes, both of which are required to use the component through Macromedia Flash or SOAP. One is the "access" attribute, which is set to "remote"—this lets ColdFusion know that this component function can be accessed remotely, including from SOAP or Macromedia Flash. The "returntype" attribute sets the datatype that the function returns to the caller. In this case, the return type is a database query, which is a built-in type in ColdFusion and Flash Remoting.
Additionally, you can see that we've specified the data types of the required arguments, also necessary for proper WSDL and SOAP bindings. Finally, we're using the cfquery tag, which is a powerful tag that encapsulates all the complexities of using the JDBC APIs. We then return the query to the client using the cfreturn tag.
With the additional meta-data provided here, the CFC can be self-describing—making it easy for design-time tools and for Web services introspection using WSDL. You can get the documentation by simply pointing to the CFC using a web browser. That request returns auto-generated documentation on the component's interface. Likewise, you can append ?wsdl to any component URL and get the WSDL definition—hence any tool that can import and use WSDL for generating Web service client proxies can easily use any CFC that you've built.
Building CFCs and Server Logic
While you can create ColdFusion Components (CFCs) using any text editor, Macromedia has introduced a new version of its development environment, Dreamweaver MX. Just as Macromedia Flash and ColdFusion have undergone significant transformations in their roles, positioning, and capabilities, so too has Dreamweaver. While it continues to have great visual design and site development features, Macromedia added a broad range of coding and application development features. We've merged in the major features of HomeSite, Dreamweaver UltraDev, and ColdFusion Studio into a new integrated workspace.
We've focused particular attention on providing strong support for server-side development using ColdFusion MX. Dreamweaver MX provides full language support, including tools for code hinting, property inspectors, debugging, etc., but also specific tools for database, component, and Web service development. One of the central tools is the ColdFusion Component browser, which allows you to easily create and use CFCs. Dreamweaver MX also includes a Web services browser for easily working with SOAP Web services.
Moving Away from the Document-based Web
Macromedia is incredibly passionate about the Internet, and the role it can play in transforming our customers' work. But the Internet needs to be more effective for end users, and in turn for the companies that serve them. To do this, the basic architecture of the Web needs to evolve—moving to a model that combines rich clients with Web services, and content, applications, and communications. And therein lies the facility for rich Internet applications.
The idea of 'Internet applications' is a slight shift from 'Web applications,' reflecting the fact that while many of these applications will run in Web browsers, many will also be standalone, Internet-connected desktop applications. Many will be occasionally connected applications on laptops and wireless devices. And more and more, these applications will run with rich clients deployed in devices such as phones, PDAs, and interactive televisions. At Macromedia, we're trying to get people to expand their definition of Internet applications beyond the notion of the document-based Web.
Macromedia believes that Macromedia MX is a solid step forward for developers building for the Internet. But we also know there's a ton of work ahead, and major new opportunities for innovative technology that break the barriers that are in place today. The best thing we can do is learn together, work together, and trade best practices so we can all help deliver a next-generation Internet.
Jeremy Allaire is Chief Technology Officer at Macromedia. He was the co-founder and former chief technology officer for Allaire Corporation, which merged with Macromedia in March 2001. .
|
