Migrating to AppServer question

Posted by Tung on 29-Jun-2010 04:26

We're migrating our application from ADM1 to .NET and also to (stateless) AppServer. The plan (or dream!) is to convert our login and main programs to .NET and be able to run our existing ADM1 programs, which use database fields so the business logic is very integrated with the UI. Then we can convert the other ADM1 programs to .NET one at a time and the new main program will run the .NET version if it exists. This way we can offer something new to our clients straightaway instead of converting the whole application to .NET which would take over a year.

Currently our main program runs programs with "RUN pgm1.w PERSISTENT SET hProc". If a client has Appserver (and not all of them will), I can do "RUN pgm1.w PERSISTENT SET hProc ON hAppServer". But if pgm1.w runs other programs that update the database, would they also run on Appserver?

I'm not sure our plan can work with Appserver. Is it possible?

All Replies

Posted by Admin on 29-Jun-2010 04:39

We're migrating our application from ADM1 to .NET and also to (stateless) AppServer. The plan (or dream!) is to convert our login and main programs to .NET and be able to run our existing ADM1 programs, which use database fields so the business logic is very integrated with the UI. Then we can convert the other ADM1 programs to .NET one at a time and the new main program will run the .NET version if it exists. This way we can offer something new to our clients straightaway instead of converting the whole application to .NET which would take over a year.Currently our main program runs programs with "RUN pgm1.w PERSISTENT SET hProc". If a client has Appserver (and not all of them will), I can do "RUN pgm1.w PERSISTENT SET hProc ON hAppServer". But if pgm1.w runs other programs that update the database, would they also run on Appserver?I'm not sure our plan can work with Appserver. Is it possible?

Migrating to .NET does that mean GUI for .NET (10.2A or 10.2B) or .NET Proxy and pure .NET client development?

Your pgm1.w is that a SmartWindow? In that case it's not possible to run that on an AppServer because it contains UI widgets (window, frame, buttons, fill-in).

Also in your first line you are mentioning stateless AppServer.

RUN pgm1.w PERSISTENT SET hProc ON hAppServer .

is no good with stateless AppServer. Running anything persistently on the AppServer causes the client to bind the AppServer agent, making it in fact a stateaware appserver. A bad choice.

I believe you should separate two tasks:

1.) turning the login and main menu into .NET Forms and running the ADM1 SmartWindows from there. We have a lot of experience with that setup and our WinKit tool (Window Integration Toolkit). It works with and without ADM1 or ADM2. But the fact that the ADM1 is build on a method framework makes many things really easy. Let me know when you want to know more.

2.) moving the ADM1 app to AppServer. That’s a much bigger challenge. The ADM1 has been built way before the AppServer was invented. That does not mean it is not possible to use it with an AppServer, but there is no big support either. The ADM1 can run against temp-tables but you'll have to define them in a data-base called temp-db and define the SmartQuery or SmartBrowser objects against temp-tables that are defined like a temp-db table. Then you need to provide code that reads data in temp-tables from the appserver (non persistently) and updates data in a similar way.

Posted by Tung on 29-Jun-2010 05:33

Migrating to .NET does that mean GUI for .NET (10.2A or 10.2B) or .NET Proxy and pure .NET client development?

It's GUI for .NET (10.2B).

Your pgm1.w is that a SmartWindow? In that case it's not possible to run that on an AppServer because it contains UI widgets (window, frame, buttons, fill-in). 

Our main program 1.w isn't Smart but most of the programs it runs are SmartWindows, etc.

RUN pgm1.w PERSISTENT SET hProc ON hAppServer  .

is no good with stateless AppServer. Running anything persistently on the AppServer causes the client to bind the AppServer agent, making it in fact a stateaware appserver. A bad choice.

Yeah, I did see another post that mentioned this, which prompted my question.

I believe you should separate two tasks:

1.) turning the login and main menu into .NET Forms and running the ADM1 SmartWindows from there. We have a lot of experience with that setup and our WinKit tool (Window Integration Toolkit). It works with and without ADM1 or ADM2. But the fact that the ADM1 is build on a method framework makes many things really easy. Let me know when you want to know more.

