Archive for December, 2005

Adobe + Macromedia = (G) All of the above

1) Equals a lot of hard work that we have been doing to align our various product lines and the benefits of that are already apparent in the new bundles you can find on the Adobe store. I can get Dreamweaver with Photoshop? Sign me up!

2) Equals some best kept secrets that our team and many other teams have been doing to build some great sample applications – Macromedia Flex with Adobe LiveCycle, Macromedia ColdFusion with Adobe LiveCycle, Macromedia Flash with Adobe Acrobat and more… stay tuned to our developer centers for more on this.

3) Equals a new world of opportunity for developers interested in taking advantage of the largest installed interactive, multimedia, customizable, extensible platform for client applications. We have seen some great examples of this already and we are asking you to tell us what you are working on this area so we can better understand the new world of possiblity. Got something cool to share? Comment on this blog or send an email to

4) Equals time to roll up our sleeves and start the real integration work, not the integration of two companies, but the integration of two complete worlds of software that are already well established with business users, developers and designers. We are already working on the next version of LiveCycle here at Adobe and we are very excited about the opportunity this will present to us.

5) Equals a huge sigh of relief on everyone’s part. Us techie types don’t really spend a lot of time thinking about what it takes to really make a deal like this happen. Instead we tend to get right down in the weeds as soon as possible and start trying to reinvent the wheel (IMHO, square is underrated even though its a bumpy path to take). When it comes to mergers or acquisitions, we want to acquire the code instead of our rival, merge the data instead of our domains, optimize the runtime instead of the resources, and we really only need lawyers to be part of the focus group on the new UI.

6) Equals Integration above the API – encouraged and supported! You still bend the rules, you still break the apps, you still find the hidden features (yes, we have no buggy bananas), and you still have to make it do what you want it to. But, now we can actually help. In fact, this morning the first order of business was supporting an early example of very tight integration between Flash and Acrobat by some very talented developers. (more to come on this…)

7) An opportunity for a multiple choice question. Adobe+Macromedia = :

a) A sign of life for Web 2.0.
b) A truly everywhere client platform.
c) A real composite application development suite.
d) The beginning of the end of deployment-driven architectures.
e) One of the largest and fastest growing developer communities around.
f) A new face for Java.
f) A really cool bunch of awesome geekiness with all the requisite blinky lights and shiny knobs.

If you answered a resounding “Gee, yes, yes, yes” to all of the above, then you’d fit right in around here today.

Ed. note: Yes, he drank the koolaid – although it’s technically not his fault, Mike Potter actually drank some first and then slipped it into Ben’s coffee while he was busy talking up the person rumored to be his new boss. These things happen.

SOA, BPM and Documents

Matching the types and tiers of applications between SOA, BPM and Document Services might make me guilty of “marketecture” – the clever but generally obfuscating, vague and confusing PPT version of a real application architecture – but I have found the following to provide the basis for a very useful tool employed in explaining how to build a better mousetrap with LiveCycle and PDF-centric applications.

According to the AMR Research Market Analytix Report “Service-Oriented Architecture: Survey Findings on Deployment and Plans for the Future,” the dominant reason (48%) for people to embrace SOA technologies is the ability to configure business processes more quickly and flexibly. A growing number of developers are moving toward SOAs (intentionally in most cases) in order to meet challenges of both intra-application behaviors and the need for truly functional interactivity. This approach can automate the result of processes in a faster, securer, and more cost-effective way. While SOA is often used in many differing domains with different semantics, I like to use the definition of SOA as an architectural paradigm, or simply stated, a model for architecture.

