SOA – a Spock-Oriented Analogy

Next week I am giving a talk at the XML Conference and Exposition 2005, which is the one show that is the source for everything XML and just XML, running November 14-18 at the Atlanta Hilton in Atlanta, Georgia. You can find out more at http://www.xmlconference.org.

We also attended the sister conference XTech in Amsterdam earlier this year, and that was a great gathering of gurus with groovy gadgets grinding on the topics driving SOA.

This particular 3-hour cruise entitled “Web Services and Architecture: The Next Generation” takes place on Monday morning (stardate 11.14) as part of the pre-show tutorials. Forgive the trekkie title, but it is a bit of an episodic where the actors change daily, and we are constantly pouring over the trade rags to find out the latest on their relationships. We also toyed with sub-titles like “Back to the Enterprise” and “Thoughts from the Bridge”, but in the end we called it like it is. The next generation, which is to say the one right before the next one after that.

“We are going to run out of ‘unobtainium’ any minute now…I’m giving her all she’s got, captain.”

Like many technologists, I confess to being a little embarassed when I think that I probably spend more time talking about SOA than I do actually executing on it. I have been speaking on Web services standards and SOA for over five years and I keep promising myself that this is the year when I will ask the question, “Who out there is doing SOA now?” and everyone will put up their hand. I’m counting on you and I can honestly say that we get to put our collective hand up with the work we are doing on the LiveCycle platform at Adobe.

If we go back about five years I remember reading in a published study that more people were planning on doing web services than were actually aware of what they were. In other words, the awareness stat was lower than the adoption stat. Strange science indeed, but it struck me then and it does again, that the reason this was the case was that it was so complicated (yes, even then), was that in order to truly understand it you actually had to plan for a launch.

IMHO, I am not sure my talk at XML 2005 will remove the necessary cloaking devices but I do know that it is going to be a full three hours or more of up-to-the-minute, feet-first diving into the standards forces that are at play. And, I do know that I am counting on the fact that the discussions following the talk and during the course of the four day show will take me to parts of the galaxy I didn’t know existed.

Trust that I’ll update you as the voyage continues…

Use Java tools to test XFA forms and applications

Today we launched testing tools and samples that run in both JUnit and Rational Robot for forms and applications that are based on Adobe LiveCycle software.

The two test cases provide a framework for automated testing of XFA-based PDF files developed in Adobe® LiveCycle™ software. They allow you to programmatically get and set various fields in an XFA-based PDF form, click buttons, and execute various JavaScripts embedded inside a PDF document.

With these functionalities, you can build more complicated test cases. Note that to run these test cases you must have Adobe® Acrobat® Professional installed on your computer.

This download is available as part of the enterprise developer program and this is limited to members only. If you would like access to these samples and are not a member, please let me know.

Developer pre-release for our new forms designer

We are currently hosting a pre-release program for our newest version of Adobe LiveCycle Designer. If you are interested in being a part of this, send your contact information to dev_info@adobe.com and request access to the Designer PreRelease.

For our thousands of users that are out there, this is a pretty exciting release and definitely has a lot of the features you have been requesting. Here is a list of what’s new in LiveCycle Designer 7.1:
– Tables (Yay! You could do this before with script or design objects but the new wizard is super slick)
– Language-Specific Features for Arabic, Hebrew, Thai, and Vietnamese
– New Paper Forms Barcode object
– Dynamic form object properties
– Descriptions in the Hierarchy and Data View palettes
– Controlling subform breaks based on data

Tables
LiveCycle Designer now lets you create simple, complex, and nested tables. You can quickly create a static or dynamic table using the Table Assistant. Static tables have a fixed number of columns and rows while dynamic tables have a fixed number of columns but the number of rows in the table will change depending on how much information is in the data source.

Language-Specific Features for Arabic, Hebrew, Thai, and Vietnamese
LiveCycle Designer now supports Arabic, Hebrew, Thai, and Vietnamese. The characters in Arabic, Hebrew, Thai, and Vietnamese are context-sensitive, that is, different images are used for the same character depending on its position within a word and some characters are made up of a combination of several characters. LiveCycle Designer now supports right-to-left or bidirectional text which occurs when texts of different direction orientation appear together.

New Paper Forms Barcode object
With LiveCycle Designer, you can add two-dimensional (2D) barcodes to interactive PDF forms using the Paper Forms Barcode object. You can then publish the barcoded forms to a website or distribute them by email or CD. When a user fills a barcoded form by using Adobe Reader, Acrobat Professional, or Acrobat Standard, the barcode is updated automatically to encode the user-supplied form data. The user can submit the form electronically or print it to paper and submit. Using LiveCycle Barcoded Forms you can later extract the user-supplied data as part of an automated workflow, routing the data among approval processes and business systems. When integrated with LiveCycleWorkflow, a single unified forms process can easily support different paper form submissions, each with their own specific workflow.

