Hi.

A new release of Eloquence means more changes.  In the past I have been intentionally vague, as that makes my keepers happy.  It is not what I would prefer, but there are numerous reasons for their concern, and I feel it best to honor them.

We have done a lot since the first release of version 2.  The primary focus became the removal of EJB's.  I can say that they are all gone, now, as we are using POJO's throughout the services.  The reason was driven from my dislike of EJB's, based on what their cost-to-return ratio.  By that, I mean that I could find no justification for their complexity.  To many of you, this is heresy.  To others, it is what you have already done, and you are wondering why it took us so long.  Well, it took awhile to get away from our fixation with what was viewed as the "proper way" to use WebSphere Application Server (WAS).

We like WAS.  We will continue to use WAS.  We had been asked to use other applications servers, however, and the use of EJB's was restricting our ability to do so - easily.  Not that it wasn't possible, but I come back to that evaluation I spoke of earlier - cost-to-return.  Staying with EJB's and also moving out to more than WAS wasn't proving to be practical.  POJO's looked much better, both for WAS and others.  So there is one of our reasons.

Another, as I have alluded to, was complexity.  We have grown to like Spring, and POJO's are a natural extension of that growth.  So, after we determined that we could reduce code and code complexity, continue our use of Spring, all while gaining more application servers and keeping WAS, well...  It was an easy decision.

So, we now code (almost) for no platform, but run with WAS and with JBoss 5.  We have also run with others, but they are not official.

I found it interesting that performance got better in most areas, but not in all areas.  There are reasonable explanations for most of what we see, both for better or worse performance.  And there are some head-scratchers, again for both better and worse performance.  If you take an overall look at the new Eloquence release, it is faster because of the architectural changes we have made.  And overall, WAS deals with the new architecture well.

I cannot say the same for JBoss 5.  My personal opinion is that the IBM folk have spent more time making their product work with Spring and POJO's and all of the stuff that surrounds our new architecture than have the JBoss folk.  I do not know if this is due to the rivalry I have seen between Spring and JBoss, or the JBoss interest in EJB's, or just that WAS is more mature.  We have a few things going on in JBoss that make no sense.  They work - you get what you want - but the performance differences leave you wondering what is going on.

You need to remember that Eloquence is sold to run on the application server that the customer owns.  We do not recommend one, sell one or alter what we find in any way.  In fact, we try to make sure we can run with other applications that may be present.  We install and configure our application - only our application.  We do our best to understand WAS and JBoss 5 so we can recommend optimum tuning of the application server for Eloquence.  But these do not extend to anything but Eloquence.

End result, the architectural changes allow Eloquence to be almost neutral, running the same code on WAS and JBoss 5.  Giving the same functionality on WAS and JBoss 5.  It is up to the customer to decide which to use.

This probably seems boring, but for Eloquence it was a big step.  We changed quite a bit of code and were nervous about how it would turn out.  It turned out well.

Now, it is common for these types of discussions to do something radical - to make statements that shock and amaze.  I do not wish to go against this tradition, so I am going to add a few paragraphs below.  If you do not wish to participate, you can stop reading now.

Okay.

First - We had a lot of trouble with Work Managers.  In Spring, in WAS and in JBoss.  This has got to be some of the most nonsensical logic I have seen for awhile.  Since there seem to be only a few players in this game, I would ask that you all get together and figure out what you want and how you are going to do it.  And, please, make it better.  I know the whole topic of threads and load and queuing and concurrency create differences of opinion.  I am sure there are competing camps, surfaced around grand theories, and that warfare is common.  But I do not understand why we had to have unique configurations between WAS and JBoss 5.  I do not understand why Spring surfaced these differences to us.  I do not understand why the JBoss 5 work manager has been coded as it has.  Especially since the same player(s) were involved.  And for the record, I prefer the implementation we got with WAS.

Second - there is no such thing as a free JBoss 5 application server.  From what we have gone through, you really need to be on the "commercial" release.  Or to have paid money to one or more consultants.  The documentation possibilities increase dramatically when money has changed hands.

Rick

Hi.

It's been awhile since my last post.  For those of you who think of Blogs as diaries, this is probably inexcusable.  For me, it's a way to talk to an audience that I don't get to see.  If I don't have anything to say, I don't think there needs to be any conversation.

