Ok, Hit me with suggestions!

Mike, I think the biggest need at this point is to start crossing the bridge from "here are some things to think about" to "here is how one actually tackles this in production".

Sure, and so I'm offering up the chance to help define what the bridge is/should/could be.  There is no point building the bridge if it's not the right length to get to where you're trying to go, or the right width and strength to handle the volume of traffic!!  Whatever we produce has to be of benefit, provided in a consumable manner and to add value, otherwise what's the point.  I can easily pontificate all I like about what I think are the needs & issues (as you well know), but I'm trying to be inclusive here so I get the broadest sense possible of the real issues as they pertain to Architecture, it's implementation etc.

I would like to see more of "real world" samples of object oriented architectures.
And by that, I don't mean architectures where the .p have been replaced by .cls.
I want the building foundation of the architecture to be OO.
I want data to be represented by class instances.
And as much as possible I want relational concepts replaced by OO concepts (ie: relation between 2 tables -> association between classes, ...).

Guillaume.

Thanks Guillaume.

If someone were to give me the job, the first thing I would do is to draw up a proposed architecture and put it out for comments.  This includes both an identification of needed framework components in the fashion of http://www.oehive.org/OERAOSI and a discussion of the architectural target and techniques.  The latter should include some proof of concept code.  This doesn't need to be extensive and it can include comments instead of actual code for business logic, but it should be a genuine candidate model for a production system.  While gathering and resolving input, I would then work up a plan for two parallel lines of development -- one aimed at the framework components and the other at models illustrating the techniques of the architecture.  The former line of developement is really just prioritizing the components according to most commonly used or most fundemental first.  I.e., some components use other components so you need to create the used component first unless it is sensible to stub it.  For the models, I would look at UML models and MDA transforms since then the illustrative code also becomes a tool which other people can use.  Maybe one can borrow from iMo or maybe that would just get us another Smart Objects.

There is going to have to be a pretty basic decision here in whether to go OO or not.  I know that PSC wants to keep telling people they can go either way and mix and that is a very understandable and valid method.  But, I don't think you can create an effort like this one and do both.  The ideas can be applicable in either, but beyond the ideas you are going to have to choose and I'm sure it won't surprise you to hear that I vote for committing to OO.

Of course, I might have a hidden agenda since, if this effort pointed to the need for language improvements to do the job right, as we found with Smart Objects, then those language enhancements might get added to the language earlier than they would without this incentive.

Note that I rcognize that what I am proposing here is a pretty big project, not just a few white papers, but I think that there can be white papers which emerge from it starting quite soon.  Unlike most existing white papers, though, some of these should go through significant version changes and the project evolves.

Moreover, were someone to actually give me this job, I would lobby heavily for a third line of development, i.e., exploring technology and techniques for getting from the systems that already exist to the systems of the future.

Thanks Thomas.

Thanks ... but no job offer? 

Good point made by Thomas.
PSC have to entirely commit to OO, and some kind of OO architecture initiative would really help improving the language.

Hi Mike,

another thing to consider is the tool aspect. Business Entity design (usually) starts with the ProDataset definition (and if someone argues, please open a separate thread). The T4BL might - in a non enterprise level, so a quick prototyping, not much more - environment work for defining some dataset definitions...

But then?

After reading white papers, people want to see Business Entities with their own database design, not neccessary the sports2000 or another variation of it (like autoedge). A common comment I've heard when introducing OERA or just ProDataset based, layered business logic and OO (GUI for .NET) based UI design to Progress customers was that it all has goten that complex and getting a foot in the door has become so time intensive.