Dynamic form object properties
LiveCycle Designer now lets you set up dynamic properties for form object properties. This means that you can assign values from a data source to form object properties that LiveCycle Designer updates at run time. For example, the items in a drop-down list can be populated with a list of countries that are stored in a data source.
Dynamic properties allow you to modify form object properties outside of the form design and rely on a data source. This can be useful in deployment and maintenance scenarios. In addition, the same data source can supply data to different form designs. For example, a long list of countries can be stored in one data file and used in many forms. You can use dynamic properties to implement functionality formerly possible only with scripting.

Descriptions in the Hierarchy and Data View palettes
You can now view captions or descriptions of the objects in the Hierarchy and Data View palettes. These provide more information about the objects when you are building a form.

Controlling subform breaks based on data

You can now use conditional breaks to manually specify when and how to manage subform breaks. Conditional breaks allow you to verify data for a field within a repeating subform against previous instances of that field. The repeating subform can then be broken up according to the change in the data supplied to the field, and if required, automatically generate a new page.

Compatibility with version 6
You can use the Compatibility tab in the Form Properties dialog box to update forms that were created in LiveCycle Designer version 6 to version 7. If the older form will be viewed primarily with Acrobat 7.0 or Adobe Reader 7.0 or later, use the Compatibility tab.

Send us an email and we will get you access to the software right away. Use the forums or mailing list there to give us feedback on the new version.

Can a web service start a workflow?

Developers have been looking for additional guidance and support on initiating Adobe LiveCycle Workflow processes from a web service. They are interested in understanding how kicking off a workflow is accomplished using web services or ultimately how processes are initiated using third-party apps.

Chris Trubiani, who is one of our developer support engineers for the Adobe Enterprise Developer Program walked me through this, and I think it is worth sharing.

To initiate a workflow from a third party app, you would typically use a web service call. You wouldn’t use the LiveCycle WorkFlow API for that as the API needs to be used from within the context of the Workflow engine and your app would not be running in that context.

It is not possible to provide meaningful sample code for something like this since the code is ideally generated by some third party tool, and is unique since it is based on your wsdl. But I’m going to tackle the points involved and hopefully that will get you off to a good start with understanding the procedure.

The first thing is to create a process and deploy a workflow in it. When you create the workflow make sure to check the “Web Service Access” box so that the workflow will be available as a web service.

Once the workflow is deployed the wsdl will be available at the URL: http://ServerName:Port/services/ProcessName?wsdl

– ServerName is the name of the server that LCWF is hosted on.
– Port is the port that JBoss is listening to (usually 8080).
– ProcessName is the name of the process you created and deployed the workflow in.

In your code you would create some proxy code that allows you to access the web service. Your IDE of choice should have a tool that will generate this automatically for you when you pass it the URL to the wsdl.

For example, in WebSphere if you create a Web Service Client and give it the URL to the WSDL, it will automatically generate the necessary proxy code. Using this you can access the web service by calling the methods in the proxy code.

There are four methods exposed by the web service:

– invoke()
– synchronousInvoke()
– getResult(long)
– getStatus(long)

These are fairly self-explanatory names but you can find a description of what these methods do in the javadocs that come with the Workflow SDK in the com.adobe.workflow.manager.ProcessManager class.

There are lots of ways to kick off a workflow with human interaction, like the actual submission of a form, but this is very useful when doing integration using a workflow that is outside of the core application.

Props for XML, Data and the Document

In this year’s Intelligent Enterprise Readers’ Choice Awards, Adobe was named winner in the categories of Best XML Authoring, Managing and Publishing Application, and Best Data and Document Capture System. Every year, Intelligent Enterprise polls its readers to gauge the best in a variety of technology categories. While specific products were not called out in the final categories, it is great to see us getting a nod for our platform and tools. I have to say that this award really belongs to our product and engineering teams.

Patterned after this

One of the big objectives for us next year is to deliver architectural patterns, as public content, that outline all of the top applications of our platforms and products and how to design them as independent solutions or into core infrastructure or to be delivered as services. Of course this brings up the age old engineering requirements vs. use cases debate and the architects’ struggle to define a methodology for knowledge transfer that is universally acceptable.

I am still undecided on the approach from a documentation perspective, but one of the most interesting things that I have seen regarding this in a long time is a paper that was authored by Matt McKenzie and Duane Nickull. I noted that it is not version 1.0 yet so I hope I dont get in trouble linking to it, but the location of the document is http://www.nickull.net/work/MacKenzie-Nickull_ArchitecturalPatternsReferenceModel-v0.91.pdf

In this document, Nickull and MacKenzie propose a meta model that constrains instances of patterns in order to “provide a framework for the decision-maker to view the business from a different perspective from the engineer.”