2.) moving the ADM1 app to AppServer. That’s a much bigger challenge. The ADM1 has been built way before the AppServer was invented. That does not mean it is not possible to use it with an AppServer, but there is no big support either. The ADM1 can run against temp-tables but you'll have to define them in a data-base called temp-db and define the SmartQuery or SmartBrowser objects against temp-tables that are defined like a temp-db table. Then you need to provide code that reads data in temp-tables from the appserver (non persistently) and updates data in a similar way.

I think we want to do only the first task. We may require clients to be connected to databases if they want to run our ADM1 programs whereas our .NET programs will be able to run with or without Appserver. The downside is they can't move completely to Appserver until we've converted all the ADM1 programs. Would WinKit give us a .NET version of our application that can run over Appserver?

Posted by Admin on 29-Jun-2010 15:29

Would WinKit give us a .NET version of our application that can run over Appserver?

No, WinKit does not change the architecture of the application at all - this is how we can achieve very good results in short time. It's (just) specialized on improving the appearance of existing OpenEdge applications using the GUI for .NET. The core are embedded windows (taken to the extremes) and utilities to go further. Think of replacing toolbars or panels with Ribbons etc., replacing browsers with UltraGrids, ABL TabFolders with Dockable Panes or UltraTabFolders and a new look be fresh colors and fonts. It's a set of utilities and templates for that purpose. No magic, but proven to work.

You may be interested (if you can wait so long) in my Exchange Online talk on GUI for .NET adoption strategies.

An architectural change may come later. Either based on the existing application or new development of some/first screens integrated with the existing application. But that's a different story.

Posted by Thomas Mercer-Hursh on 29-Jun-2010 16:45

Part of this will depend on what's important to you.  If the main thing is lipstick, ie., putting on a new face, then proceed as Mike is directing you and get that job done and figure out the architectural shift separately.  But, if the architectural shift is ultimately more important, then I would concentrate on what you want to do there first because what you decide may dramatically alter what you do on the cosmetics.  The most extreme example being that if you decide in favor of moving to an N-tier architecture, then you are going to be changing the code radically enough that some new options might open up, including .NET OpenClient and RIA client.

Posted by Admin on 29-Jun-2010 17:04

Well time to market is also relevant.

I've experience more than once that a big bang approach is not an option. If putting the lipstick on the pig takes just a few weeks it might open new sales or at least keeping the existing but unsatisfied users or customers from looking for alternatives, and making the actual architectural change more likely to happen. Telling them that we are working on something that will be released in X years is often not a satisfying option when you are not able to release in the meantime. I've also heard more that once that customers of VARs hate the big bang: it involves risk. Many customers helped to stabilize a solution and want to keep it stable, not going through all the new testing and training involved in a new application. They may be happy with just a bit better, offering more productivity here and there. One of my clients has experienced his customers say: when there is a too big change we might as well look for a competitors app.

The big change may and often should and will come later. What architecture and UI technology used may vary on many factors. I absolutely agree.

Von meinem iPad gesendet

Posted by Tung on 30-Jun-2010 03:45

My bosses want to refresh the look of our application as it's looking slightly dated but just as importantly they want to separate the business logic and user interface and develop different UI for the web, PDAs, etc. Their plan is a gradual change, starting with the login and main windows then converting other programs to .NET one by one. And I clarified the situation with my manager: we're not aiming to run our ADM1 application on Appserver, only the new .NET version.

But WinKit may help us to get new clients who are put off by current look of our app. I've told my bosses about WinKit and I'll leave it to them to decide if it's something they want to use.

Thanks for your replies.

Posted by Thomas Mercer-Hursh on 30-Jun-2010 12:12

There are, of course, ways to make a major transition less expensive and more efficient than just sitting a bunch of coders down in a room.

And, one should recognize that a stepwise transformation is not likely to ever get you to the nice clean new architecture that you would get from fresh implementation.