On the other side I know some developer teams that are very productive (and focussing on business logic not framework designs) because they are successfully using all the latest technology without caring about it every day as they are using tools from independent consultants (Thomas Wurl's ticEnterprise for the backend and our SmartComponent Library as a GUI for .NET based OERA consumer as one sample of many others).

If PSC isn't going to deliver a flexible Business Entity generator and UI component builder, how about providing links to people that provide free or commercial tools for all aspects of building the application:

- Backend

- Frontend

- Common infrastructure

The tools may or may not be UML or ABL based at all.

If that's something you'll consider I suggest to open a separate thread asking for the solutions that are around (free and commercial) and then you can judge which ones qualify for a list published by PSC.

Microsoft provides similar links to vendor and open source sites from within the IDE. Information that is accessible from out of the box is very important. I don't know if you have statistics about how many partners have developers that are actively or passively participating on PSDN (sorry Progress Communities). My experience is, that you only reach a low percentage around here.

Mike

Hi Mike

Thanks for your reply.

As always you raise some interesting points, and I agree that Productivity is a key element in anyone being successful, and in fact it's one of the highlighted 7-Keys to success that you will hear more about at Exchange OnLine next month.  The question, then of course, is how do we provide that Productivity and, as you point out, should that necessarily come from Progress, as there are a good number of 3rd Parties providing a range of solutions.  And, if PSC were to provide something, what should that something be, and how far should it go.

Would it be sufficient, for example, to provide a set of Reference Components (for want of a better term), that were fully class based, implemented using Interface classes, that provided that key structure of a base set of OERA classes.  These Reference Components could then be taken, and interchanged with any other code so long as it conformed to the Interface Classes that form the back bone of the structure.  The aim to provide breadth as opposed to depth (i.e one code deliverable per identified Reference Component to then be 'fleshed out' as opposed to a limited set of Reference Components that were more completely implemented).  The danger of course of providing a more complete implementation is how much of a 'fit' it can be for everyone.  So to use an analogy, should we be helping determine where the hole should be, provide a set of tools, and then you can dig as deep as you like, choosing to use the digging device with the implementation we provide, but also

allowing you to replace that diging device with a JCB so you can dig faster, if you choose

Or is the expectation that there should be, in the box, to use a very loaded term, Framework?  Again, if so, how far should that go, we've all seen in the past the advantages, and dis-advantages of having a full framework in the box.  Maybe there is a half-way house, a mix of some simple tooling with the Reference Components.  Maybe it's a combination of all the above plus the 3rd Party tools you mention?  Does this have to be in the box or is it good enough to be delivered via Progress Communities?  In the past there has also been talk about an open source, or collaborative efforts around some OERA components.  What's the likely hood of that getting some support?  Again history isn't necessarily on our side, look at POSSE or the SmartObject MarketPlace (now I'm showing my age!!).

I also agree with your last point about the current reach of Communities, and it's something I'm currently looking into.  There is a big community out there, so either we have a lot of lurkers (and if your one of them reading this, then please don't be shy to post something, everyone's opinion is welcome and valid), or we're missing a few!! (If you want to discuss this point, please start a new thread and don't hi-jack this one!!)

Mike

mormerod wrote:
Would it be sufficient, for example, to provide a set of Reference Components (for want of a better term), that were fully class based, implemented using Interface classes, that provided that key structure of a base set of OERA classes.  These Reference Components could then be taken, and interchanged with any other code so long as it conformed to the Interface Classes that form the back bone of the structure.  The aim to provide breadth as opposed to depth (i.e one code deliverable per identified Reference Component to then be 'fleshed out' as opposed to a limited set of Reference Components that were more completely implemented).

IMHO *this* is the way to go.

PSC leads and sets standards, but should not provide implementations.

I believe history is on your side here!

Thanks Peter.

There is a discussion in a thread on PEG in which Guillaume has objected to my seeing TTs and PDSs as a virtue and advantage in ABL which one should be using, even though it meant a different approach in some cases than one would use in traditional 3GL OO.

My response there was:

There is a reason why RDBMSs have persisted instead of being replaced by  OODBMSs ... and it is because there are many kinds of problems,  especially those involving large amounts of data, where the relational  model is much faster than the OO model.  It is for those things that I  advocate using TTs and PDS in ABL rather than attempting to follow the  way those things would be done in OO 3GLs.

Take, for example, the problem of ascertaining the total dollar value of  the orders which will ship for a certain customer within the next  month.  Imagine there being 1000 open orders for the customer.  Imagine  needing to look at all 1000 and run a method to check the date and  another method to get the dollar amount to total.  Conversely, imagine  selecting limited rows from the temp-table and adding up the amounts.

There are two key questions to ask about any proposed such framework.

One is the degree to which it is an open set of components.  I.e., can I take an Authorization component and drop it into my existing application as a first step or does the whole thing have to be used together like ADM?  And, can I decide that I need that component to behave a bit differently and subclass or modify it and incorproate back into the framework with little difficulty.

The other, frankly, is how good it is.  If it isn't production quality code built in a way which experts will agree is a good model for further development ... don't bother.

I would rather this be a community project than a PSC only project.

IMHO *this* is the way to go.
PSC leads and sets standards, but should not provide implementations.
I believe history is on your side here!

I fully agree with that approach. OESI as OpenEdge Standard Interfaces :-)