Based on this, if we were to publish reference architectures that mapped to such a meta model then architects designing solutions that include our applications could have questions answered, RFP responses filled in, sub-patterns applied to their patterns, and business level descriptions of the solutions provided in context of their overall recommendations.

The interesting thing about this approach is that architecture could become both an instance and a reference, and both static and a living set of documents or patterns. The parent child relationships could scale up to the business case and down the OS-specific mappings for requirements.

For example, things like performance benchmarks could be easily inserted alongside physical deployment models, and directly correlated to geographic failover policies. The logistics for providing these services could then be referenced from external service providers.

This would change our thinking about accountability, responsibility and the delivery of thought leadership within the context of a properly managed discovery process. The creative input of the entire team would always remain in context. And most importantly, the tedious business of proposals could now contain an exciting level of detail that for the most part, would automatically be rendered at runtime. This render would be up to the minute collaboration and purely based on the quality of creative thought that was applied to the problem.

Of course like anything that is services oriented, this could be harder at first, but, IMHO, the payoff would be well worth it.

Good-bye Tokyo, hello planning process….

It’s transition time for me. I am busy putting a year of work behind me to get the Adobe Enterprise Developer Program launched in North America. Right now, I am heading back from Tokyo which was the first leg of my journey to roll it out for the rest of the world.

At the same time we are kicking off our planning process to identify what my team is going to be focused on for the next year. Planning ahead, you say? Yes, I think beyond a year (most of the time to my boss’s dismay) but for a few weeks I am going to put on some serious 12-month blinders and roll up my sleeves for the task at hand.

For the record, Tokyo was awesome. The Adobe office in Japan is packed with genius and they are working with us to bring the program to Japan. The Japanese press received this news well and depending on how your Canji is you can read my interviews online at IT Media and Enterprise Watch. I tried to babelfish them for translation but it wasn’t much better than watching the new version of the HitchHiker’s Guide to the Galaxy on the TV in my hotel room – somehow it’s just not the same and it gets a little lost in the translation.

ed. note – That was a potential obscure reference there to the fact that the BabelFish was actually a fish that you put in your ear from a famous movie about hitchhiking around the universe. You put the fish in your ear so you could understand alien languages.

I have spent a lot of time putting fish in my mouth over the last week and even though I could barely understand most of the waiters I met, I never once tried putting it in my ear. Instead I relied on my handy phrase book or the translator that Adobe in Japan had graciously provided me with.

Anyway, as we plan for next year, and as our planned acquisition of Macromedia moves forward, I am wondering what you are thinking about, especially when you think of Adobe in the future. What do you think we should be doing? Do you have any big questions that you feel are unanswered? Do you think we are on the right track? I have gotten a lot of feedback and talked with developers around the world but I still want to hear from you – this is your chance to get in on the plan for the future.

These are exciting times, and I am very curious to see what opening my blog up during the planning process does for the benefit of the community at large. Post a comment here or send email to dev_info@adobe.com – that is my team’s public email address for any and all issues, thoughts, questions, etc. Thanks in advance for the input.

And now I fly, back to the land of the brave and the home of the free. The funny thing is that although I arrive only hours after I leave, I will actually miss a day of blogging – so go ahead and take your time getting back to me (smile and wave).

Processes and the people that build them

A workflow is not always going to be a business process. To help sort this out we can define a business process as a set of actions required to achieve a business objective, and separately define a workflow as the management of the actions in a business process. Business rules are then used to define the logic of a business process and dictate how process information flows from one individual or system to another.

We will see workflows that are broken into two separate groups. There are the application-centric workflows where the information is not formatted for presentation since there is no requirement for human interaction. These are important and a lot of people are working in this space. Adobe remains more concerned with the document or form-centric (human-to-human) workflows where both the data and the formatting can pass from action to action as a single piece of information.

Forms or documents that are used in our workflows should be created with either Adobe LiveCycle Designer or Adobe Acrobat, but of course the Designer-generated forms saved in XDP (I will blog on XDP later) format provide greater flexibility, easier separation of data and you can embed the schema to help you or others locate data.

Who does all this work? From my perspective you can define a useful set of roles for building out workflows – where outside the normal system administration and management, you need a subject matter expert for things like security, database, web services, and of course the J2EE Application developer, the form developer, perhaps a business analyst and finally the workflow administrator. One person could wear all these hats or you can easily define life cycle procedures to manage the apps, versions, etc as you share and collaborate on building applications.

To do this successfully you are going to need to get your hands on the SDK for LiveCycle Workflow so that you get the QPAC Development Environment. This is just a plug-in for Eclipse that gives you a wizard-like environment to create deployment and design-time dialog boxes. Once you are done the same plug-in lets you test the QPAC and import it directly into the workflow engine. I posted earlier on QPACs (Quick Process Action Components) but they are basically a Java component that is defined by a service class, a dialogue class, some metadata and the necessary application resources.