So, from the above statement you can rightly guess that I have something to say.

I want to tell you about the next release of Eloquence, coming out soon.  I will leave it to Cincom marketing to give you lots of information about new stuff.  This is a Blog about architecture, and that's what I am going to stay with.

We have made some changes since version 1 - some small, some not so small. I'm going to focus on the not-so-small.

First, we are using Hibernate for the persistence layer.  It made no sense to stay in the SQL-writing business.  It was quite limiting and very consuming.  We have found that Hibernate has resolved some areas of complex code - making them go away or at least get simpler.  It has also given us the ability to support many more RDBMS vendors.  As with all first-time adopters, 100% of our hopes were not met (it's amazing what you think you know versus what you really do know).  I had thought we had done all of the research and set our expectations correctly, but until you work with something - and do it wrong - you don't truly get it.  We are past that now, and I think we are more impressed after it is all over.

Second, we are using Spring - for many purposes - and keep coming up with ways to increase its use.  If I am sold on Hibernate, I am even more sold on Spring.

Tangent Alert!

For those who do not know me, I am not young, having now counted more than 3 decades in this career, let alone time in this body.  I have a natural engineering style.  It shows up in everything I do - programming, deck building, furniture making, cooking, …  Spring fits me very well.  If I had created it, it would look like it does.

Back again.

Our use of Spring has so far been limited to our services (mostly).  As you will remember, we follow an SOA model,  Most of what we do is present in the application server, behind a messaging layer.  This is where Spring predominantly sits and where its use has grown.  We started out looking for just a helper for the persistence mechanism - everything we read said Spring/Hibernate was better than just Hibernate.  That changed once we started using it, discovering the power that was there.  Inversion of control, for example.  Support for aspect-oriented programming.  And, of course, the O/R, JDBC and DAO support, where we began.  More is coming as we push into the use of Spring Integration.

Third, we made a decision to greatly change the way Eloquence is administered.  In version 1, between Author, Web, the Admin Console and numerous configuration files, you created/managed the items and environment needed.  It wasn't ideal and sometime confusing as to where to go to get to something.  A lot of that has been brought together into the Eloquence Admin Console - EAC for short.  What you will see has little in common with the old one.  We have implemented a new UI, modeled more like Author to help with consistency.  EAC also uses Web 2.0 technology - JSF and AJAX.  This last change was the most dramatic, and points to future direction for Eloquence.  And, as you probably guessed, it uses Spring (but not Spring Web or MVC).

Finally - and here I have to cross into function for a bit - Eloquence has new modules to support Batch and  Output processing.  While I mention these last, they were the reason for most of our architectural changes.  They are also going to continue to drive most of the coming changes, as well.  The services used to be centered around the Engine - the piece that performs the actual document generation process.  Let's face it - all of the really cool stuff in the world doesn't matter if you don't produce a piece of paper - or Email, Fax …

Engine is still there and still represents why we exist.  We even gave it new abilities, which are used by Output to gain finer control over the document generation process.  Such as the ability to merge, sort and group documents; enhance individual documents or document streams with images, barcodes and PDF insertions; and deliver to more types of devices.  And if Output can do it, Batch can make it happen over large data sets, manually or on a schedule.

When you see Eloquence 2, I hope you will impressed.  We have tried very hard to keep what was good about version 1, while continuing its evolution.

Rick

Hi.

I have lately been in France, China and India.  I am saying this to impress you, of course.  Not impressed, huh?  This was my attempt at trying to be like some other Bog's, where the sole purpose is to show how cool the writer is.  I thought I would give it a try, but it's just not me.  Oh, well.

The purpose of all this traveling was Eloquence - not my personal eloquence, which is progressively hopeless, but the product Eloquence.  We are continually looking at ways to make it better, and that involves me leaving home, it seems.  In France, I spent time with the Cincom developers located in Lyon.  They are the primary developers for almost all of the new output processing going into version 2.  We have put a layer above our Engine that controls document generation, output generation and final delivery.  It will be universally used by the Eloquence application components.  So no matter how you come into Eloquence - Web, Batch or though an external application - all generation and delivery will be consistently processed.

The architecture of Eloquence Output is new.  It has been in my head and then on paper for 2 years.  In it, Engine still performs the initial creation of the document based on rules, document text and dynamic input.  But to this we have added across-document enhancements (such as insertions and barcodes) and the ability to sort, group and bundle documents across operations.  The aspects of Output are fully surfaced though the Admin Console, both for definition and run-time.

Speaking of the Admin Console, in China I met with the folks doing our new Admin Console.  Yes, I know we had one already, but I didn't like it, for so many reasons - usability, look-and-feel, and consistency among them.  And yes, the current one works fine, but I knew we could do better.  We ditched what we had and thought about a cleaner design.  The interface is much richer and employs many of the improvements gained in Web 2.0 - Java Server Faces and AJAX, for example.  The objects are managed both individually and as larger, composite objects.  All of the changes give a simpler, more intuitive feel.  It can be amazing the benefits you gain from a new approach.

One of the biggest changes was the use of the Spring framework.  To all the folks who have and will work on Spring - thanks.  It has made our jobs a lot easier and our product better.  The Cincom teams in the U.K. and India have done the work getting Spring into Eloquence.  I wanted to finagle a trip to Maidenhead, but that didn't happen.  Probably for the best, as they have been quite productive without me bothering them.

My final trip took me to India, home of another group of our Cincom developers.  These guys and ladies have been doing so much for us over the years, working on all parts of the application.  My focus on this trip, however, was our test team, helping them to understand what's coming at them and how to best handle it.  The architectural changes have given us better isolation, making it easier to test individual units.  It going to make their jobs easier, which means more and better testing, which translates to a better product.  Cool.

These are big changes, all relating to improvements we are making in the Eloquence architecture.  And since this is focused on architecture, I thought it was important to say something about them.  Sorry if it came off too much like marketing.

In the inaugural message, I would like to talk about what a document generation application should be.  But first - I'm Rick.  I am the architect for Cincom CDS, responsible mostly for the Eloquence application.  I hope to talk to anyone who cares to listen as often as possible.

So, what about a document generation application?  For me, first there are the simple things - create the document I expect, as quickly as possible, on/to the devices I have.  If you can't do that, you're not in the game.  But this describes an incredible number of applications, including almost all word processors and reporting tools.  Do I consider these to be document generation applications?  Short answer - yes.  Long answer - not really.  You have to say 'yes', since by shear volume they probably do more document generation in these applications than in any other.  Just as the typewriter once did far more than these did.  And as a pen and paper did before the typewriter.

Pen and paper still exist - typewriters still exist - and word processors and reporting tools will exist for quite some time.  But there are also document generation applications, such as Eloquence.  Which is why I have the long answer of 'no' above as well.  There are two characteristics that can be used to start separating word processing and reporting tools from document generation.  They are the ability to deal with complexity, and the ability to hide that same complexity.  Complexity can come in the number of pages, page content and format, input data types, output data streams and device targets.  Any of these can make the task of document generation quite difficult to manage on a day-to-day, week-to-week basis.  So that difficulty must be met by making the process as simple as possible.

If we focus on complexity, then nothing will ever be 'simple to use', but it can be 'simpler to use'.  Hiding complexity is both a noble goal and mandatory to keep this work bearable.  But if it is always hidden - if the complexity cannot be met head-on when desired - then you cannot truly manage it.  I agree that most of what needs to be done can be - needs to be made bearable, possibly 'easy'.  But if the application doesn't allow you to 'get into the ink' when you need to, then it isn't truly serving you.

For me, there is no question that even the best programmers cannot predict and code all the ways a document generation application will need to be used or what it will need to produce.  So they must give you a way to accomplish what you need.  The trick is to do so in a way that makes sense - back to the 'simpler to use' idea.  And so it is that how you deal with the application becomes the defining mark of the application.

I believe that the perfect document generation application is part programming tool, part application.  The application part holds your hand, does most, if not all of the work, and gives you what you want for 80% of your work.  The programming part gives you a rich set of tools to use for the rest of the time when you need it.

That tool set should be broad in coverage and needs both low- and high-level parts.  In fact, it should the same tool set used by the application.  Some of you won't want it, and that's fine.  The application will provide what you need.  But some of you will need it and will appreciate that it is there.

The quality and scope of both the tool set and the application will define the top competitors in document generation.  At Cincom, we will strive to be the best.