Some thought about Progress's role transition

[wsong]

Recently, after spending some time looking at progress's new product releases, I noticed that there is some important and unique changes which implies Progress may try to make a major transition in this roles in business software industry

I would term it a transition towards to business logic product vendor in contrast to the Database product vendor.

10 years ago, I started using progress becuase the my company are using Mfg/pro which sits on Progress. 3 years ago, I managed to become a SAP consutant. Recently, I resumed Mfg/Pro / Progress career, quite rare for an ERP consultant, many friends said I am crazy.

I found the major sucess of SAP lies with its ABAP ( or more accurately SAP basis). It is a business logic development layer independent of any Databases ( it talks to all DB basically through SQL) . It also enables a three tier structure. SAP basis is a scalable robust business logic layer sits between the presentation and DB. However it is not open platform, it is privately owned by SAP.

VB, Java, C++, C#, Delphi is good , but not for developing maintainable business logic. Navisions guys also abratract the C++ to something like java call X++ to develop the Axapta. The benefits of object language is wrongly targeted to solve the business logics. You have layers of clumsy classes to do a piece of simple logic.

Now for business software developer, you either use PL-
SQL at the background for Oracle, or stored procedure for SQL-Server to develop your business solutions. and use VB or Java + sql for front-end ( where is scalablity and cross platform ability? and where is efficiency of business logic development) you know how tedious that can be.

So I guess that is why in recent 10 years we did n't see some great business application appears. I personally think, within the recenly 10 years, while most of effort are placed on interface / archetecture, the industry overlooked business logic which is crux of the business software. That is why we see a lot of products with fancy screens but can not solve your business problems when you spent your money on it.

Come back to Progress, if we only look at the progress ( sonic is another topic), in the market place, I don't see presense of it DB ( although I think its performance is among the best). But as progress develpers, we know progress 4GL (ABL) is very productive, you don't find a comparable language in business logic development ( Please don't mention Java, PL/SQL ). I think a natural direction for Progress will be develop a independent progress 4GL and app server product, like SAP basis which can connect to any DB which support SQL protocal.

4GL language + Application Server + Oracle DB + .net/Java front-end.

Do you know any better archetacture for a business software devleopper.

SAP once was trying to tell all that you need not care what DB your application is running on, you only needs to know it is running on SAP. However as SAP itself is a application development vendor, other application development vendor will only see SAP as an signal of danger rather than business partner.

Progress as an independent infrastructre provider, if it adopts such market direction, It can realise what SAP once dreamed - all business software runs on progress.

To archieve that, progress may consider to seperate its ABL Application server business from its database business.

in 10.1B Progress dataserve now supports all the major DBs, I am not sure if its dataserver + application server + 4 GL can run independently. If it does, I will bet on its future.

Any input or comment is welcome

Willy Song

Shanghai















Now the

 

[TomBascom]

I think that you are now seeing Progress as they have always seen themselves.

They have never been in the standalone database business. The database is there because a 4GL without an integrated database made no sense to the founders. Progress (or Data Language Corporation as they used to be known) has always been about providing the best tools for developing business applications.

(And for a long time they claimed that SAP was their competition. I haven't heard that lately but it fits quite nicely with your observations.)

 

[Jupiter]

Sitting in India I cannot see any important marketing activity on behalf progress to send message to companies which are migrating from Progress to SAP should rethink and new companies thinking about implementing SAP should go for Progress.

Progress, with all its wonderful features can do no good to the business if it falls short of marketing itself properly.

Comments are welcome.

 

[TomBascom]

Sitting in India I cannot see any important marketing activity...

Trust me. Being in India has nothing to do with it

Progress is the World's leading proponent of a marketing strategy known as "Stealth Marketing". It's a sophisticated variation on the better known "Build It And They Will Come" philosophy.

They target this marketing energy at application partners -- not end users. So "Progress who?" is the usual end user reaction upon hearing that a product is based on Progress.

 

[joey.jeremiah]

There were the Volvo and Selexyz highly public projects based on OpenEdge this year.

Although, they're solutions developed by Progress partners they, probably, had some Progress involvement.


They were in the infoworld.com 2006 innovation awards and they weren't the only Progress and the other Progress companies awards and articles this year.

In 2005, 3 out of 12 innovator awards went to technologiest from the various Progress companies.

It's no comparison to one of the biggest software companies in the world but it's an interesting trend

 

[wsong]

The following feature will be helpful to application developer

If progress adds the following mechanism into the openedge1. Application lock manager As the detached prodataset will become the trend in progress app server development, optimitstic lock is widely used, the traditional DB level locking mechansim will only work during the update. In developing application with complex data interinks with long-duration user interface interaction, the pure optimistic lock sometimes is not good enough. e.g. if you are maintaining a a sales order line, it may impact the sales order file, a MRP file, shipper, etc, at the same time another guy is maintaining the same order, or another guy is creating shipper line for the order, after you modify everything and click save button, system tells you "Another guys modified the order, please do it again" what is your feeling.If progress can have a application lock service, which will keep the locked records and key fields ( not all fields should have a lock, the "last one overwrites all" works normally for most fields) information as a central service. thEn we can do some isolations whenever inevitable in application development. Life for the progress developer will be much easier. So we only need to sumit the table and fields to be locked to the service, and release it after we complete in the program. When the other guy access the table / fields, system will prompt " user XXX is using the data ".I am not sure if other people have the same concern in their code development2. Background processing engineWe need to have some service which can process the app server programs in the background mode at pre-specified time and date. At the moment, I don't see how progress are solving it for the application server. If progress want to have to more application developped on its platform, more tools and infrastructures should be available to increase development productivities.

 

[joey.jeremiah]

... sounds like pessimistic locking, and there could be cases where you'd want that behavior or it would be inevitable.

i don't think, that such a manager for a stateless appserver would be especially hard to write, and it would be reasonable to design the architecture to support it.


the database could have a lock table that would identify records through object id's, maybe even rowids could be used in this case etc.

and the data access objects would use a set of transaction procedures that would also check if the record is locked.

again, only incase that behavior is desired.

 

[wsong]

Hi Joey

Thanks for the clarafication. it is only necessary in the high propablity of collision.

I am thinking whether it is possible to keep the locking objects in in memory?

What is your opinion?

Best Regards

Willy Song

... sounds like pessimistic locking, and there could be cases where you'd want that behavior or it would be inevitable.

i don't think, that such a manager for a stateless appserver would be especially hard to write, and it would be reasonable to design the architecture to support it.


the database could have a lock table that would identify records through object id's, maybe even rowids could be used in this case etc.

and the data access objects would use a set of transaction procedures that would also check if the record is locked.

again, only incase that behavior is desired.

 

[joey.jeremiah]

Hi Willy,

You're right, I think, my previous suggestion is unnecessary.

I think, a better, simpler way is to bind an AppServer agent to the client, for the duration of the operation and use automatic transactions that allow for transactions to span multiple client requests. Though, you'll be locking an agent and not just records but, I think, overall it's a cleaner, better solution.

For reference and examples have a look at Managing Transactions chapter in the Developing AppServer Applications doc.

Again, only incases where this functionality is necessary, in most cases you'd want to keep transaction as short as possible.