New Data Access Layer Sample Application Materials

Hi Frank,

great job you and the other guys did, i just try to implement some of your ideas in an new project.

At this time i am not very familiar with the code, just organise and read for understanding ideas and code.

In your autoedge excample i miss 2 files, not sure how important but code isn´t working without:

and .

Can you take a look at this ?

Greetings from Germany

Werner

Hi Werner,

I'll look into this but let me explain something about the source code first. The idea of the samle code is to show relevant pieces of code from a sample application in addition to the document(s) on a specific topic. The code itself may or may not compile. It was not the intention to provide 'ready-to-compile/run' source code but to provide sample implementations of the topic at hand. I'll see if I can provide a quick fix for this issue.

Regards,

Frank Beusenberg

The code itself may or may not compile.

Then how is the target audience supposed to trust that the example's valid? Examples of various architectures & concepts don't need to be complex, but they should be runnable so a developer can execute it, see how things work, and how it can be used in their work.

Cast my vote with Tim ... any set of sample code should, at a minimum, come with a test harnass that illustrates the operation of the code and which validates that operation.

Ideally, multiple PSDN code samples would interact with each other as well.

Hi,

I agree I have worded my reply a little unfortunate. What I meant to say was that the sample is runnable (we will provide a document to help you setup the sample environment), but the source file(s) available for each individual topic are there to illustrate and support the design discussed. We felt it was easier to only show the sources relevant to the topic at hand instead of putting out a fairly large amount of source files and then wade through them to get to the relevent ones. I will post the setup document asap so you can run the sample application. We are working on getting the complete sample application available on PSDN in an installable format for you to play around with.

Regards,

Frank Beusenberg

We are working on getting the complete sample application available on PSDN in an installable format for you to play around with.

Is it going to be ADM-centric? Since I live in ChUI land and've never used the ADM, navigating ADM managed code is a bit problematic for me.

We are working on getting the complete sample

application available on PSDN in an installable

format for you to play around with.

Is it going to be ADM-centric? Since I live in ChUI

land and've never used the ADM, navigating ADM

managed code is a bit problematic for me.