OpenSource and commercial tool vendors may or may not pick up and that should give an implementer real freedom and choice.

One is the degree to which it is an open set of components.  I.e., can I take an Authorization component and drop it into my existing application as a first step or does the whole thing have to be used together like ADM?  

We definitively have made different experience with ADM or ADM2. It just provided an OO simulation at times where the language had no inheritance, encapsulation (and for the ADM1) event handling.

It wasn't/isn't too hard to take things out or bring in new stuff.

Umm, OESI, I kinda like that

Of course, this is all still theory, and to be taken with a pinch of salt, but yes I'd like to think that if everything was implemented via Interface Classes then you can swap code in & out to your hearts content as long as it implements the Interface.

I'd like to press further on this 'Production Quality' statement.  What do you mean/envisage by that?

It wasn't/isn't too hard to take things out or bring in new stuff.

My remark wasn't about the difficulty or lack thereof of using ADM and then modifying it, but about the possibility of using some specific component from ADM to enhance an existing, non-ADM application.  With a couple of limited exceptions, using ADM is and all or nothing proposition and I think this has been one of the biggest obstacles to its adoption because lots of people have complete existing systems.  I feel strongly that any new framework should be constructed of components which can be used individually as far as it makes sense to do so.  I.e., it is possible to have two components, one of which depends on the other, but one should then either be able to use only those two components without regard to the rest of the framework or to easily stub in a replacement for the second component.

Of course, this is all still theory

It may be theory as applied to PSC ABL frameworks, but it is certainly tried and true practice in the industry.  We wouldn't be attempting something new or unusual.

I'd like to press further on this 'Production Quality' statement.  What do you mean/envisage by that?

I mean something designed in such a way that it has all the qualities one would want in a component  that one would use in a production environment.  I.e., its design needs to incorporate the complexity of real world requirements in the area which it addresses and the implementation needs to be scalable and performant.

I would suggest, for example, that a design which puts a temp-table in every business entity object is inherently non-scalable because of the known issues of instantiating thousands of temp-tables.

Give me all the capacities of ADM2 in something that respects OERA, that has development tooling at least equivalent to what we have for ADM2, that is class based, overridable (we can extend what is already there) and that can easily make use of the GUI for .Net and I'd be happy.

I'm with you - that's a big productivity loss when coming from the AppBuilder. For real development productivity the tool (OpenEdge Architect) needs to be aware of the framework implementation or at least the rough structure. So the lack of such an client frontend structure (something like the ADM2 - just better ) and the level of productivity in the Visual Designer go hand in hand (can't achieve one without the other).

We've build such an environment on top of the Visual Designer ourselves: http://www.consultingwerk.de/index.php?id=184&L=1 Our component library leverages prebuilt toolbars (that still can be modified in each screen using the Infragistics wizards), browsers, viewers, .... All components will be linked with each so that they know how to communicate with each other. Our design goal was productivity without dictating the UI design.

Productivity with the UI is nice ... but what about the rest of the application?

To me, the route is model to code.

mormerod wrote:
In the past there has also been talk about an open source, or collaborative efforts around some OERA components.  What's the likely hood of that getting some support?  Again history isn't necessarily on our side, look at POSSE or the SmartObject MarketPlace (now I'm showing my age!!).
Mike

POSSE was a Very Good Idea.

The way it was executed was not - PSC raised too many barriers to active participation by the outside community.

If you want participation from non-PSC people, PSC needs to lower the barrier to participation as much as possible.