Putting a fresh face on the application in a stepwise fashion is certainly a doable thing with ABL GUI for .NET ... that is one of the genius things about it.  Making the move from ADM1 to AppServer is going to be a rather less straightforward transition and one that is going to be awkward because you will have a mix of programs operating on the client which are functioning in very different ways with very different expectations of how data is handled.  Transitioning that one program at a time is going to be a lot more difficult than the visual transition.

So, fine, jump in and put on a little lipstick right away.  That will get you some boost in appearance without disrupting much and it will introduce you to a lot of new concepts.  Once you have the basics working, it will be straightforward to keep prettying things up one bit at a time.  But, I would recommend that once you get that far, sit back and take a good hard look before diving into the AppServer part.  Consider carefully what your target architecture is going to be, what toolsets there are to support that architecture, and what tools there might be to either assist you in building the new programs or transitioning old code.  There is likely to be *at least* a 4X difference in cost and effort between best practice and just diving in here.

Posted by Tung on 01-Jul-2010 06:24

We are going for a fresh implementation, creating GUI for .NET form versions of our ADM1 Smartwindows, moving away from DB field widgets, separating the business logic into procedure files and putting in place an Appserver framework. The intention is a new .NET version of the login and main screen which will run our current ADM1 app. Then if a program's been converted to .NET, the main screen runs that instead of the ADM1 version. The databases haven't changed, just the UI, so I don't see the "mix of programs" being a problem. Or have I missed something?

The problem for us coders is it's a huge change making the transition to OO, using Architect, working with unfamiliar controls, properties, methods, etc. so we're definitely still at the 'diving in' stage. Compared to moving from CHUI to GUI, I found that easy! We didn't do any courses with Progress, just read their documentation and watched their videos. I think the hardest part is not knowing what's best practice.

Posted by Peter Judge on 01-Jul-2010 07:24

I think the hardest part is not knowing what's best practice.

There's plenty of opinion (with the occasional fact sprinkled in for good measure) available on these forums. There are also a number of more specific sub-communities (Gui for .NET, OO Practices, SaaS and cloud etc). Feel free to ask.

-- peter

Posted by Thomas Mercer-Hursh on 01-Jul-2010 11:12

Agreed that defining best practice is a challenge, especially since there is far from universal agreement in the ABL world.  You will find arguments/discussions here, some material on OE Hive, and an on-going series of whitepapers here http://www.cintegrity.com/content/OOABL .  You might want to consider a mentor ... maybe even more than one in order to get broader coverage and a variety of views.

My point about the confusing mix is that you are going to have a long period of running two very different architectures in the same session.  Among other things, one part of that session will require a database connection and another part won't be expecting one.  Switching back and forth will require some mental nimbleness and care, not to mention good discipline.

The main thing I would emphasize, though, is to be very clear about the difference between the lipstick and the architectural shift.  Once you get past the startup, putting a new face on any given function should become fairly routine.  Oh, sure, you will periodically have some new skill or trick to add to your repetoire, but I would expect that simpy prettying up an existing function and leaving it in the current architecture to be fairly straightforward.  The architectural shift, however, is a much bigger step, both in figuring out the target architecture up front and in the amount of work you will have to do to move any given function.  You will find that there are a lot of dependencies, i.e., things which you need to do first before you can do the thing you started to do.  In particular, you are going to want to think carefully about the construction of your AppServer serivces since presumably one service will provide data for multiple client programs, each of which is now getting its own data.  In fact, you might want to consider doing something like building one or more AppServer routines for Customer data and then converting all the functions which are now getting Customer data directly to use the new routine(s).  I.e., separating the data layer first since that is fairly easy.

The UI/BL separation is harder and involves some more difficult decisions.  In particular, are you going to stick with fat client and keep the BL in the client or are you going to move in the direction of a lighterweight client and push the BL to the server?  And, how religious are you going to be about the separation?  It is easy to be a bit lax in a fat client environment, but, of course, then you aren't going to achieve the same flexability in terms of future UI changes.  This is something you want to get clear up front and a good place to get some help in making sure you have a good plan.  You also might want to consider some tool support for helping to make some parts of the transition.  E.g., see http://www.cintegrity.com/content/Request-Expression-Interest .

