OE Reference Arccitecture and ORM considerations... - Forum - OpenEdge Development - Progress Community

OE Reference Arccitecture and ORM considerations...

 Forum

OE Reference Arccitecture and ORM considerations...

This question is not answered

Hello,

I've been asked to investigate the OERA as a prelude to designing a new from the ground up web based system with typical CRUD functionality. As part of this process I've looked at the AutoEdge|The Factory as an example of an implementation of the OERA.

I was wondering if anyone has found themselves in a similar situation. i.e Using OE116 and looking at developing a new system based on the OERA and if so what are;

a. the pitfalls

b. the caveats/provisos

c. the benefits

After downloading the sources and looking through the code the AutoEdge stuff looks very much like an OE version of something like a Java ORM framework such as Hibernate with the priciples of dependancy injection for example.

So, basically, what I'm asking is if you were starting from scratch, what type of framework (if any) would you employ and why?

Thanks.

All Replies
  • I would suggest, that you'll also have a look at the CCS specifications.

    And, there are also prebuild commercial frameworks that comply with OERA and CCS. Please contact me offline, if you are interested in a discussion how that could jump start a modern back- and frontend development.

    Sent from Nine

    Von: MBeynon <bounce-MBeynon@community.progress.com>
    Gesendet: 10.08.2017 11:01
    An: TU.OE.Development@community.progress.com
    Betreff: [Technical Users - OE Development] OE Reference Arccitecture and ORM considerations...

    Update from Progress Community
    MBeynon

    Hello,

    I've been asked to investigate the OERA as a prelude to designing a new from the ground up web based system with typical CRUD functionality. As part of this process I've looked at the AutoEdge|The Factory as an example of an implementation of the OERA.

    I was wondering if anyone has found themselves in a similar situation. i.e Using OE116 and looking at developing a new system based on the OERA and if so what are;

    a. the pitfalls

    b. the caveats/provisos

    After downloading the sources and looking through the code the AutoEdge stuff looks very much like an OE version of something like a Java ORM framework such as Hibernate with the priciples of dependancy injection for example.

    So, basically, what I'm asking is if you were starting from scratch, what type of framework (if any) would you employ and why?

    Thanks.

    View online

     

    You received this notification because you subscribed to the forum.  To stop receiving updates from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • We built NSRA Framework (for which I did a presentation at PUG 2011), that is radically different to ORM, as I never liked the concepto of ORM. You can find information about it here: www.nomadesoft.com.ar/nsra

    When we develop the framework (which is an Multi database / ABL server / Multi client framework) we did it to fulfill a wider need that what you seem to be doing.

    For such a "small" project, I will recommend to go for a prebuilt solution/framework (as Mike suggested). If you like the challenge of building a framework, the important points you should consider first:

    - Why? Clear goals for the framework itself, other than "build the website"

    - How? Layers, SAS, Protocols, technologies involved

    - Who? Not only who is building it, but, more importantly, who's going to use it

    If you search the PEG (I wonder if that is possible) you may find a lot of discussions about "OERA frameworks" taken place between 2010-2013.

    I can't sell you anything right now, but you are welcome to ask..

  • Many thanks for the answers everyone. I'm currently looking at the CCS project (So much to go through!) .

    Cheers.

  • I think OERA it’s more about layers and how one should build/use application’s blocks, very often this is referred to in relation with a framework that implements generic functionality of some of those blocks - data access, business logic, service interface, generic services (authentication, authorisation, logging, session/context management, etc) but it doesn’t automatically imply any framework.

    The ORM on the other hand tries to provide a simple solution for data access, specifically my mapping “objects” to underlying data storage and provide basic CRUD functionality some also supporting navigation based on table relations (foreign key).

    Outside of Progress world this is how an ORM might look like - http://sports.akera.io:8080/explorer/, you can see the “objects” being exposed, each with generic CRUD methods and some with convenient methods to access related (parent/child) data based on defined relationships. To get customer information using  the primary key a simple GET request like this can be used - http://sports.akera.io:8080/api/Customers/1 (last path parameter is the customer number), to get invoices for the same customer this simple request will do: http://sports.akera.io:8080/api/Customers/1/invoices

    Well, you might recognise the famous sports database so it’s still a Progress “app” behind that we’ve build for demo purposes - the actual web app using the services exposed by Loopback (the ORM part of Strongloop) looks like this - http://sports.akera.io:8080/. More complex business logic processing can be added to specific methods, using our node.js API we can easily call 4GL code by passing parameters around.


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • The same RESTful API's can be implemented with pure OpenEdge capabilities with ease. We have implemented true Restful API's for our Business Entities based on annotations. No need for node.js here.

    Sent from Nine

    Von: "marian.edu" <bounce-marianedu@community.progress.com>
    Gesendet: 11.08.2017 8:50 nachm.
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] OE Reference Arccitecture and ORM considerations...

    Update from Progress Community
    marian.edu

    I think OERA it’s more about layers and how one should build/use application’s blocks, very often this is referred to in relation with a framework that implements generic functionality of some of those blocks - data access, business logic, service interface, generic services (authentication, authorisation, logging, session/context management, etc) but it doesn’t automatically imply any framework.


    The ORM on the other hand tries to provide a simple solution for data access, specifically my mapping “objects” to underlying data storage and provide basic CRUD functionality some also supporting navigation based on table relations (foreign key).

    Outside of Progress world this is how an ORM might look like - http://sports.akera.io:8080/explorer/, you can see the “objects” being exposed, each with generic CRUD methods and some with convenient methods to access related (parent/child) data based on defined relationships. To get customer information using  the primary key a simple GET request like this can be used - http://sports.akera.io:8080/api/Customers/1 (last path parameter is the customer number), to get invoices for the same customer this simple request will do: http://sports.akera.io:8080/api/Customers/1/invoices

    Well, you might recognise the famous sports database so it’s still a Progress “app” behind that we’ve build for demo purposes - the actual web app using the services exposed by Loopback (the ORM part of Strongloop) looks like this - http://sports.akera.io:8080/. More complex business logic processing can be added to specific methods, using our node.js API we can easily call 4GL code by passing parameters around.


    Marian Edu

    Acorn IT 
    +40 740 036 212

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Sure thing Mike, just saying maybe dataset centric frameworks with data access/business entities might be too much if all you need is a web based system with CRUD functionality… surprised no one mentioned Rollbase already ;)

    As for node.js you’re probably right, no one needs that (javascript) when building a web application… luckily we’re not the only one making that mistake, Progress got that wrong as well with Nativescript (CLI), Modulus and just recently Kinvey (https://devcenter.kinvey.com/nodejs/guides/getting-started). But anyway, that RESTful API only need one command line to build and that’s to ‘discover’ the models from the database(s) and optionally define relations to get all that without any single line of code… ah, and using their client SDK’s you get to use the same API’s from iOS, Android or JS ;)


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Sure thing - one can always throw in additional technologies to complicate things that can also be done with the technologies most of us here master already. ;-)

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • LOL, just said “using” node.js there is only a matter of installing it and the dependencies all in all 3-4 command lines… it’s not that different than using the PAS (new or old), you do not need to master Java/Servlets/Spring to use the “pure” OpenEdge solution do you?

    Point being, if Progress decides at some point to move from Tomcat to node.js I’m sure no one will even bother… it’s still a pure OE solution :)

    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Right. But today the supported solution is Tomcat. And I still don’t understand what the benefit would be to add in additional technology for jobs that Tomcat with either of the OpenEdge AppServers does equally well. What’s your point? Do it just because you can? Because it’s cool? What’s the added value?

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Hi MIke,

    NodeJs opens up a world of (free) modules that can provide a wide range of services. Logging in via FaceBook, sending push notifications, integration with payment services, and so on.

    All of those things are harder to do with OpenEdge code running in Tomcat, right?

  • I do not say that there aren't things that node can do, that are harder with OpenEdge. That was not the point of the debate so far. But exposing restful services works just great from OpenEdge.

    Sent from Nine

    Von: onnodehaan <bounce-onnodehaan@community.progress.com>
    Gesendet: 12.08.2017 11:16
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] OE Reference Arccitecture and ORM considerations...

    Update from Progress Community
    onnodehaan

    Hi MIke,

    NodeJs opens up a world of (free) modules that can provide a wide range of services. Logging in via FaceBook, sending push notifications, integration with payment services, and so on.

    All of those things are harder to do with OpenEdge code running in Tomcat, right?

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Well, I didn’t even tried to start a debate here… my reply was only trying to address the ORM considerations of the OP, although that can be done with only OE components things are not that easy without a framework to provide the boiling plate while with node.js&akera.io&strongloop this can be done in five minutes. If you already have something that works great then there is no point in changing that, my point is not that node.js is cool nor that we just did that because we’ve could… as you know JS is there to stay, typescript did cleared some of your nuisances with it and the fact that the same language is now used on server side and even more on mobile native frameworks (nativescript) I would say node.js is here to stay even just because it’s easier to master one language that works everywhere ;)

    There was another thread about oData that tries to somehow standardise the RESTfull API’s out there, we did started at some point to build an oData facade for loopback but it looks like we’re not the only one so we’ll see how far we can go with this - https://github.com/htammen/n-odata-server… wouldn’t it be nice to be able to fetch data straight into our beloved Excel? :)

     
    Marian Edu

    Acorn IT 
    +40 740 036 212