We enable business processes through workflows, but when it comes to workflows – you still have to build them. In my previous post, I gave some suggestions on places to start learning how.

A cycle of live events on LiveCycle

A lot of questions I have been getting focus on getting training on our platform. While we are working to get more and more resources to help you get started on the new technology at our website we are also starting to tour a lot more. You can catch us at the Intel Developer Forums in Asia and India this fall – and we will be at XML 2005 in Orlando in November as well.

We are doing a webcast on how Adobe’s LiveCycle Workflow and Intelligent Documents make application building fast and easy for Java developers. Here you can learn how our process management solutions can enable you to build, automate, manage, and track processes through Java-based Quick Process Action Components (QPACs), the building blocks that you use to visually assemble workflows. This takes place on October 25th and you can register at http://www.adobereg.com/java/User_Info.asp

Adobe Developer Days are all day events that take place throughout North America diving deep on developing applications for both Adobe Acrobat and Adobe LiveCycle. Meet the SDKs and some great developers that really know how to wingman their way through our apps. The dates and cities are:

November 8th Seattle
November 9th San Jose
November 10th Plano, TX
November 15th Boston
November 16th New Jersey
November 17th Chicago
November 22nd Ottawa
November 23rd Toronto

Find out more at our events page

If you are already using our technology why not start your own user group? They are starting the Adobe Enterprise Solutions User Group in Chicago, IL. This is being kicked off at the Doubletree Conference Centre in Downers Grove, Illinois on Thursday, October 20th from 1:00 PM – 5:00 PM.

This user group meeting will include presentations by Adobe and existing customers, as well as technical and business focused breakout sessions. The cost is free and includes a cocktail reception after the event.

There are also a bunch of pre-recorded webcasts up at our webinars page

Should we be coming to your town? Is there something you would like to see us doing at events that we are not doing now? Let me know…happy coding.

Components + Context + Abstraction <= Workflow

I have been doing a lot of presentations on the new Adobe LiveCycle Workflow for developers, technical press, partners and others. In these presentations most of the discussion turns to the benefits for the application developer. Since the primary focus is on the build scenarios, change management and other topics roll up into these discussions around building applications using a services-oriented approach and then delivering final applications as workflows, or composite applications. What are the benefits of a workflow-driven application and how does Adobe provide some leadership in this area with our new server products?

When we look at code that has been written by another developer it can be very difficult to comprehend, especially if we are not aware of the model that the developer used and do not have insight into some documentation relative to the code. This latter best practice is just not practiced enough. Once code is compiled or actually executed, the code itself is lost. So even if the best documentation standards are practiced, large applications that are generally written by several developers would compound this complexity and make it more difficult to understand.

Large applications are broken into many objects or procedures. When executed, this is encapsulated, along with data usually, and then delivered up to the end user as interface or data. But if we look inside the applications, it would be no surprise to see data being handed off from object to object, dependencies frequently in a variety of .java files, and more and more now, applications being composed of many different java components, either vendor supplied and extended or hand coded, or potentially deployed as components.

If we can disassemble the entire application, step through all of the lines of code – we can usually determine the original intent, identify the objects and dependencies and then begin to make changes as required.

There has to be an easier way. IMHO, workflow design and development, and let me plug Adobe LiveCycle Workflow Server, is what provides that better way.

Components: We both suppy components and provide a plug-in environment into Eclipse for building these components that we call QPACs (Quick Process Action Components). A QPAC may contain several code objects but they should be deliberately grouped around one physical object – a user, a database connection or perhaps a service provided by a separate server product and accessed through Web Services or RMI. Several developers can work on one project, each providing QPACs and when another developer comes along and works with these components, it is much easier to fathom the intent of the original application.

Context: In the LiveCycle Workflow Designer, we have a visual view of all of these components in context, generally with self-explanatory iconography. This visual view is akin to the original architecture renderings that would have been built for the application. This intuitive approach is not only great for building applications, but also makes it very easy to understand what other developers intended. I have opened workflow diagrams from other developers and within minutes I can describe the intent of the application, how the code is being executed and most importantly, I can easily determine where to go and what I will need to do in order to customize the application.

Abstraction: When I look at a component within a workflow at the code level, I am generally looking for a few things – the objects, the variables, strings, etc. With QPACs I do not need to go to the code unless I want access to the object. I can change the variables, strings, etc and the actual data that is returned to these variables all from within the interface. In some cases it would require going to the actual code, but if I can step through the process, modify queries, generate XPath expressions and more all from within a visual environment, then that is much more productive.

These are just some of the examples of how using a workflow paradigm can help us in our development, but I think we can benefit from this kind of approach in all of our applications. SOA is not BPM, but BPM with SOA can be a better way to build an application and it should help a lot when others need to modify or change elements of the app itself.