My other recommendation is to consider your analysis tools.  It is a lot easier to make predictable changes to your code if you know what the current code actually does, where all the places that deal with certain data, what all the routines are that use a particular piece of code, etc.  Take a look at http://www.oehive.org/ABL2UML and http://www.joanju.com/analyst/index.php for example.

Posted by Mike Ormerod on 01-Jul-2010 11:43

Certainly if you start to also consider the architecture i'd reccomend looking at the following :

Architecture Made Simple Part 1

Architecture Made Simple Part 2

They walk you through the process of starting with 'legacy' code and how to migrate to a more OERA like structure in simple steps, while introducing some of the new concepts & techniques along the way, including datasets, and some simple OO.

HTH

Mike

Posted by Admin on 01-Jul-2010 15:08

tamhas schrieb:

My point about the confusing mix is that you are going to have a long period of running two very different architectures in the same session.  Among other things, one part of that session will require a database connection and another part won't be expecting one.  Switching back and forth will require some mental nimbleness and care, not to mention good discipline.

Ok, you are accepting that the modernization will take a long time. Not running the old and new architecture in the same session means you are definitively maintaining two applications. I can hardly imagine how users (in fact I never met such users) would accept to work with two different applications at the same time. So until the new development is completed and tested we are talking about maintaining two applications with very differnt structure. Whenever a new feature or a change in business rules is requierd this needs to be implemented twice - because the chance to reuse the implementation (maybe based on SCM tools that can merge source code) is almost not existing. So it's probablay more effective to change module by module and roll out modernized modules as fast as possible to reduce the need for double maintenance. And very few development managers I've talked to where a friend of double development effords.

As a matter of fact I've seen applications where V6 style code had been GUInized was running with ADM1 code in the same session. Right now it's being thought about replacing part of the V6 style code with a modern architecture. Any other approach than running it in the same session (V6 GUInized, ADM1 and new code) is out of question.

Besides business domain specific functionality most applications have functionality like security, menu management, customization where it's highly demanded to keep the same structure. In a world where everybody is talking about single sign on, how would you sell an application that's actually two applications with different user and rights management?

So I believe that when starting a transition it's good to look at the structure of the current application first, look at good and bad functionality. Then make the good existing (framework) functionality available to new code. Very often I've experienced that it's not that hard to make it even AppServer aware. Even when old sins like (GLOBAL) SHARED VARIABLEs are used. It's a simple task to make this functionality accessible to new (OO) code. It's just a matter of creating a different interface of a facade to good functionality (I believe that there is a huge amoung of good quality and still maintainable procedural code out there). In fact our GUI for .NET development utility (the SmartComponent Library) has been designed to flexible plug into existing frameworks for functionality like session handling, security, appserver location etc.. That is proven to make the integration into existing customer frameworks or even ADMx or Dynamics a simple task. We have designed Interfaces and provide sample implementation of these framework services. With our customers we replace the sample implementations with customer specific implementations.

And for the developers discipline: My experience is that by switiching the tool and the UI (AppBuilder for existing code with ABL GUI, OpenEdge Architect for new code and potentially GUI for .NET or a RIA UI) most developers hardly get confused about if they should use the old or new coding standards. The natural differences between procedural and OO coding does kill the remaining doubt.

So when the strategic direction about using a Progress client for the UI is made, what's your actual problem with running old and new in the same session for as long as there is still "old"? It shouldn't be a religious decision - it's a business and strategy choice. And business wise I see a many reasons why it makes sense - IF the Progress client is the deployment choice for new (for at least as long as the overall migration takes).

Posted by Thomas Mercer-Hursh on 01-Jul-2010 16:26

Someplace in here that has been a failure to communicate.  The post you are responding to assumes transformation in place.  It assumes same session.

