OERA from Autoedge + Dataview integration

I don't think you can really get there from here. You can do little bits here and there, but really OERA is something that has to be designed in from the beginning. If we had a real OERA framework, you might be able to do something to automate going from one to the other, maybe, but thus far we don't even have the target defined. We have a few exercises, like AutoEdge, but they are far from production ready models ... and don't even use OO.

Hi Andrew,

I have developed an OERA implementation that uses ADM2 frontends and the dataview. I started about 2 years ago and the product is stable and has powerful features. The product is called "ticEnterprise".

I'm not sure about autoedge, but a backend for an ADM2 frontend requires a bit more functionalty especially to support the retrieveData() api for the ADM2.

Creating Business Entity , DataAccess Object and Data-sources by hand is a tough task - especially when the physical model changes. ticEnterprise includes a powerful generator that generates the entire backend except your custom business logic.

Please let me know if you are interested to get more information about it.

Thomas Wurl

Not to be skeptical, but I have some trouble believing that anything starting with ADM2 can get to anything more than a sort of OERA veneer. Anything that was really OERA compliant would no longer resemble ADM2. Can you tell us a bit more?

Why so skeptical? All the OERA modell/white papers/samples focus primarily on a suggestions to structure the backend or common services. Basically a way to layer your application.

If you put the ADM2 on top of the service interface it can actually be a very nice player in this architecture.

Did you see Haavards white papers on the DataView SmartObject?

Well, it starts with being skeptical of anything to do with ADM in any flavor or incarnation. This is not helped by whitepapers which we have seen on OERA which advocate things like passing temp-tables and ProDataSets hither and yon in what is to me a basic violation of encapsultation. While I can imagine ADM incorporating some kind of data layer (ignoring for the present the "leaky" nature of the way PSC illustrates the data layer being used, I haven't seen anything that suggests real UI layer separation such as we should be wanting these days.

The question is: what is an OERA veneer?

OERA defines a service oriented layered architecture. It defines

strongs separeted layders. It defines business components such

as business entity, business task and business workflow.

As a developer you have to have some kind of framework around it

that includes the common infrastructure. If you have done all of

this then you have created an OERA compliant architecture.

The ADM2 is just one possible presentation layer. According to

the idea of a layered architecture it can easily be replaced by

another one. The ADM2 doesn't really care about the backend, nor

does the backend care about the ADM2.

The ADM2 dataviews require a special api that the backend /

business entities have to support:

- retrieveData()

- saveChanges()

The ADM2 also supports batching.

This has been all written down by Haavard Danielsen in his

whitepapers about dataviews.

The responsibilty of the ADM2 ends with the serviceadapter.

A good idea is to have a generator for the backend that:

- Generates all datasets and keeps it in sync with physical db.

- Generates all business entity, data access objects and datasources

- Keeps the knowledge about all these objects in a neutral format

to be able to re-generate all of this when the model or

technology changes.

So the heard of the generator is a database that knows about

the physical db, temp-tables, datasets, business components and

the relations between each others. This database is the design

repository.

Another good idea is to have a tool for database design like

CA ERWin. A big part of the business logic of any application

is the referential integrity of the database. I think that this

logic belongs into the database triggers. I use Erwin templates

to generate ABL triggers from the model. With a generator that

knows about these rules it's also possible to generate referential

integrity rules into the data access object.

The db model also feeds the design repository with all table

relations that make it easy to generate dataset relations and

also keep these relation in sync when the physical model changes.

My custom ADM2 includes SmartObjects that embedd most of the

codejock controls. There are addional things like resizing,

dynamic lookups based on dataviews, treeviews and all that stuff.

I don't want to enter the discussion if oera is good or not,

or if it's OO compliant to pass datasets ...

As a tool developer I always have to make sure not to reinvent

the wheel and to pick my up customers where they are. I choose

the technology that's available and enhance it if required

to be more productive and to make the most out of it.

Best regards,

Thomas

I am absolutely with you on using generators to create as much of the application as possible. I am more inclined to use Enterprise Architect than ERWIN since it is then possible to model the application and not just the data relations. And, in that context it is possible to use MDA to do the generation so that both the data relations and the business logic is coming from the model.

Definitely agree with the MDA approach. I have used Enterprise Architect with the OpenEdge plugins and seems to be a pretty good generator of components for OERA as well supporting data modeling for OE dbs. I think it makes more sense to capture models in a standard like UML rather than a custom proprietary format. I read in another thread more support for OpenEdge in Enterprise Architect is coming. Also looked at autoedge. IMO there seems to be problems with it. I thought OERA was supposed to separate data access from business logic. But this wasn't demonstrated or adhered to very well. The session supers weren't very well designed and the code was messy and hard to follow. Also found that the transaction processing had a lot of holes and the error handling wasn't very good. Not sure if it a very good example of architecture for a real application.

You've picked up on many of the same criticisms that have been voiced since AutoEdge came out. I do think AutoEdge has value in providing a focal point for discussion ... more so that an lot of other sample code from PSC ... even if it is in order to point out why it is that one wouldn't do it that way in a production system. To be sure, I sympathize with the team that put it together since they started on it before there were any OO constructs in the language and naturally the work exceeded the original budget so the powers that be weren't very interested in backing up and starting over again. Even now that there has been some revisiting, it isn't a case of a real rethink, but more a touch up here and there. The problem, of course, is that being from PSC, there is a tendency in parts of the user community to think that it must be a good example that should be followed. It was never intended to be a model for a production system and they have said so over and over, but people still keep taking it that way.

I would love to get some good examples out there which are suitable for production use, hence the OERA OSI project. And, I would love to get some sharing going on about MDA models and using EA. Unfortunately, so far I can't get PSC to release the source code to the tools they have created and there haven't been other people publishing material to complement or supplement my ABL2UML work. One of these days ... maybe.

If it was never meant to be a model for a production system then it begs the question why it was ever done at all. Beyond being a focus of discussion that is, it seems like a waste of effort. Wouldn't a better base for discussion be an more solid example which factored in the basic reqs of production systems? At the very least I'd expect much better in the basics such as transaction processing and error handling from an example from PSC. I'm sure a lot of people out there are looking for a starting point for OERA. If autoedge was never intended for production systems and has so many basic flaws then what do people do?

Wouldn't a better base for discussion be an more solid example which factored in the basic reqs of production systems?

Well, that's the way I would prefer to do things personally, but it isn't a simple task to come out with a manageably small sample which still reflects the complexities of an enterprise system.

At the very least I'd expect much better in the basics such as transaction processing and error handling from an example from PSC.

Based on the code samples in the manuals?

I'm sure a lot of people out there are looking for a starting point for OERA.

It does appear that PSC has been effective in generating interest.

If autoedge was never intended for production systems and has so many basic flaws then what do people do?

The hire consultants to help them define a framework. Of course, that is often associated with compromise too since the company only wants to address the complexity of the problem it has, not the general problem. But, if people would start thinking about components instead of completely integrated frameworks, we might eventually get some contributions to the OERA OSI from this kind of work.

http://www.cintegrity.com/OERA