No, the sample application is mostly based on the "Implementing the OpenEdge Reference Architecture" papers (http://www.psdn.com/library/kbcategory.jspa?categoryID=289), so you will be able to go through the code without any knowledge of ADM or ADM2.

Having that said, if you don't want to just "run it" but also want to dig through the code, and maybe modify / reuse some of the it, the material that Frank has been posting over the last couple weeks will help greatly to understand how the sample application is build.

Hi again,

i started this discussion, now again i explain my point of view: if code examples are used to explain, this code should be complete, or, if code is referenced, an explantaition whats going on in the referenced part should be written instead.

This is not to get a running piece of code, it´s for understanding your thought why you implement this in this in this special way.

I agree, whitout reading and understanding all of your papers (and the first series from John Sadd too), its impossible or very hard to implement OERA whitout great mistakes and errors.

Hence i repeat, great job you did, but example code should work or explained what happens.

Werner

>.....

Hence i repeat, great job you did, but example code

should work or explained what happens.

Werner

Hi Werner

The whole aim of the work we're currently doing is to cover the exact points your making. As the guys have said, each sample is runable (you just need the set up info which we inadvertently missed from the doc which we will posts asap). At the same time, the supporting documents and designs are also intended to explain what we did and why.

So if we're not achieving that, or you have specific questions about the designs or the implementation then please let us know and we can answer you questions and refine the work if needed.

To us, in many ways this discussion is very encouraging, as one of our goals is to get everyone involved in discussing the work we put out, and indeed to tell us what you like, what you don't like and maybe why others would do it differently. There is no one right answer for everyone, as everyone has a potentially different starting point and environment when building their application. If you put 10 Architects in a room you'd end up with 10 different answers!!

So keep the comments coming, because it's only through these discussions that we can make sure the material we do is useful to you.

Thanks

Mike

Just to throw in another oar here, I think there are two structural problems with the current approach:

1. The context hasn't been clear. E.g., I had downloaded a couple of code samples previously and unzipped them into a single directory, but not looked at them right away, and then I got the MVC one. That got me to wondering how I would tell which code went with what and so I zapped everything and unzipped it into four separate directories. Now it turns out that I have to go back the other way in order to run it.

2. Given that one does have to put it all together, it is going to be difficult to tell what goes with what in order to look through what's new. I think this is made more difficult by the current directory structure. This directory structure isn't appropriate to a real world context in whch this kind of code would be used. Why not set it up like a real application?

Just to throw in another oar here, I think there are

two structural problems with the current approach:

1. The context hasn't been clear. E.g., I had

downloaded a couple of code samples previously and

unzipped them into a single directory, but not looked

at them right away, and then I got the MVC one. That

got me to wondering how I would tell which code went

with what and so I zapped everything and unzipped it

into four separate directories. Now it turns out

that I have to go back the other way in order to run

it.

Ok, so maybe we need to look at our instructions to make things as clear as possible.

2. Given that one does have to put it all together,

it is going to be difficult to tell what goes with

what in order to look through what's new. I think

this is made more difficult by the current directory

structure. This directory structure isn't

appropriate to a real world context in which this kind

of code would be used. Why not set it up like a real

application?

I'm curious to hear what you mean by 'set it up like a real application'. What about the structure do you feel isn't 'real enough' ? I'm curious because this structure follows what we've used for the entire example app (AutoEdge), which you'll see in a few weeks when we post the whole project. Now we've split the structure by client type, and server, and they by function within each, which from my long years as a partner seemed to work reasonably well. But I'm always open to new ideas

One of the structure issues is how things are distributed in directories. I'm pretty sure that I'm going to be disappointed to find out that this example isn't OO yet, but even if it isn't, let's look forward to what it should look like when it is.

So, based on all your OO experience with other languages, what is the first thing that you should expect about the location of this kind of stuff ... that the path should start with com/progress, right? And, below that one has an application group, a specific application, and a category. E.g., if one is going to have a set of component for maintaining customers, for example, one shouldn't have CustMaint.p in the top directory. Instead, it should be in something like com/Progress/Autodoc/AR/Cust/CustMaint.p. Now, there are some different approaches one could take, like putting data access layer components in one place, UI components in another place, etc., but at least create enough of a directory structure so that if the application were built up to something large that one wouldn't end up with hundreds of programs in each directory.

This is just one point, but the whole idea is to build pieces like they were supposed to be part of some large, complex suite of applications, not like they were some little toy.

I'm curious to hear what you mean by 'set it up like

a real application'.

...

Now we've

split the structure by client type, and server, and

they by function within each, which from my long

years as a partner seemed to work reasonably well.

But I'm always open to new ideas

A proper directory structure is one thing, a normalized database schema is another important thing. Don't assume that the currency details are part of the order table: there should be a currency-table as well. And a customer consists of more information than name and salesrep. These hierarchies make it interesting designing a dataset for order entry.

Some applications are multi-company applications, so tables can have a company-id as part of their uniqueness constraint. Some information can be company independent. You can imagine defining product information as company independent, but the pricelist should be company dependent. A customer can have some discount rules, so fetching a product price can be fairly complex.

Not all applications use an artificial primary key that can be generated at the client-tier for instance. How do you deal with un-assigned primary keys that get assigned during the database transaction. When you do want to use an artificial key, what is a proper data type to use (issues: proper index distribution and how to solve a database repair). What if you don't want to support sequences, since you want to port the application to another database type.

The UI of the typical Progress sample application is also very unrealistic: ever seen a deployed Progress application with 3 browse widgets? I wonder if you started the sample application with a UI-design upfront and implemented the business logic later on or did you work inside out (from business logic to UI). When you start with the UI you will find you have to make some concessions. It would be nice if these concessions are documented...

Theo.

Good points! I think the overall point is that at least one of the people involved in designing the thing should have experience with a large complex application so that he or she can do things in the way that it is necessary to do them in that context. If you start out by thinking in terms of an isolated simple application, you end up with something simple.

Possibly the worst aspect of this is the schema. With an overly simple schema, one can't create interesting examples. With a reasonable schema, one could, at least, create one's own examples.

the entire example app (AutoEdge), which you'll see in a few weeks when we post the

whole project.

Any update on when this is likely to happen?

the entire example app (AutoEdge), which you'll see

in a few weeks when we post the

whole project.

Any update on when this is likely to happen?

Hi Thomas

Not long now Our current target is by the end of october (subject to change of course!). We're currently in the final phases of recording supporting material etc, so we can explain as much of the project as possible, and not just simply throw code over the wall. As soon as we have a final date I'll let everyone know.

Hi all, sorry I'm a little late on this one but here are a few comments:

I applaud what you are trying to do

BUT

When I compare it to Spring/Hibernate or EJB3/Hibernate and the annotations methods they use what we have here really just seems “too hard” and “too much work”. Why don’t you look at the EJB3 tags and implement something similar??

Hi all, sorry I'm a little late on this one but here

are a few comments:

I applaud what you are trying to do

BUT

When I compare it to Spring/Hibernate or

EJB3/Hibernate and the annotations methods they use

what we have here really just seems “too hard” and

“too much work”. Why don’t you look at the EJB3 tags

and implement something similar??

Sorry for the late response, I've been on the road the past few weeks and internet access wasn't always possible.

I'm interested in the comment about 'too hard'. Can you exapnd a little on this? Obviously one of our aims to to try and make this whole architecture stuff easier, not harder, so anything you can feedback is very welcome, especially as we're about to move in to a phase of designing some OO based reference implementations.

Thanks

Mike

When we are making the comparison of "too hard", let's compare apples to apples. What you are looking at on the ABL side at this point is hand writing code for each instance. A fair comparison would be comparing that to hand writing everything in Java without Hibernate. It just means that someone needs to create the framework so that it doesn't all have to be done by hand.

Ok - why does it look hard? there is just a "lot" of it and its "so" different from the other approach we see in Java and possibly .NET. I took the PDF and showed it to about 20 developers, they all said "it looks too hard" and "why don't they just "annotations" and "why can't they just make it like EJB3 - thats simple to understand". I suppose it also comes back to what T said (in his post) - there are lots of frameworks in Java/.NET and lots of tools (e.g. Hibernate) and this is one of the major areas Progress is missing. IF you take a look at the UML/MDA forum you can see lots of comments on how to generate the DAO layer from UML etc. I think this is much easier than hand crafting too.

does that make sense?

Well, but I have no intention of developing without a framework or without using MDA. OK, so we can't go borrow what someone else has done, but that doesn't stop us from doing the same thing and possibly even sharing the results.

Not to mention that what is unfamiliar looks hard and I would gather you are showing this to people who are familiar with Java rather than 20 ABL programmers who have never done any Java.

Not to mention the small issue of all current docs still being in terms of .p ... they will be cleaner when they are .cls.

No - the developers all had 5 - 7 years "enterprise" Progress experience (across DB, AppServer, WebSpeed) as well as c/c++ and more recently Java/J2EE. These are they guys who helped build our own DAO layer and "ValueObjects" into our 4GL.

Yes, I think we do need a framework to simplify the ABL. The metrics we have on Java vs ABL us to be that Java was 4 times slower than ABL, now Java is faster ..... Oh, and its free too (which helps).

All - please let me stress that I think this is a "really good" idea and I'm not trying to "pour cold water" on it or anything. I'm just trying to ensure that the ABL remains a "language of choice".

All - please let me stress that I think this is a

"really good" idea and I'm not trying to "pour cold

water" on it or anything. I'm just trying to ensure

that the ABL remains a "language of choice".

All understood and gratefully received. My job is to help make sure that '..the ABL remains the language of choice' So my aim is to make sure that the materials we put out get over this barrier of 'too hard'. I'll certainly go and delve deeper into the EJ3B/Hibernate stuff, I must admit I've only given it a cursory glance so far.

But I also have a related question, do you think it's the leap from client server to n-Tier that is difficult, or do you really see it as an OERA related issue, or simply that the OERA adds another level of complexity onto the n-Tier architecture which needs more explanation and supporting materials/code etc?

But I also have a related question, do you think it's the leap from client server to n-Tier that is difficult, or do you really see it as an OERA related issue, or simply that the OERA adds another level of complexity onto the n-Tier architecture which needs more explanation and supporting materials/code etc?

I think that there are really two separate issues here. One is the complexity of N-tier, layered architectures, i.e., OERA. There is an inherent complexity here that has to be tackled in order to comprehend how the whole thing works and what aspects belong in what layers. Like even simple things such as field validations against a database table where the person has probably had this in the same program as the UI or at best separated into the layer on the AppServer and now has to deal with the notion that nothing touches the database except the data access layer. Once some of these rules are internalized, I think in some ways the actual development can even be simplified because there are strong patterns which emerge which typify the components of any particular layer.

The other issue is that ABL developers, unlike Java developers, are approaching this complex development problem with little more than raw, line by line code, while the Java developers tend to have a variety of toolkits, frameworks, code generators, etc. to facilitate what they do. Moreover, the concepts of the N-tier complexity are less new there and so there is more of a supporting culture and even some aspects of language support, if you want to call an EJB language, for example. So, the ABL developer is much more in the position of having to figure it all out from scratch, rather than being able to draw from the community. Hopefully, we will get some framework development and practice and will all get more comfortable with the ideas and then it won't seem quite so hard.

EJB3 -- see here: http://trailblazer.demo.jboss.com/EJB3Trail/.

And yes - we need something far LESS raw!!! I really, as a developer in 2006, don't want to care about Fills etc. I want to write DAOs like this:

class State {

@ID

def var id as dec no-undo.

def var name as char no-undo.

@ManyToOne

def var Suburbs as Collection no-undo. /Yep - a collection/

@OneToMany

def var CountryID as dec no-undo, /Link back to country/

@FinderQuery whereInAus

"for each state where state.country.countryName = 'aus'"

}

Anyway - hopefully this helps. This is what I want to see. Then i can say

Collection States = null.

States = serviceLocator.getStateService.getStatesInaus();

Collection States public getStatesInaus() {

return getStateDao().whereinAus();

}

Muz

Again, I think there are a couple of different issues here.

One, not specific to the example in this post, is the degree to which one can create common shared code that gets written once and then not repeated in every instance. There has clearly been some good thought in this direction in the AutoEdge example code. It doesn't pretend to be production ready ... and, of course, I would want to redo it as classes, but it seems to provide good examples of layering.

Another, leaving aside the specifics of how you have presented this example, is the whole notion of model to code. For a DAO in particular, I think this is very achievable using UML and MDA ... we just need someone to do it and be willing to share.

Finally, we have the specifics of how you say you want to write it. If you really want to use this notation, it is still achievable, but you probably will have to write the generator yourself.

Finally, we have the specifics of how you say you

want to write it. If you really want to use this

notation, it is still achievable, but you probably

will have to write the generator yourself.

Yeah - unfortnuatel PSDN keeps dropping out over here in Aus and just logging in can take 4 or5 attempts. So I often don't get a "run on".

Arghhhhh!!!!

I'm an old V6 developer, wich over the years develop some V8 and V9 code too... I'm just taking contact with OO and OE10.

IMHO, the example you provided looks a lot like any .Net language... It's this what we want for our beloved ABL?. I'm not sure...

Sorry I don't have any alternatives...

Anyway, I'm very interested, so please, please continue this thread!!

Regards,

To each according to their own taste, I guess!

Having written a program generation system for ABL back in the early 90's which used specification files like this in principle, if not in actual appearance, I am looking forward to doing the generation from UML models using MDA.

The one really tricky thing about this process is that, while UML 2.0 is much more complete than its predecessors by far, the Action Language is still only at the level of a definition of the semantics, not the actual language. So, we are going to have to create our own Action Language. Fortunately, ABL itself may not be a bad starting point for this language, if we throw out all the UI stuff. The Action Language is what one uses to specify algorithms.

Is it "do or die" for the ABL??? I think we need some real help with tools, frameworks and writing less code. Less code means less cost, less bugs, fewer headaches .....

No, I don't think it is do or die. In fact, the really depressing thing is that no matter what kind of great framework and MDA tool we might create, there is site after site after site that will never use any of it because they already have a reasonably complete customized application and no need or desire to get into all this fancy stuff. Only if they become non-competitive (if an ISV) or run into other critical business issues such as EAI or need to move to browser clients would they ever consider a major rewrite and without that major rewrite all they are likely to do is patch.

Now, that is a very serious issue for PSC, but it isn't this thread.

Is it "do or die" for the ABL??? I think we need some real help with tools, frameworks and writing less code. Less code means less cost, less bugs, fewer headaches .....

I agree with you about the help we need... What I don't undertand its how a 3gl like coding style can help us... English it's not my native language, so excuse me if I don't get you... Please feel free to educate me, because I'm trying to learn...

Regards,

One way to possibly look at is

(3GL + frameworks + tools) > 4GL

Now this may not be true in all cases but ....

Note: EJB3 is still, probably a 3GL

Message was edited by:

Murray Hermann

The point of a 4GL over a 3GL is productivity. Back in the 1980s I remember reading a report of a study on programmer productivity which found differences of up to 1000 to 1 between the best and the worst. Approximately a factor of 10 was assignable to each of developer experience/aptitude, language, and tools. So, clearly, someone writing Java who is experienced and using a really good tool set is likely to be more productive than someone writing ABL by hand, but I don't think that is a new thing dependent only on the latest tools. We all know or have heard stories about the guy that can turn out reams of C per day that actually work, even without tools.

So, to me, the lesson is to always use or create the best tools that one can and to use the best programmers (some tools help significantly in making a lesser programmer into a better one). And, when the tools don't write the code for you, I would rather write in ABL.

With 1000 to 1 or even greater productivity out there, no one language is going to live or die based on its productivity ... there are too many other factors.

What you should worry about is what kind of environment you are going to have to work in. Do you have to write a lot of repetitive code? If the answer is yes, then fix it.

Maybe not the best example (for a lot of reasons...) but... I work every day in a team where the main developing activities are in the .Net area...(not mine) There are no day in wich I'm not astonished to see how hard some things are for this guys and how easy it would be with old plain ABL... (sometimes code, sometimes architecture...).

I know there exists some places with .Net framework that rocks, but still I´m not convinced by all this new stuff..

I'll check EJB3 info to have an informatted opinion...

Regards,