Archive for September, 2005

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.

Watch some events fire…

Ever wondered about the event model that we use in PDF today?

Watch the events fire live…

Show me the PDF events

Did you know…

Adobe has launched a new developer program alongside our longstanding ASN (Adobe Solution Network) offerings, that is targetted at Java developers that want to expose their awesome skills through PDF forms and documents.

You can find this at Adobe Enterprise Developer Resources and I want to know why you aren’t all rushing over there and signing up right now.

I know – 18 month decision cycles, budget cuts, skills development and more contribute to staying on the course you are on. But, IMHO, it’s worth a look – and this program makes it easy to look.

Continue reading…

Feeling fickle: Let’s use POJO, JSF, Swing, Spring, and of course, some good old J2EE

{hold.on;
what.happened;
}

Suddenly there are a million ways to do things – JSF, POJO, Spring, Swing, Struts, Tapestry, Ruby on Rails, and on and on. Many of them do not stand alone and as such require overlap and lots of manual coding (although that’s half the fun) in order to get these variants to resemble a final application. This is especially true if we want that resemblance to emerge in the form of some type of UI. So off we go digging around the internet to find where one stops and another starts, where the overlap is, why is one better than the other. Be careful which book you read, which vendor site you end up on or which serverside discussion you end up in. Pick a side, pick a flavour, get a plan. Well, not today.

I still love my enterprise Java – good old J2EE. Not that I am so old fashioned, that I can’t change. But the reality is, we know the patterns. We have improved them. We have bloated them beyond recognition in some cases (oops!) maybe because of the community process but that is starting to turn around. And the good news – my boss understands the model and he knows he can move me on and replace me with someone else and they can pick up where I left off. Wait, is that a good thing? Aah, now I am starting to understand why we do the things we do.

Let’s tackle some of the technologies and in the spirit of having some good fun at my expense, I’m going to pick some sides based on how I’m feeling today and see where the conversation goes.

JSF reminds me of a loose cannon API or according to some developers “JSF is just not as refined as Tapestry.” Yes, it allows developers to use every other technology into the framework, in fact it actually forces developers to pull pull in other frameworks in order to make it suitable for consumption. But will we actually see software vendors reach out and embrace Tapestry just because it works, or does this leave no room for them to sell a “product” and therefore we won’t support it (I will get to this point in a later entry). JSF on the other hand is a completely different market animal; people need to be retrained, you probably should buy some tools, etc so that brings on the vendor support.

JSF-Spring provides the glue code for some comprehensive integration of JSF and Spring (thus the obvious name), but unfortunately this has been done in an implementation independent way which means you cant actually use it with JSF. Back to Tapestry for minute – you have to marvel at all that power with no invasiveness. But on we go in JSF, with relational databases and some other lagging techs dragged into the mix for good measure. Wait, I want to be implementation independent – what a luxury.

That makes it kind of like POJO – people don’t and won’t sometimes because it doesnt have a fancy name and a vendor stack and it’s maybe just too darn easy. When we were at JavaOne this year there was a lot of questions at the Adobe booth about running outside of the EJB container, moving off the app server, etc…but it was just that – discussion and questions. Are you using these emerging technologies? How are you using them? More importantly to me, what do you want vendors to do?

And as long as you can get to our APIs when you need them – do we really have to do to declare total support for this? It’s becoming so complex that I suspect I will need a small army of engineers to get through the responses to this blog.

For the record, how I really feel – it’s all good, it’s all Java, and that’s all good enough for me. I’m going to see who is available to help me get my next job done and I intend to absolutely base my decision on whatever they are really good at. Hopefully, it’s PDF-L at the end of the day (I like things in Reader instead of a browser), rendered through XFA (abstract away) and sitting on top of some Adobe LiveCycle APIs (whew, some good old J2EE) – but who knows, maybe they can sway me today. I’m feeling a little fickle. Maybe Flash…? At least it’s easy, and wow, is it ever beautiful when I’m done. I know my marketing counterparts will support me if it’s beautiful, even if my vendor of choice doesn’t – yet(smile). This is too hard…

An entire nation with a user interface

I am always intrigued by usability, both within software and without.

I have travelled all over the world meeting with developers and this week I am in Japan meeting with the press, partners and the Adobe team focused on the enterprise to help with the launch of our Adobe LiveCycle Workflow and our developer program here. I love Japan, but it never struck me before that a country could be a study in usability.

Everything seems so well placed – there is a way to do each thing and each thing has one way to do it (navigation). Everything has instructions (help panes) and I have not once been at a loss for where to find something or where to put something (file system).

Even the language itself. No words are mangled or misused (taxonomy). In working with the translator and with my limited knowledge of Canji I am fascinated by how easy it is to make a point. It is as though there is no opportunity for abuse of terms, rhetoric or sarcasm – I am sure it exists but I am not able to see it (obfuscation). I find this totally refreshing.

(Design) In talking to the few journalists, developers and architects I have met with I see the same meticulous approach to their work – and this all about software development. They take everything in and then think it through, often not raising questions about topics I have covered until some time later. What has happened to thoughtfulness? Why are we in such a hurry to make our points known that we cannot even listen effectively.

Then there are the customs – the ultimate study in usability. Language barriers, cultural barriers, class difference, etc all melt away through the observation of simple customs. Bowing, properly presenting business cards and gifts, presentation and meeting etiquette, not turning your back on groups you are departing from and a general sense of self-respect and respect for others prevails. (RT*M – it works)

As a coder, I would like to code this back into our genome.

I know we focus on HCI but why not HHI? I suddenly want us to start wearing suits to work again or at least leave the flip-flops at the beach, engaging respectfully and attentively in meetings again, putting the distractions aside for a moment and truly taking the time to see each other for what we can contribute.

Maybe thats just it – I can focus on this while I am here because I am technically 14 hours ahead of my inbox. I am sure it will all slip away once I get back home (engineering cutbacks) but I hope not (feature prioritization).

Even the Starbucks was right where I needed it to be – in the lobby of the office tower I am working in. (end user or vertical market customization)

I know, I know. I promised that this would be a useful blog. Starting now. (RTI)

This blog is a helpful blog

Starting now, this blog is a helpful blog. This blog knows not only where I am but also where I will be and where I have been. Starting now.

This blog is a Java blog. This blog knows that Java developers will build solutions on our platforms and using our products and that they need to talk about this. I need to talk about this. Starting now.

This blog is an Adobe blog. This blog is for Adobe things like Adobe LiveCycle and Adobe Acrobat. The biggest problem is those are a lot of things and there is a lot to talk about. Starting now.

This blog will throw exceptions. This blog should err on the side of caution since things are not always what they seem. In lieu of an editor some things will always slip through the cracks. This blog is a dangerous blog but only for me. Starting now.

If I add one more of these I will have to snap my fingers a lot. I should just blog. Starting now.