Reinventing people’s processes by integrating documents or forms into SOAs involves some discussion on three technical topics: SOAs, BPM workflows, and document services. If we use 3 tiers to describe the SOA overlay on the core applications and we assume that each tier has three elements, then each element in a tier interacts with its corresponding counterpart in another tier. Now I wave the magic technology marketing wand and the three tiers apply to other technology trends like BPM, workflows, and document services. Then I spin the three ideas to align around the necessary application components and “abracadabra, ala-shazam” I have provided a method to describe an open architecture and standards-based approach to developing applications that utilize documents as the interface and enable IT developers to add or eliminate services to meet changing technical requirements or business needs.

The SOA afficionado builds applications as services. SOA can be defined using three different views or elements that are required:

1) Applications: The developer breaks down underlying artifacts and improves the aspect orientation of discreet units of application or business logic.

2) External interfaces: This developer exposes both configuration interfaces and activity interfaces.

3) Transport: The developer enables SOA by providing transports to the collection of services within composite applications.

The BPM or workflow architecture gets applications oriented around workflows so that services can be integrated into BPM applications. Three types of workflows can be persisted from your SOA up to the document layer:

1) Intra-application workflows: Developers combine the services interfaces of different applications, essentially exposing and serializing APIs to create new functionality or new transaction types that persist across several applications or infrastructure layers.

2) External workflows: Developers can externalize business processes and workflows to interface to a set of pre-existing applications. What is needed is a way to represent expose services or represent transactions and data to the various business stakeholders.

3) Human-centric workflows: Developers can provide interfaces for people to access the various functions. This access can be granted based on the roles of the different actors that need to request, submit, review, or approve the things that cannot be automated through technology alone. Even if these transactions can be automated, they often still require some type of intervention in order to provide approval or input..

Documents services can be used to link security services to a specific document, create and bind policies to documents, and expose enterprise data as documents with read and write permissions for authenticated users. The following three elements comprise the baseline of document services:

1) Document services: Developers can deploy document services on the same layer as other services and therefore can be easily combined with other applications that require access to the API. Not only can we process requests using these services, but we can also impact the way in which applications process information contained in the specific document functions. Further, these transactions can now be handled as secure communications inside and outside a firewall.

2) Document templates: Developers can dynamically assemble intelligent documents at runtime using data and logic constraints in the XML or code. Intelligent documents are actually secure, dynamic digital containers for delivering and executing document services. The documents integrate XML content and high-fidelity presentation in PDF with powerful business logic that drives form or document design behavior. Built-in capabilities include calculations, routing instructions, error checking, digital signatures, and data validation. Data in XML can be imported and extracted automatically.

3) Document clients: Users interact with the documents through universal clients. Examples of universal clients include standard web browsers or free software to enable people to view and engage with interactive, quality digital documents anywhere at any time. Adopting accepted standards like web interfaces and PDF is critical because it offers users uninterrupted access to materials now and in the future.

Given the similiarity and the dependencies in each of the three tiers, a simplistic comparison can be applied to show how the approach we are taking to manifest documents as the end-user interface for large applications is therefore an instantiation of an SOA.

1) There are both application logic and a message bus required to instantiate application interactions. In this layer we can consider the folowing:
Application = Intra-application workflow = Document services

2) There needs to be an application interface or some technology provision for external interaction that is schema-driven. Given that:
Application interface = External workflows = Dynamic templates

3) A useful container generally requires a client that provides the usability to these interfaces, and unlocks the workflows, data and interaction required to carry out the application functions
Transport = Human-centric workflow = Interactive forms and documents

In each of the examples above, the dependencies roll back into the previous. For example, an interactive form assumes the existence of and represents human-centric workflow and has a dependency on a mechanism for transport. Simply put, email me the form and I will submit the data from here. It’s not about redundant technology, it’s more about abundant technology and, IMHO, this is a logical extension of where you might already going. If you clicked to this blog from the Macromedia MXNA, then this blog is a document that went through a workflow and exists in a services oriented architecture.

No actual developers, code or architectures were used or harmed in the creation of this entry, yet. The almost entirely fictional representations herein are meant to provoke thought, not debate, and any resemblance to marketing or technical literature is purely coincidental.