I don't agree that transformation in place is the only option.  Quite a few partners so far have already done major rewrites in which they largely freeze an old version and create a new version alongside.  Because the old version is largely frozen, only a small number of changes have to be done to both.  At least one partner I know of also introduced modules of the new version module at a time.  Since most users use one module, there was not a lot of confusion and it allowed them to get new code to selected customers sooner, thus also providing a kind of secondary beta.  Others have roled out the new version to new customers and only gradually converted the existing customers.  There are many possible strategies here.

Is developing a freshly architected version all in one big push expenseive?  Well, sure, although I think there are starting to be tools and techniques to lower that cost substantially.  It certainly isn't going to be as expensive as converting the entire application to Java or .NET and yet I know half a dozen companies who are doing that ... and that is obviously an all at once shift.

Is it going to take a long time?  Well, that depends on what you consider a long time and what kind of tools and resources you use.  One can certainly lay a lot of foundation work down in parallel with existing development before a freeze is needed to simplify things.  There is a lot of foundation work and planning and development of techniques.  After one starts producing non-foundation code, the time it takes depends, as I say, on tools and resources.  It doesn't need to take years and generally, if the degree of moderization that one is going to do is significant, as it is here, then it is highly likely that could be completed faster using full separate modernization than one could complete in place modernization ... quite possibly twice as fast or more.

Here, based on admittedly limited data, I don't see the compelling urge to do it all at once.  Perhaps the competitive pressure isn't that significant yet.  Perhaps the expected expense is to high.  Perhaps it is just seen as too risky.  Whether that conclusion would still stand under a more thorough analysis is unknown, but for the present I am assuming that the OP is only really interested in a transform in place strategy.  That will take longer than doing it all at once, but it will also take fewer peak resources.  The result isn't likely to be as fully modernized, but that isn't important to a lot of people, maybe even most people.

By confusion, I am talking about the complexities of working on code that enbodies two different design approaches, one old and one new.  E.g., one has an old function which calls half a dozen .ps in the process of doing what it does.  Two of these are shared with some other function.  Then one goes to modernize one of these and one needs to understand that the overlap exists and the nature of the overlap.  Then one needs to come up with a strategy.  E.g., suppose the .ps use shared variables and the new strategy is going to use objects.  Are you going to retrofit the other function to use the objects or what?  It is a choice one needs to make and one that one needs good analysis tools to understand.

Tools can make a huge difference in cost, effort and quality.  They can change the whole way that one approaches the problem.  Even tools which only do one small part ot the process can make the code easier to work with.

There are some things that one can do without a grand plan.  Dressing up a few screens to create a good first impression is one of those.  So is anything which improves code quality and packaging like getting rid of shared variables.  But, if one is going to do a serious modernization of the architecture, that is something where I am advocating having a clear view of the goals and architecture up front.  E.g., if one decides to stick with fat client, then the only thing on the server is data access.  That is actually fairly easy to factor out and, with reasonable analysis tools one can identify superset requirements up front and design the right DA routines up front and then just substitute calls in the existing code as a first step.  If one wants to move to thin client with most or all of the BL code on the server, then its going to be harder, particularly having it interoperate with existing code.  But, it can be done ... it just needs a good clear plan.

Posted by Tung on 02-Jul-2010 09:50

I'm not familiar with the terms but from what I can understand, we are doing a transformation in place and the same session. And we want a thin client so the UI is independent of the BL and DA.

From the user's point of view, they see the same modules but with a new look UI using new controls, eg. a freight job screen, a container code maintenance screen. So new and existing customers can see we're updating the application but don't have to wait however long it'll take to do it "all at once".

But I agree we need good analysis tools and grand plan to ensure our architecture is designed and works well. That's why I'm trying to get someone from Progress to advise us, so we don't have to fix things later on

Posted by Thomas Mercer-Hursh on 02-Jul-2010 12:09

For an overview of transformation strategies, check out http://www.cintegrity.com/content/Transformation-and-Modernization-Strategies

