OERA from .Net?
Thu, 2008-10-09 19:52 — dlauzon
Hi,
I wonder if the .Net framework supported in the upcoming 10.2A already have classes defined to be just what we'd need for the OERA components (from the beta presentation site, .Net 3.0 and 3.5 seem to be supported)?
I know almost nothing about .Net, but there seems to be a large API with a well thought structure.
Since 10.2A will support ABL classes inheriting from .Net classes, we'll probably be able to override .Net component methods to use our own ABL implementation if needed, and in many cases, we'll probably don't even need to have an ABL implementation!
Anyone having any thoughts on this?
Can a .Net user confirm or not that there are components in .Net that matches those of OERA?
- Login to post comments
10.2A .NET GUI for ABL
The 10.2A GUI for ABL really has almost nothing to do with OERA. For one thing, the .NET capabilities in 10.2A are exclusively focused on UI. There is no intention yet to support the use of .NET components for messaging or other services. Secondly, I have some question about the desirability of using such components even if supported since it locks one into a Windows platform. It is one thing to decide to require Windows for the UI portion and quite another to require it for the Database and AppServer portions. Third, OERA as it exists doesn't actually define any components or framework. This project is an attempt to create *a* set of components which are OERA compliant and production quality, but there might be many such.
not 10.2 .Net GUI
It is true that you would probably have to run the ABL + .Net on a Windows machine unless Progress is compatible with the Mono Project that allows to run .Net on multiple platforms (http://www.mono-project.com/Main_Page).
"the .NET capabilities in 10.2A are exclusively focused on UI"
That's wrong. Although the focus is on the UI, 10.2A supports full access to the .Net framework library (most of which isn't GUI related), apart for some exceptions where the ABL doesn't support the related .Net concept (e.g. threads).
"ABL enhancements to support the Advanced GUI include:
Ability to instantiate and access .NET objects"
http://www.progress.com/openedge/beta/oe102a-beta/index.ssp
> That's wrong.
> That's wrong.
Err, are you in the beta program? The .NET GUI for ABL is just that. Data binding and business logic on the ABL side and UI on the CLR side. It is *not* a general purpose, use any .NET component implementation.
We'll see in a couple of weeks
I won't bypass the non-disclosure agreement, but let me quote again from the public beta web page:
Ability to instantiate and access .NET objects
We'll see in a couple of weeks/months, when 10.2A is publicly available.
simple no-.Net-UI .Net sample
Now that 10.2A is out, here's a simple .Net sample that uses no .Net UI:
MESSAGE System.DayOfWeek:Friday:CompareTo(System.DayOfWeek:Thursday) SKIP System.DayOfWeek:Thursday:CompareTo(System.DayOfWeek:Friday) SKIP System.DayOfWeek:Friday:CompareTo(System.DayOfWeek:Friday) SKIP VIEW-AS ALERT-BOX.The section "Supported features and limitations" of the manual "GUI for .Net Programming" does express some 4 pages of limitations in the marriage of ABL with .Net but, although Progress focused the marketing on the GUI part (as the name of the aforementioned manual implies...), you are pretty much free to use any .Net control available out there, including non-UI controls, i.e. the limitations aren't related to Progress trying to block non-UI .Net classes.
license prohibits non-UI use of the AVM to CLR Bridge
After verification, although it is technically feasible to use non-UI .Net classes, here's what the OpenEdge EULA states:
At this time, the allowable uses of the Bridge are restricted to developing or deploying Microsoft .NET Winforms User Interfaces for business applications using OpenEdge products, and for one-way usage of AVM calling the CLR (and not vice versa).
Any use of the Bridge other than as set forth in the previous paragraph is prohibited. Additionally, the Bridge may not be used for multi-threaded processes.
Progress Software reserves the right to modify the allowable uses listed above in future releases of OpenEdge products, as well as to modify the list of OpenEdge products that include the Bridge.
PSC Products that contain the AVM to CLR Bridge in this 10.2A release:
Development Products:
• OpenEdge Architect
• OpenEdge Studio
• 4GL Development System
Runtime Products:
• Client Networking
• WebClient
I'll log an enhancement request about this licensing limitation and ask that the AVM to .Net Bridge be also available on AppServer.
There has been a lively
There has been a lively discussion of this topic on the PSDN General Forum as well as the Beta forum. No immediate joy, but some clarification and explanation.
Enhancement request number is 3847
Enhancement request number is 3847, for those interested in voting for this enhancement.
Significant exceptions were
Significant exceptions were noted in beta.
significant toward non-ui classes?
And are those exceptions significant specifically for non-ui classes or are they significant also for ui classes?
For UI, the one really big
For UI, the one really big exception seemed to be .NET controls that use generics. That is definitely a future item. One also runs into issues with multi-threading .NET controls and single-threaded AVM. I don't recall the details of the specific non-UI controls that were tried, but I don't think it was either of those issues.
There is a discussion underway about the possibility of making the beta forum or at least parts of it public now that we have FCS. I hope this happens ... since I was the one who suggested it ... since there is a lot of trial and error and discovery recorded there. In the short beta period, it accumulated more posts than any other PSDN forum has accumulated in its entire life.
You have my vote for the publication of the beta forum
You have my vote for the publication of the beta forum!
Unfortunately, it isn't
Unfortunately, it isn't something I control. I suspect they are going to want to scrub it or something. Not clear at this point.
how do you propose using
how do you propose using .net to separate business logic and data access, and possibly data access into smaller reusable data sources ?
sure it has an extensive api, maybe we could use it's messaging services, the .net ui is a good valid option and many companies have been doing that for a long time.
but having the richest api, class framework or standard library etc. is the not the same thing as architecture and how to break down your application and what patterns to use. imho.
it reminds me when xml used to be the solution to everything :)
maybe the wheel already exists
OERA defines specific components or type of components (look at the tree structure of this project).
In another thread, someone said something similar to "hey, Rails already has something similiar to the OERA components, let's take their structure and port it to ABL" and you answered "Great Idea!".
What I'm saying is "hey, maybe .Net already has OERA components, maybe we could use them directly, since 10.2A allows to use and inherit from .Net classes".
E.g. what if .Net framework already has a class "SessionManagementService" that defines methods that one would expect from such a component?
What if there is already a .Net class "DataAccessComponent"?
Couldn't we have our ABL CLASS MyOrderDataAccessComponent INHERITS DotNet.DataAccessComponent ?
I'm searching right now about how to conform to SOA (that's what OERA is about, no?) with .Net and I'm finding multiple entries. My not so wild guess is that there are .Net components in the framework that implements and enforces a good architecture and patterns equivalent to OERA.
Great idea, no?
Early quotes from my search
Some quotes:
"In contrast, .NET is generally regarded as an easier environment to develop applications in, but it is not narrowly scoped, as is the case with the rebel frameworks, LAMP and [Ruby on Rails]."
"the investment and work Microsoft have put into building .NET as a framework for Web services and SOA"
http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1204143,0...
"ADO.NET is a set of classes that expose data access services for .NET Framework programmers. ADO.NET provides a rich set of components for creating distributed, data-sharing applications. It is an integral part of the .NET Framework"
http://msdn.microsoft.com/en-us/library/e80y5yhx.aspx
"The System.Data namespace provides access to classes that represent the ADO.NET architecture. ADO.NET lets you build components that efficiently manage data from multiple data sources. [...] The centerpiece of the ADO.NET architecture is the DataSet class. Each DataSet can contain multiple DataTable objects, with each DataTable containing data from a single data source, such as SQL Server."
http://msdn.microsoft.com/en-us/library/system.data.aspx
"System.ServiceModel"
"ChannelFactory Creates and manages the channels that are used by clients to send messages to service endpoints."
"ClientBase Provides the base implementation used to create Windows Communication Foundation (WCF) client objects that can call services."
"InstanceContext Represents the context information for a service instance."
"OperationContext Provides access to the execution context of a service method."
"ServiceHost Provides a host for services."
"ServiceHostBase Extends the ServiceHostBase class to implement hosts that expose custom programming models."
"ServiceSecurityContext Represents the security context of a remote party. On the client, represents the service identity and, on the service, represents the client identity."
http://msdn.microsoft.com/en-us/library/system.servicemodel.aspx
with respect in my opinion
with respect in my opinion language and architecture are for the most part two separate things.
the way i see it is we're not talking as much about which language and features to use but how to use them.
i think what we talked about in regards to rails was to take an example from rails not incorporate it with abl.
regards
Exactly, Rails was proposed
Exactly, Rails was proposed to be taken as an example, not incorporated, so I suppose that this would have included to take key Rails classes and implement them in ABL, no?
I'm proposing to take .Net as the example and as the implementation (at least in part).
With Rails, you would start with 0% implementation already done.