| Macromedia MX and
Web Services. |
 |
| By Jeremey Allaire |
 |
| Macromedia MX combines clients, servers,
and tools into an integrated family that will
deliver rich Internet applications. It deeply
embraces the idea of deploying and using "software
as services," though the MX approach
goes beyond many of the current notions and
discussions in the industry about Web services.
|
 |
| What's
the Big Idea? |
 |
| Over the past couple of years, an idea has
emerged (some might argue it's an old idea)
that software will be transformed into being
used as services, rather than as monolithic
applications tied to a specific machine or
platform. Rather than install software onto
computers every time we need some functionality,
an end user or corporation can reuse other
application assets over the network. The idea
expands into the notion of just-in-time delivery
of applications. "Software as services"
is a big idea. It holds the promise of introducing
radical new economies of scale into the manufacture
and distribution of software applications.
From an end-user perspective, it's the idea
that users can access information and applications
anytime, anywhere, and from any device. |
 |
| This is a powerful set of ideas. It's the
idea that the value we create in software
can be freed from any single delivery platform.
It's the idea that rich applications can be
used easily across platforms and devices.
How close are we today to realizing this set
of ideals? |
 |
| The Web
Services Industry Today |
 |
| The phenomenal focus on Web services over
the past year is interesting when contrasted
with the actual set of technologies available
to fulfill this vision. When comparing the
broader vision for software as services to
the current world of Web services technologies
- protocols like SOAP and formats like WSDL
- it looks more like we're perhaps 25% of
the way toward fulfilling that vision. |
 |
| Today Web services are primarily talked
about through the lens of specific protocols
- SOAP and WSDL, perhaps UDDI, though I've
yet to find a customer who's really using
UDDI in any significant way. This early focus
and discussion is great; finding the holy
grail of a common protocol for exchanging
objects and data between platforms is an incredible
achievement, and the fact that the industry
is so focused on it gives us hope for the
future of interoperable and open software.
|
 |
| But even the current crop of technologies
implemented around these standards has problems
and challenges. In the Web services model,
application logic is well structured, often
as component services. In actuality, the need
to deliver well-structured applications has
largely eluded Web application development
over the past years. In fact, we all know
that close to 75% of Web applications aren't
well structured; they're conglomerations of
dynamic pages, including scripting languages,
database code, and presentation logic all
together. Indeed, the desire to move to component
middleware standards such as EJB, CORBA, and
COM has been manifest mostly in the world
of high-end architectures within large corporations
rather than in the mainstream of Web application
development. |
 |
| As such, there is a huge disconnect between
the need for well-structured Web services
and the reality that most Web applications
are built using 4GL scripting languages, usually
are unstructured, and rarely meet the requirements
of thoughtfully designed object-oriented systems.
|
 |
| Let's assume for a moment that Web services
are strictly defined as the middleware standards
for messaging and object marshaling - for
example, SOAP and WSDL. Even in that world,
the vast majority of Web application developers
aren't well positioned to both create and
consume Web services without becoming full-on
system programmers using complete object-oriented
environments such as Java or .NET. The back-end
world of Web services needs to evolve to make
it simpler for RAD or scripting-level developers
to easily create and consume Web services.
It would be a huge victory for the industry
if those 75% of Web applications built with
scripting languages could also share their
value and data with other applications. |
 |
However, the focus on Web services through
this lens largely relegates the topic to discussions
of classic back-end middleware rather than
a more holistic view of what's necessary to
deliver software as a service. Strikingly
absent from the current discussion of Web
services is any notion at all of what the
end-user experience is of these "software
services." This is due in part to the
type of vendors thinking about Web services
- for example, traditional enterprise middleware
companies - but it's also because of the hard
work required by interoperable messaging and
object protocols.
These are necessary conditions to any future
for software as services. |
 |
| Getting back to the original vision of software
as services, it's quickly apparent that we
need a much more holistic discussion and framework
for thinking about Web services, one that
actually includes end users using this software.
What would an end-to-end model for Web services
look like? |
 |
| The Missing
Piece: Rich Clients and Web Services |
 |
| Many of the early visions and discussions
of Web services centered on the idea that,
in the future, software could be used as a
service rather than as monolithic applications
that needed to be installed and used on our
desktop computers. While the Web has made
progress in delivering applications easily
to browsers, the world of Web services would
take it further by delivering the experience
of desktop-quality software that can be consumed
as a service. Visions of using "productivity
applications" as services were common
interpretations by the industry. Examples
such as Hotmail and Salesforce.com were cited
as leading indicators. In this future world
of software services, end users could easily
access rich applications from any desktop
computer; these applications would always
have their personal information, would be
interconnected with back-end systems, and
could even be portable across devices. This
new world, however, would leave behind the
document-based or page-based model of the
Web for one that was much richer in terms
of application capability, and that extended
beyond the browser onto desktops and devices.
|
 |
| What is the user experience of Web services?
What's the model for combining rich interfaces
with back-end middleware to deliver exceptional
new value for end users and the companies
that serve them? |
 |
| Macromedia believes that the perfect complement
to Web services as middleware is the emerging
category of rich clients. Indeed, it may well
be that rich clients and Web services are
two sides of the same coin, combining to enable
this world of software as services. |
 |
| What are these rich clients, and what do
they require to really meet the requirements
of transforming the user experience and providing
the logical front-end to back-end Web services?
|
 |
| Rich clients should combine rich content,
applications, and communications in a single
client environment. By rich content I mean
richly formatted text, graphics, audio, and
video. By applications I mean both rich, complex-user
interfaces - the kind we expect from a modern
desktop computer - and application logic and
data deployed in the network. And by communications
I mean the ability for end users to interact
through these clients, to share data, text,
audio, and video in real time and nonreal
time. Rich clients should provide these capabilities
in an integrated manner, where the applications
that can target them far exceed what is possible
in the world of HTML documents. |
 |
| Rich clients should allow applications to
run in browsers, but also as standalone applications
on desktops and laptops. They should also
support running on devices. To support these
new Internet-connected application types,
they should support offline data storage,
enabling occasionally connected devices and
applications. |
 |
| Most important, rich clients should anticipate
the emerging world of back-end Web services
by using a services-oriented architecture
for integrating business logic and data across
the network, whether that's simply contained
in an application server or actually a distributed
Web service exposed through a protocol like
SOAP. |
 |
| Rich clients and Web services combined hold
the promise of fulfilling the broader vision
that the industry has for deploying software
as services. The combination will enable rich,
business-connected productivity applications.
It will transform what's possible on the Internet
today. From now on, when people ask you what
Web services are and why they're significant,
make sure your worldview encompasses this
broader perspective on software as services.
|
 |
| Macromedia
MX and Web Services |
 |
| As might be expected, Macromedia has focused
on delivering a holistic approach to Web services,
one that provides transformative technology
for the client, server, and development-tools
aspects of Web services. |
 |
| ColdFusion
MX: An Approachable Web Services Environment
|
 |
| Starting with the more common world of Web
services as component middleware, Macromedia
has introduced major new Web services capabilities
in ColdFusion MX, the latest release of this
rapid server scripting environment. For those
not familiar with CFMX, it's a fundamental
shift and repositioning for ColdFusion in
the industry, moving from being a proprietary
application server to a rapid development
and scripting environment that runs on any
popular application server, such as IBM WebSphere
or Sun's Sun ONE. |
 |
| Specifically with Web services, Macromedia
focused on delivering a Web services engine
that would empower RAD and scripting-level
developers to easily construct and consume
Web services. |
 |
| Using a technology called ColdFusion Components,
or CFCs, scripting developers can add simple
tags that provide metadata for defining a
service and then include arbitrary script
inside that metadata. The result is a well-defined
component that provides a services-based interface
(see Figure 1). Underneath, CFCs are dynamically
compiled into JavaBeans and hot-deployed into
the containing application server. This gives
the mass of scripters the ability to easily
construct server-side logic that can immediately
be exposed through SOAP and can also be used
by rich clients, such as Macromedia Flash
Player. |
 |
| The ColdFusion MX Web services engine is
actually based on Macromedia's active involvement
in the Apache Axis project, with strong contributions
from IBM and others in the Apache community.
It is the first commercial server to use this
powerful new open-source Web services platform.
|
 |
| While CFCs allow developers to create Web
services easily, ColdFusion MX also includes
approachable capabilities for consuming and
using Web services. Developers can declaratively
invoke any Web service and Web service method
at runtime; ColdFusion will dynamically generate
Java client proxies that handle all the SOAP
interactions, and actually transform SOAP
results into local variables that can be used
from script. Developers don't need to think
about parsing SOAP or WSDL, or even of manually
building client proxy skeletons, let alone
having to invoke interfaces on those proxies.
|
 |
| Web services can also be imported into a
script and used as tag libraries, with each
method on a Web service exposed as a custom
tag, enabling even HTML-level designers and
programmers to use Web services. |
 |
| Flash
Player 6.0: The Internet's Premier Rich Client
|
 |
| In line with our more holistic view of software
as services, Macromedia is leading the way
with the introduction of a powerful rich client
for delivering Internet applications. Macromedia
Flash Player has evolved into being a complete
environment for delivering rich user experiences
across browsers, operating systems, and devices.
|
 |
| Over the last several years, Macromedia
Flash Player has emerged as the most ubiquitous
client runtime on the Internet. With more
than 98.3% of Internet end users having a
version of the player, it is now the most
widely deployed software environment in the
history of computing. Since the introduction
of Flash Player 6.0, we've distributed well
over 100 million new runtimes, averaging almost
3 million downloads per day. Packed into this
new player are powerful new capabilities for
delivering applications. Flash Player now
provides a more complete programming environment,
a visual component model, and fantastic new
rich-content types |
 |
| Most important, we've introduced technology
for connecting rich client applications with
back-end services. Dubbed Macromedia Flash
Remoting, this technology provides a high-performance
connection between rich clients and back-end
services, no matter what the back-end platform
or model. Flash Remoting supports using services
deployed as CFCs and scripts, Java classes,
JavaBeans, EJBs, JMX Beans, C# objects, ADO.NET,
and ASP.NET pages. With these services it
provides a high-performance binary connection
- running over HTTP - between server objects
and client objects. |
 |
| Additionally, Macromedia Flash Remoting
provides a simple mechanism for connecting
Flash to SOAP Web services, even services
deployed on networks and servers that are
different from the application's origin domain.
Crucially, browser-contained Flash applications
follow a strict security sandbox, where they
can make requests only to their originating
domain. Flash Remoting provides a server-based
proxy to any SOAP Web services. |
 |
| Nonetheless, the Macromedia Flash Remoting
model uses a services-based architecture that
is back-end independent: client code can use
services without ever knowing the type of
back-end implementation. |
 |
| Dreamweaver
MX: Creating and Using Web Services |
 |
| Two tools in Dreamweaver MX stand out with
respect to creating and using Web services.
Dreamweaver MX includes development tools
for creating CFCs for easy authoring, providing
one of the quickest ways to create SOAP-accessible
Web services. It also includes significant
tools for using other people's Web services.
The Dreamweaver MX Web services browser allows
you to point to any WSDL file or UDDI repository
and import a Web service into the development
environment. This provides a visual browser
of the Web service's interface, and will even
generate client proxies for .NET and Java.
Once developers find a method they want to
use, they can drag-and-drop these into their
code and Dreamweaver will create the basic
invocation code automatically. |
 |
| Studio
MX: Tools for Creating Web Services |
 |
| With the MX product family Macromedia has
both broadened and focused its suite of design
and development tools by providing an integrated
suite called Macromedia Studio MX. |
 |
| Studio MX provides everything needed to
rapidly create everything from content and
graphics to rich and complex user interfaces,
server-side logic, and components that interact
with XML, databases, and Web services |
 |
| In the MX family Macromedia Flash MX provides
the primary authoring environment for creating
rich client user interfaces, evolving from
its early heritage as a motion graphics design
environment to a complete application development
tool for client-side applications. Likewise,
Dreamweaver MX has also been transformed from
being the premier Web authoring and site development
package to a complete IDE for Web application
development, including powerful new programming
and database tools and support for XML and
Web services. |
 |
| Software
as Services: Make It Real |
 |
| Macromedia is passionate about the idea
of using software as services. We believe
in a holistic view that encompasses both the
front-end user experience and the back-end
integration layer. Our hope is that by making
Web services approachable and affordable,
all of us - not just the legions of advanced
programmers and classic middleware developers
- will be able to take advantage of what they
have to offer. Building for the next generation
of the Internet should be fun - let's make
the Internet interesting again! |
 |