New and Revised OERA Definitions - Forum - OpenEdge Architecture - Progress Community
 Forum

New and Revised OERA Definitions

  • Hi

    As a follow up to my exchange presentation, I just posted some new or revised definitions for each OERA component. Some are brand new definitions for things we've never actually put a paper out before, such as Service Adapter, Business Task, Business Workflow etc. Some are revised, such as Business Entity, Data Access Object, Data Source Object etc.

    These definitions reflect our latest thoughts and refinements on the OERA and it's components. Many of the changes to the revised papers are clarifications, as well as some subtle yet potentially interesting shifts.

    As always I'd welcome your feedback and comments. Maybe we take a paper at a time and have a healthy discussion

    Mike

  • Did you mean to post a link?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Yes, good catch, although I figured everyone has the OERA section so well bookmarked !!!

    For all the latest OERA stuff look here:

    http://www.psdn.com/library/kbcategory.jspa?categoryID=54

    Thanks

  • So, I eventually located 12 new definition documents ... right?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I just read the one on Presentation. I think it would be very valuable to either extend this paper or to provide a companion piece which talked about the MVP components is a bit more detail relative to how they are likely to be used for different UI types. I.e., what is a View actually going to contain if it is a traditional ABL GUI client versus a WUI client.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Sorry for the tardy reply, but yes 12.

  • I really like the Design & Consequence section of these definitions.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Following on the one on Service Requester: Service Adapter in particular, another discussion that I would like to see is a mapping of architectural components, contexts, and the products that one would use to support them. E.g., a service adapter needing to communicate with a service provider which was on a different machine and which was utilizing a non-ABL technology would point one to a connection via Sonic. But, if both ABL then .... etc.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Following on the prior post and the one on Business Components: Service Interface, I think there are some interesting questions which one might raise, including:

    You make a point of saying that the service interface is stateless. It is easy to see how it can be stateless between requests, i.e., there is no need for a memory of prior requests other than than which might be maintained by a context manager, as you note. However, it seems like one would actually want the call from a service interface to the appropriate business component to be async since otherwise it will be locked and unavailable for accepting other requests until such time as the request is complete. Do you have an architecture to propose for that?

    And, of course, if one achieves async calls to the business components, does this mean that the identity of the requestor travels with the message or is it part of the context?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • In Business Components: Business Workflow, most of the document seems to suggest that a Business Workflow is a component embedded in the Business Component layer. The exception being at the bottom of page 3 where you reference the simple solution of Sonic itineraries or the more complex one of using a BPEL engine. I get that one still has a conceptual Business Workflow element in the design, but I think it would be good to acknowledge that addressing this need with a component in the BC layer, addressing it on the bus, or some mixture of the two are really quite different solutions. This should show up in Design & Consequence particularly.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Business Components: Business Task is one that underscores questions about what products and architecture is under this conceptual structure when one gets to implementation, notably the concept of a Business Task as something that is stateless and persistent.

    If we are in the context of a service, as in SOA, then it seems perfectly reasonable that the session would create some task objects and that these might persist so as to be readily available for the next use (back to this in a minute).

    If, however, we are thinking in terms of something running on AppServer, would one persist a task object beyond a single invocation? Or, are you thinking in terms of running multiple AppServers, each specialized for a particular area so that having each session have a number of utilities running and ready to go could be sensible?

    And, if tasks persist for re-use, what cleans them up? Do you need a task manager which kills off least recently used tasks after a certain time?

    And, does the task manager categorize tasks? I.e., task A is performed frequently, so leave it running, but task B is performed only at month end, so kill it off when done.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Well, you knew I had to get there eventually, didn't you... In Business Components: Business Entity you are perpetuating the structure which I have argued against here ( http://www.oehive.org/OERAStrategies ) of separating the Business Entity from the Data Instance, thus separating the data from the logic and failing to encapsulate the data definition which must appear in both the Business Entity and the Data Access object.

    I also think there is an overly simplistic expectation here that one can have a super Business Entity that incorporates all possible logic related to a Data Instance. This misses out on a lot of the potential for inheritance in OO. Take, for example, the classic example of a Order class which has two sub classes InternalOrder and ExternalOrder. How do you construct one Business Entity which covers that? Especially without losing the advantages of inheritance?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I just read the one on Presentation. I think it

    would be very valuable to either extend this paper or

    to provide a companion piece which talked about the

    MVP components is a bit more detail relative to how

    they are likely to be used for different UI types.

    I.e., what is a View actually going to contain if it

    is a traditional ABL GUI client versus a WUI client.

    If you've not already, I'd reccomend looking at the exchange session from John & Sasha : Arch-11 Building your presentation with classes which does go into more detail on MVP and the components.

  • Following on the one on Service Requester: Service

    Adapter in particular, another discussion that I

    would like to see is a mapping of architectural

    components, contexts, and the products that one would

    use to support them. E.g., a service adapter needing

    to communicate with a service provider which was on a

    different machine and which was utilizing a non-ABL

    technology would point one to a connection via Sonic.

    But, if both ABL then .... etc.

    Yes, I'd agree, and it's something we're considering at the moment.

  • Following on the prior post and the one on Business

    Components: Service Interface, I think there are some

    interesting questions which one might raise,

    including:

    You make a point of saying that the service interface

    is stateless. It is easy to see how it can be

    stateless between requests, i.e., there is no need

    for a memory of prior requests other than than which

    might be maintained by a context manager, as you

    note. However, it seems like one would actually want

    the call from a service interface to the appropriate

    business component to be async since otherwise it

    will be locked and unavailable for accepting other

    requests until such time as the request is complete.

    Do you have an architecture to propose for that?

    And, of course, if one achieves async calls to the

    business components, does this mean that the identity

    of the requestor travels with the message or is it

    part of the context?

    This also plays into a bigger picture with regards to the topic I also touched on at exchange, and that is being s service as part of a series, all of which are async calls, and as such how do you then handle that, plus transactions, etc. This is certainly an area we need to build out further as it poses lots of interesting questions and challenges.