When you say "thin client", how thin?  Thinest is zero footprint, i.e., browser with RIA technologies.  But, that would be almost impossible to blend with your existing software because there is no AVM on the client.  Next thinest would be to have only the UI on the client.  That is possible, but is certainly going to take some careful staging in the mix with your existing code.  In particular, pretty much everything that happens from any given menu selection will have to be one technology or the other since, for example, a new technology BL component on the server can't call a BL component of old technology on the client.    Having both UI and BL on the client, but well separated would be easier, but wouldn't be very thin, since only the DL would be on the server.

It sounds like what you will want is to first create a container which provides your menu system and other general front end components, then embed your existing application within that and possibly take a few important functions and stick an ABL GUI for .NET front on them without yet doing much about the underlying architecture.  I would suggest Mike is the go to guy to help you make that happen.  This first phase won't modernize your architecture at all, but it will provide you with a bit of sizzle and will familiarize you with some of the OO constructs and such.  I'll bet that once they see it, the sales types will push you to do more screens in ABL GUI for .NET than you originally planned.  Depending on the size of your team, you might dedicate one person or a part of a person to keep moving forward with that kind of lipstick modernization since it will continue to provide visible evidence of progress and, in the end, if you are going to have an AVM in the client, you will want those ABL GUI for .NET screens anyway, even if you later change the architecture behind them completely.

Once you have that rolling, you can work out the architecture for the modernization and launch an independent effort to separate functions into layers.  Again, depending on the size of your team, you might want to have some sub teams working on their own areas.  For example, as I mentioned earlier, it would be smart when you get to needing a Customer data source component to use your analysis tools to figure out all of the different ways that you need customer data through out the application and then build one or more data source objects to fulfill all of those needs up front.  Myself, I would be inclined to then go through all of the places in the application where customer data is used and clip in the new access, although I confess it has been a long, long time since I looked at ADM, so I don't know how straightforward that would be.  That isn't a complete modernization by any means, but it will simplify the later modernization by separating out the data layer ... perhaps not in the exact way you will want it in the end, but at least separate.  In fact, it would be one reasonable strategy to have one team focused exclusively on doing just that since it would get you to a point where the client no longer needed a database connection at an earlier date.  That would allow you to consider WebClient for deployment, which would simplify your client install issues.

Then, of course, comes the real modernization.  This is clearly going to be the toughest part of the job and the one with the least clear blueprint.  Suffice it to say that there is quite a diversity of opinion in the ABL world about the "right" way to do things .... and, ultimately, you are going to have to decide which direction to go.

I don't know what part of the world you are in ... which is significant since, curiously, the EMEA PPS (Progress Professional Services) has ideas which are materially different than the NA PPS and they use different technology in their transformation projects.  I will suggest a bit of caution.  There is no question that PPS has done more transformations than anybody so they have a lot of experience and tools.  But, they also have some very specific ideas about how to do a transformation and that may or may not mesh with your plans.  Don't be surprised to find out that all they want to talk about is their approach, which is much more of a "big bang" process than the transformation in place approach you have in mind.  Of course, it could be that they will convince you that this is the better way to go, but if not, they might not be the best partner.  Plus, you should recognize that, just because they come from Progress ... branded, as it were ... doesn't necessarily make them the best architects in the Progress world.  The NA PPS is certainly doing some very interesting things with a code to model to code approach which is very much what I think is ultimately the best strategy for full modernization, although you may have noticed trolling around these forums that I don't always agree about some of their design choices.  Even if you find that PPS is willing to work your way, I would seriously consider having in a couple of other people to at least talk to you.  You might even commission a couple different sources to provide you with an analysis similar to this http://www.cintegrity.com/sites/cintegrity.com/files/Transformation_NeedsAssessment.pdf so that you can judge who best fits your companies needs and ideas and who is willing to work the way you want to work.

And, I would pay a lot of attention to possible tools.  For all of the questionable aspects of ADM, one thing about it is that it is highly structured.  Anything that is highly structured is much more susceptible to tool facilitated transformation ... not that you can eliminate hand work, but that you can reduce the effort and thus the cost and time while often also improving quality.

This thread is closed