Settling on an architecture - Forum - OpenEdge Architecture - Progress Community
 Forum

Settling on an architecture

  • My architecture for idiots (I like this name for many reasons)

    The main points in guiding the design of the architecture are -

    Before anything else, it should be easy to understand and simple to write. It has to be practical before anything else.

    Secondly, it needs to be flexible and suitable for real world challenges.

    The main design decisions -

    1. DATA-SOURCE object will not be used in the implementation.

    All the preTransaction, postTransaction etc. validation hooks will also not be in the implementation. Like the DATA-SOURCE object, I think, they're mostly an unneeded complication, and they remind me too much of the things I didn't like in ADM2.

    In general, the dataset will be filled by one single query, and changes will be saved using a single procedure containing all the validation logic needed.

    There will be one general purpose fetchData( ) method and possibly several fetchDataByXXX( ) methods that will use a fixed join order and indexes, mostly for use with browse widgets (or similar) where scrolling is needed.

    There will be one general purpose saveChanges( ) method and possibly several specialized operation methods, for example, deleteXXX( ), newXXX( ) etc.

    2. There will only be BE's, DAO's will not be used in the implementation. The BE will also be incharge of mapping the internal view to the physical store and hiding the physical implementation.

    Although it is a good theory that there can be several DAO's for different types of data stores, for example, Oracle, SQL Server or even unmanaged data I really don't see us using this or almost any other 4GL application not with a Progress database.

    Other reasons for using DAO's, like, using several data sources don't seem reason enough to justify their use. The BE does a good enough job of abstracting and localizing the physical implementation, promote code reuse etc.

    3. The security and context management will mostly be moved to the interface layer. The BL will for the most part not have it's own security or context built-in.

    The way I figure it is -

    With a GUI interface the users are mostly (I know not always) in a controlled environment on a LAN, there's isn't much chance of hacking inside this zone. So I don't think the AppServer access needs it's own beefed up security.

    With a Web interface all users access the application through the interface (and also through a single point entry, i.e., the web-disp.p) and I don't see a need to independently protect the BL running either locally or on a separate AppServer. And likewise for web services. I mean, you usually put security in the entrance

    4. Because of that a Service Adapter/Interface will not be used in the implemented. BE's will be either runned locally or remotely through a proxy making dynamic calls to their direct full BE (similar to the Dynamics implementation). BE's will be super procedures.

    In the reference implementation it seems that the BL is represented as a much bigger and almost independent part of the application and the UI as a small/thin shell. I think, in this implementation the BL, well, only manages the data and the UI which are the menus, lots and lots of screens is still a very big or even the biggest part of the application.

    5. Dedicated reporting and BI will mostly be done using SQL views, stored procedures etc. Although, the biggest problem is the lack of experience in the 4GL community with SQL and the need for possibly acquiring different skills.

    Microsoft Excel will also be highly dependent upon for the reporting presentation. We've been using Excel's advanced reporting features increasingly in the past year and we've been very happy with the results. And not least due to the ubiquity, familiarity and attitude that users have towards the product.

    It's also a much less expensive alternative then the enterprise reporting tools on the market. Practically free since almost all the intended users already own Microsoft Office.

    I believe even though it is different then the reference implementation it does for the most part adheres to the OERA and it's intended goals.

    Appreciate any responses, be kind

  • I think this approach of storing everything in a single entity works for a particular scenario, but not all. And when you have a complex entity, you can alsways delegate work internally to other classes, the caller doesn't have to know about that.

    So besides your entity, there must be more class types in your archticture. Think about static data.

  • All the preTransaction, postTransaction etc.

    validation hooks will also not be in the

    implementation.

    So what if you want to implement a user interface that checks the state of the data before its saved? So when you enter a product code during order entry, you want it to pick up defaults for the orderline. Where do you put this logic? When you enter a product, where do you validate that the product is a valid product (there can be some business rules associated that define if a product is valid in the order context)?

  • 3. The security and context management will mostly be

    moved to the interface layer. The BL will for the

    most part not have it's own security or context

    built-in.

    Who will be responsible for filtering data:

    - user XX is not allowed to see invoices of customer YYY

    - user XX is not allowed to use all price agreements

  • 4. Because of that a Service Adapter/Interface will

    not be used in the implemented. BE's will be either

    runned locally or remotely through a proxy making

    dynamic calls to their direct full BE (similar to the

    Dynamics implementation). BE's will be super

    procedures.

    This means that a business entity will get a huge responsibility. The idea of OO is to think in responsibilities. Try to do a CRC-session (http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/) to find out if your entity is doing too much...

  • 2. There will only be BE's, DAO's will not be used in

    the implementation. The BE will also be incharge of

    mapping the internal view to the physical store and

    hiding the physical implementation.

    It could still delegate the actual data access to a dedicated data access component and that data access component could implement all queries required by the entity. The shift is that you will use one data access component instead of multiple. But you could do the latter if you want to, when you want to fetch code values for instance. This way you can potentially generate the data access components, so your business entities are slim(mer) by default...

    You should also consider implementing a dual interface:

    - a dataset/temp-table return value

    - a query return value for reporting

    This way you can use the same component for reporting or batch jobs as well.

  • So what if you want to implement a user interface that

    checks the state of the data before its saved? So when you enter a product code during order entry, you want it to pick up defaults for the orderline. Where do you put this logic? When you enter a product, where do you validate that the product is a valid product (there can be some business rules associated that define if a product is valid in the order context)?

    I didn't say there isn't validation logic.

    The common, dynamic method for save/commit changes with sets and sets of validation hooks is just too elaborate.

    Instead a simple strait forward procedure can traverse the changes in the dataset and save/commit the changes to the physical store. All the validation logic needed for this operation will be apart of the procedure where ever needed.

    I'm not saying validation logic can't be modularized into internal procedures or methods if it's being repeated. There can be stand alone validation methods that can be called from the UI or another BL object if needed. And there will be some very basic validation logic in the UI.

  • Who will be responsible for filtering data:

    - user XX is not allowed to see invoices of customer YYY

    - user XX is not allowed to use all price agreements

    Security will be in the interface is it always has. I'm not saying everything we used to do building applications was good but this works like a charm.

    Who can enter which menus, screens, what functionality is off limits to whom etc. is implemented in the interface.

    Of course, there can always be small exceptions to this rule but in general security is done at the entrance and not all over the place.

    Context will be managed for stateless interfaces, like, web UI and webservices.

    Why does the BL in the OERI but it's also hinted on with the OERA is almost a separate, standalone application with it's own separate security and context management ?

  • This means that a business entity will get a huge responsibility. The idea of OO is to think in responsibilities. Try to do a CRC-session (http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/) to find out if your entity is doing too much...

    If anything it will be simpler, much simpler and will only deal with, well, handling the data.

    The BL would not be a separate application.

  • It could still delegate the actual data access to a dedicated data access component and that data access component could implement all queries required by the entity. The shift is that you will use one data access component instead of multiple. But you could do the latter if you want to, when you want to fetch code values for instance. This way you can potentially generate the data access components, so your business entities are slim(mer) by default...

    You should also consider implementing a dual interface:

    - a dataset/temp-table return value

    - a query return value for reporting

    This way you can use the same component for reporting or batch jobs as well.

    One can do many things but without mainly a real need for several physical stores and non-Progress database data sources it is a very expensive unneeded complication.

    All the unneeded objects that would have to be written and all the attach/detach data sources, callbacks and on and on and on, that at the end of the day will not have a real use.

    In regards to passing queries for reporting. 4GL query objects (the 4GL object) are so limited that there are just too many real world cases where they couldn't be used.

    In general, I believe, BE can be used for the transaction processing part of the application, maintenance screens etc. and including basic reporting, generating forms etc.

    Dedicated reporting and BI will be done using SQL. At the current situation 4GL/ABL is just not suited for real world reporting and BI needs (although it is very well suited for transaction processing).

  • You should also consider implementing a dual

    interface:

    - a dataset/temp-table return value

    - a query return value for reporting

    >...

    >> In regards to passing queries for reporting. 4GL

    >> query objects (the 4GL object) are so limited that

    >> there are just too many real world cases where they

    >> couldn't be used.

    You can return a class instance representing a resultset, which wraps the query. The result would be a typed query with buffer properties and a Next()-method.

  • Security will be in the interface is it always has.

    I don't hope you mean "user interface" here, do you? Else you're exposing your entities through the AppServer and anybody can use them without any security applied. That doesn't seem right.

  • Why does the BL in the OERI but it's also hinted on

    with the OERA is almost a separate, standalone

    application with it's own separate security and

    context management ?

    Because it's an aspect of the application, a feature. And you can plugin a different implementation, like LDAP authentication, table based authentication, etc.

  • If one needs to plug in the business logic to another application why not do it through the integration layer ?

  • I don't hope you mean "user interface" here, do you? Else you're exposing your entities through the AppServer and anybody can use them without any security applied. That doesn't seem right.

    Yes. That's what I said.

    The case where users have, possible, access to the AppServer would be GUI. In most cases, this would be on a LAN in a controlled, trusted environment or at least in our case.

    It would mean that there would need to be some hacker that we don't know of inside this zone, with a 4GL development package that would somehow probe the BE's and make calls to the AppServer.

    To me it seems like a seriously unnecessary, unproportional overhead to develop the BL as a separate application with it's own security, context management etc.

    Besides if there is a hacker inside this zone and especially one that knows his way around Progress there's so many other things he can do, and even not in Progress.