Reference Architecture Reactions - Forum - OpenEdge Architecture - Progress Community
 Forum

Reference Architecture Reactions

  • We've been talking and writing and presenting about the OpenEdge Reference Architecture for a couple of years now. Some partners are actively using (and varying) it as a basis for new or redesigned development, others still seem to see it as farther in the future for them or difficult to relate to their current situations and needs. For you who've seen and read some of the existing materials (see the PSDN topics under the Architecture -- and Implementing the OERA -- as part of the OpenEdge Principles materials here on PSDN), what ideas do you get from the materials? What issues does it raise? How do you or can you imagine making use of the concepts and possibly the samples? What kinds of directions would you like to see the discussion go in? Lots of questions, but let's get started talking about it...

  • I didnt get to attend any live show presentations but out of interest I read the documentation and whitepapers when they came out and tried to go through the presentation and web events.

    Truthly, I had a hard time with the documentation. Although I remember there was a paper on Distributed Applications and AppServers that was just beautiful.

    I see the point in separating physical storage from internal view and of course BL/UI but then there's the simplicty of writing web apps. Maybe if we had GUI it might be a more natural setup, maybe ?

    I'd love to see other people and IMO theres some very talented writers in the community write on the subject and offer maybe simpler and different ways of presenting the subject.

  • I John,

    My company and I have been early users of your new concept ADM2/SDO/Ntier a few years ago (2001).

    Our main software, ERP like, is completly constructed upon this technology and is pretty successful in our customer production sites.

    ADM2 tech have been successful in dev and project teams and on the customer side aswell.

    It has been successful in dev/project team, because it produce nice looking and practical screens and because it is a very powerful environment for designing db oriented apps.

    It has been successful on the customer side for roughly the same reasons, nice and pratical screens, and because their supplier (us) are able to take their change request without complaining.

    You may not see it but it has been for us a dramatic change in app design, giving us the ability to focus on other things than app design which is not our job.

    We really think that PSC had done a great job in providing us with this env.

    As a comparison, Java and .Net are far from the productivity that ADM2 provide us.

    Having said that, we are a little worried for the next dev env that you are providing.

    1) it is at present time not complete : no GUI, no decent GUI, it will be provided in 2007 AFAIK. This is really a big lack in your new env.

    2) it seems going toward the main current frameworks principles (Java and .Net) with OO Orientation, Services, Presentation (MVC), etc.

    This will make dev heavier.

    ADM2 had the great advantage of implementing Ntier easily without unneeded hassle. And giving Webclient and its automatic update deployment, what else ...

    3) in conclusion to point 2), the only competitive advantage for PSC will be it ease of use of its Data manipulation verbs and principles, easier than JDBC.

    The main points of concern are actually :

    - Providing us with a comprehensive dev env (with integrated and up to date GUI).

    - Making developpers work easier, up to the point that was reached with ADM2, with tight integration of the Modeler tool and the code generated, just like ADM2 as i said.

    What is said in this sentence may not seem harmful, but when you are a daily user of ADM2/v9, I can say it is a very high challenge in terms of productivity, maintanability and stability.

    Best regards

  • I've been wondering about the new GUI. Are we still on for late 2007, or somewhere in that area ?

    I know Bruce has moved on. He's the one that presented it at exchange and was, probably, very much involved with it. Though I don't know if he was an authority or something of the sort on the subject ?

    I'd love to hear more about whats planned for the new GUI, especially, if it will have a resizing scheme ?! which I think would be a serious mistake not to include or at the very least leave room for it in the future.

    I've done lots of work with resizable layouts in the past and of course theres more then a few frameworks around.

    It'll be interesting to see them incorporate ActiveX controls, or even better a GUI only framework, even though its a dying technology. Just a thought.

  • Hi Alon

    Your response raises a couple of questions to me Firstly you comment on having a hard time with the documentation, may I ask to which documentation your referring to in particular? Obviously one of our aims is to make the material we're producing as readable as possible.

    My second question relates to simplicity. In your opinion do you think that concepts such as the OERA and the subsequent implementation samples we've produced are too complex? One concept we've been thinking about internally is possibly putting together some more simple OERA based examples. So I'd be interested to hear if you think there is a pent up need for such work!

    Thanks for the feedback

    Mike

  • First of, alot of people I know are not just new to OERA and Datasets, even AppServers are new.

    So it maybe alot to take in.

    Maybe, for me, the n-tier poster is too abstract. OK, it fits everything but its hard to associate what goes where.

    From what I pieced together thinking about it.

    In a rich client setup, it largely divides into client/service the UI and context management goes into the client and the service is stateless.

    And because its a very scalable model.

    Datasets are mainly used to pass complex data structures back and forth and theres the proxy and gateway thing.

    And to simplify saving/getting data from/to internal view and physical storage.

    I read the whitepapers a while ago (not the first version) and the web events and presentations, not the 10.1a docs.

    It had alot of detail but I didn't get the big picture.

    But then again it was sometime ago, I'll try going over the 10.1a docs this week, maybe it'll look different this time.

    English isn't my native language though I don't think the docs ever had a problem in that area. Besides don't take me too seriously

  • For the questions regarding the New User Interface ...

    I've been wondering about the new GUI. Are we still on for late 2007, or somewhere in that area ?

    Yes, that is still our target!

    I'd love to hear more about whats planned for the new GUI, especially, if it will have a resizing scheme ?! which I think would be a serious mistake not to include or at the very least leave room for it in the future.

    If you have not already, please check the presentation INNOV-14 from Exchange 2006. In addition if you could not go to Las Vegas, please plan to attend PTW and INNOV-14, which includes a couple of demos. The session will have additional information and Q&A, of course.

    ...Resizable layouts:

    Yes, that should be possible.

    It'll be interesting to see them incorporate ActiveX controls, or even better a GUI only framework, even though its a dying technology. Just a thought.

    We are planning ot include everything you may need in-the-box (OpenEdge Architect), including controls. Possibly with popular third party controls as well. I cannot say much else now, we are negotiating with vendors.

    Message was edited by: Salvador

    Typo:

    "...please check the presentation INNOV-14 from Exchange 2005 ..." should read "...Exchange 2006"

  • I had a quick read through the 10.1a Getting Started: OpenEdge Reference Architecture doc.

    It was surprisingly good, I could relate to the ideas right away. Exactly the overview I was looking for !

    Thanks

  • That's very exciting to hear, all the work being done around UI's !

  • There is so much to say about the ideas raised in this thread that I'm not sure where to start! This is a great conversation to keep going and very helpful to what we are thinking about.

    In general, the theme seems to be about productivity and any advantages that we can bring in that area. I would agree with Alon that productivity has, in large part, been elusive over the last few years. It is not that we've taken anything away, it is simply that the environmental expectations have become more complex. OERA is certainly not as productive as the old "FOR EACH..." that made us famous. And, in present form, it is not as easy as ADM2. Basically, that's becaue we have had to sacrifice, at least temporarily, some productivity to gain flexibility. ADM2 made it easy to get across the client/server bridge, but the ADM2 objects do not work with alternative user interfaces and alternative service-based access methods. We needed something more flexible. ProDataSets will form the backbone of that flexibility, in that they handle complex datasets quite well, regardless of the intended exposure targets and/or the intended storage requirements. If all you want to do is store things in an OpenEdge database that exactly reflects the logical data structure, and expose them through only an OpenEdge user interface, then they are perhaps overkill - particularly if your integration requirements are few. But I would maintain that time and growing flexibility demands will show that having a flexible data manipulation and marshalling object between storage, logic, and logic exposure will prove very valuable. And having a SOA-based architecture will make it easier to adapt to those changing requirements. But, if you don't need that, we'll still support the "FOR EACH..." and ADM constructs.

    Back to productivity: There was a time when productivity was expressed entirely in the language. It would be nice to return completely to that, but I'm not sure that today's application environments will allow it. Going forward, we see it as a combination of advanced language features, good templates and examples, and advanced toolsets. I can envision UI and BL layout tools that automatically generate the necessary interface points (including ProDataSets). I can also envision tools that automatically expose business logic (including ProDataSets) whenever you need to create a new user or integration interface.

    Obviously, we don't have all those language features and tools. Yet. That's one of the ideas behind OERA and PSDN. We hope to use these vehicles to help fill in the gaps for work not yet completed, and we hope to gain some beneficial experiences from all of you that will make the eventual tools and features that much stronger. In fact, it is working already. We've made some adjustments to the ProDataSet roadmap based on things learned through PSDN and the community.

    As to our competitors, I think that Microsoft has a similar vision - provide the basic capabilities in the language and layer it with tools and metadata. But our language is already richer with a more native understanding of data, and we think that we can outgun them on this, even if we can't match their marketing budget. As to Java, the community as a whole still doesn't seem to understand the productivity thing, although there are some that are waking up to it slowly. So keep in mind that we're keeping one eye firmly on the characteristics of what has made us successful for all these years, and one eye firmly on where the market is going.

    One last note and I'll let you get on with more important reading. We are still working on the new UI, and it is designed to incorporate many of the ideas I've expressed above. I don't want to commit to a release date in this forum, but we'll get it to you as fast as we can - it is our number one priority for the next full release.

  • This is a very interesting and useful discussion. As already highlighted in the other responses developing modern Service Orientated Business Applications (SOBA) is much more complex and the challenge going forward is to provide the same productivity tools for building a SOBA as has been possible with traditional architectures.

    We would love to here some ideas from anybody making the transition to SOBA on how you envision tools helping in the future. How do you think differently when building a SOBA and how could the tools assist with this? What are the typical steps you have to take to build a SOBA and how would you like to see tools working together to automate this as much as possible.

    This is an area we are focusing a lot of research on at Progress and any input would be very timeley and greatly appreciated.

    We have layed a very solid foundation for future tools with OpenEdge Architect (based on Eclipse) which was released as part of OpenEdge 10.1A. This was however just the beginning and the true value will only be realized once we start delivering additional development tools targetted specifically at SOBA and conforming to the guidelines of the OpenEdge Reference Architecture (OERA).

    TIA

    Anthony

  • We would love to here some ideas from anybody making

    the transition to SOBA on how you envision tools

    helping in the future. How do you think differently

    when building a SOBA and how could the tools assist

    with this? What are the typical steps you have to

    take to build a SOBA and how would you like to see

    tools working together to automate this as much as

    possible.

    What about a "workflow designer" to design the "business services"? From this design the necessary client and server code that implements the service will be automatically generated. The implementation must adhere to "web services standards" (WDSL,SOAP,UDDI,WS-*). The design and development will be separated. Not necessary to "code-first".

    I am not looking for a ESB solution that is primarily focused on integrating different applications. Although I think the "business services/process modeling tools" from the ESB tools (integration) will tend to move towards application development - I think you should work from the business processes towards the implementation and not the other way around. I think we should look for an application workflow engine that can be used to define the business services (external/interface) but also the more fine-grained components within the actual service implementation itself (internal/implementation).

  • What about a "workflow designer" to design the

    "business services"? From this design the necessary

    client and server code that implements the service

    will be automatically generated. The implementation

    must adhere to "web services standards"

    (WDSL,SOAP,UDDI,WS-*). The design and development

    will be separated. Not necessary to "code-first".

    I am not looking for a ESB solution that is primarily

    focused on integrating different applications.

    Although I think the "business services/process

    modeling tools" from the ESB tools (integration) will

    tend to move towards application development - I

    think you should work from the business processes

    towards the implementation and not the other way

    around. I think we should look for an application

    workflow engine that can be used to define the

    business services (external/interface) but also the

    more fine-grained components within the actual

    service implementation itself

    (internal/implementation).

    The concept of looking at applications from a business process point of view, as opposed to starting from the database up, is something that we have been talking about for the past few years, even more so since the introduction of the OERA. So yes I think we agree, you really need to look at application development differently than you did a few years ago, and obviously this ultimately means you need tools to support that development paradigm. I'm not in engineering so I can't make tools promises, so I'll leave Ant and others to comment on how we may help from a product direction, but I think it's safe to say that you just can't sit at a keyboard and start coding these days, you need to think about processes, design and architecture way before you even sit at a keyboard

  • The concept of looking at applications from a

    business process point of view, as opposed to

    starting from the database up, is something that we

    have been talking about for the past few years

    True, we have been talking about this for years...

    Although it could work for some type of applications, I think creating (business/web) services from source code implementation just does not work.

    The business services should be designed by the "business consultant" not the developer (and the tools should make this possible).

    The service implementation should be generated from the business service definition. You shouldn't have to code the business entity/task/workflow layer + servicing layer by hand (although there are some UML based / repository based initiatives).

    Shouldn't PSC look at the Sonic platform (Orchestration Server) just like Microsoft is incorporating Windows Workflow Foundation into the Visual Studio development environment (pulling the programming model/application workflow engine from MS BizTalk which will remain their main "integration" product)?

  • True, we have been talking about this for years...

    Although it could work for some type of applications,

    I think creating (business/web) services from source

    code implementation just does not work.

    The business services should be designed by the

    "business consultant" not the developer (and the

    tools should make this possible).

    I think the key thing is that the Business Process should be designed, whether that is by a 'business analyst' or whoever, the critical point is that they have the business knowledge/domain knowledge and can express the processes in an understandable way, preferably using some form of standard notation.

    Shouldn't PSC look at the Sonic platform

    (Orchestration Server) just like Microsoft is

    incorporating Windows Workflow Foundation into the

    Visual Studio development environment (pulling the

    programming model/application workflow engine from MS

    BizTalk which will remain their main "integration"

    product)?

    Whether Sonic Orchestration Server would be the right approach, or not, your point is well taken that it would be great if such capabilities were in the product. So if we all keep our fingers crossed who knows what the future will bring !!