1 / 40

.NET for Everyone

.NET for Everyone. Peter van Dam pvd@netsetup.nl. PUG Norway - Lillehammer 2005. Why a .NET client?. Support more client types (PocketPC, SmartPhone, Linux) Easier to sell: Eliminate ‘Progress who?’ .NET framework already available on client Sell to Microsoft-only organizations

taya
Download Presentation

.NET for Everyone

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. .NET for Everyone Peter van Dam pvd@netsetup.nl PUG Norway - Lillehammer 2005

  2. Why a .NET client? • Support more client types (PocketPC, SmartPhone, Linux) • Easier to sell: • Eliminate ‘Progress who?’ • .NET framework already available on client • Sell to Microsoft-only organizations • Superior Windows user interface • Integration with Microsoft desktop

  3. Downsides of .NET • No strong server-side offering • Low level 3GL language • Low productivity for Business Logic • High roundtrip time (+3 seconds over internet) • Limited scalability

  4. Why Progress? • Best 4GL for business logic • Superior AppServer technology • Better scalability • Multiple database support • Multiple OS support

  5. Best of Both Worlds • Progress on the Server • .NET on the Client Internet Internet Internet Internet .NET Progress or or or or Application data Application data Intranet Intranet Intranet Intranet

  6. The Project Started with the OE 10 Beta program in August 2003 Partnered with a company that had some C++ and Java experience but no .Net experience Netsetup provided the server framework (DWP) Subsidized by the Dutch government (WSBO)

  7. Internet orIntranet WebClient over inter/intranet AppServer AIA DB

  8. The DWP API getscreen.p Repository ui.p Application data Dynamic client Application data update.p Appserver boundary

  9. Internet orIntranet The ultimate goal:.Net over Inter/intranet AppServer AIA .NETproxy DB

  10. The OE 10 Open Client Toolkit There were many problems with the .NET proxy during the beta Therefore we started with a Web Services approach The .NET proxy problems were eventually fixed in OE 10.0A SP1 However, the .NET proxy did not run with AIA until OE 10.0B ProDataSet was not mature until OE 10.0B

  11. .NET communication ProxyGen generates an <application>.dll file This is a so-called .NET assembly (compiled library) It enables the .NET program to communicate with the Progress AppServer The data traffic is exactly the same as native Progress

  12. Creating the .NET client Choose a .NET language C# seems to be the most logical choice because it is created for .NET If necessary, customers can create additional client-side code in different languages (i.e. Visual Basic .NET)

  13. Connecting to the AppServer The .NET client connects to the Progress AppServer using the Connection and Application objects supplied in the proxy You connect justlike in Progress by supplying a URL, userid, passwordand extra info

  14. Connecting to the AppServer If the connect succeeds, the proxy remembers the connection state and you can call the Application objects Just like in Progress, it is a problem to determine if the authentication failed or there is another problem with the connection

  15. Regional settings PROGRESS programmers are used to dictating the date and numeric format to users (by specifying –d or DATE-FORMAT and –E or NUMERIC-FORMAT) for the client In the Windows world, the user is in charge of this The .NET client should use the user’s Regional settings

  16. Regional settings

  17. Representing dates Our .NET client uses the Short date format from the user’s Regional Settings The developer must allow for the maximum possible size of date fields In addition we represent each date field with a date picker in update mode

  18. Representing Integers Integers are represented using the Regional Options Number settings This means that the Progress FORMAT is not used As a matter of fact the Progress FORMAT is not even available on the client And if you would make it available on the client, it would not make sense to .NET Therefore we must store the .NET format in the repository

  19. Representing Decimals In Regional settings the Number format applies both to Integers and Decimals In addition to that a Currency format is defined as well In Progress we cannot distinguish between Decimals and Currency We display all Decimals according to the Number format We use the Progress FORMAT to find out the number of decimals to display

  20. Sizing a field How do we determine the size of a field? We do not have the Progress FORMAT and if we had it we could not interpret it in C# We solved this issue temporarily by passing the BUFFER-FIELD:WIDTH property to the .NET client But the Progress width does not necessarily make sense in .NET

  21. Showing field data In Windows, a disabled field is always grayed out We know that problem from COMBO-BOXES, RADIO-SETS and TOGGLE-BOXES in the 4GL We solved it in C# by making the fields Enabled and ReadOnly Added bonus is that you can also copy field data

  22. Parsing VIEW-AS Our own C# Widget Factory parses the Progress VIEW-AS phrase This is how the C# client knows when to create a COMBO-BOX, RADIO-SET etc. We try to interpret the VIEW-AS phrase as good as possible Example: LIST-ITEM-PAIRS It would be better to store .NET formatting information in the repository as well

  23. ? The Unknown value (1) .NET has no concept of the Progress unknown value in variables The Progress unknown value maps to DBnull All .net code will generate errors if a variable contains DBnull somewhere Therefore you have to check for Dbnull everywhere in your code

  24. ? The Unknown value (2) You can also have Proxygen map these variables to special ‘holder’ classes (e.g. IntHolder instead of int) These are Progress supplied classes that can also hold unknown values The code is more verbose and less standard if you use these Try to avoid using the unknown value in your interface if you can

  25. Web Service or .NET Progress proxy? Which communication method are we going to choose? The Web Service approach creates a lot of overhead but became available in 9.1D02+ .NET Proxygen was not available until Open Edge 10 This had some impact on the development of the C# rendering program

  26. Internet orIntranet Web Service approach WSA AppServer DB .wsdl .wsm

  27. Web Service approach .NET natively supports Web Services ProxyGen generates a .wsdl file and a .wsm file The WSDL file describes the Web Service (API and location) The .wsm file is needed to deploy the Web Service Communication is standard XML over HTTP/S ProDataSet not supported

  28. Drawback of Web Services A Web Service is not very efficient for this purpose because it has too much overhead AppServer calls are converted to XML and wrapped in SOAP messages SOAP imposes severe limitation on the characters used (e.g. CHR(1)) Web Services are ideal for occasional inter-application communication Not ideal for running a single application over the internet

  29. The .NET proxy in OE 10.0A After the introduction of OE 10.0A SP1 we switched from Web Services to a .net proxy (regrettably not yet with AIA) AppServer .NETproxy DB

  30. uihooks.cs Internet orIntranet Code Hooks blhooks.p Repository ui.cs bl.p Application data Application data

  31. Demo: client hooks

  32. Demo

  33. After one year… Results were unsatisfactory We had wasted a lot of time on technical issues, including initial OpenEdge bugs Project progressed too slow Many communication problems between .NET and Progress people Not enough commitment from our partner No .NET added value from our partner We decided to start over

  34. Lessons learned Proof of concept delivered It is very risky to be the first one to use new technology .NET experience essential 100% commitment essential Much more detailed specifications needed Do not try to make a 1:1 mapping from Progress UI to .NET

  35. October 2004: A new start Experienced .NET partner selected OpenEdge is now mature (.NET proxies via HTTP, ProDataSet including update) Take advantage of ProDataSet Much more detailed specifications needed Pay more attention to .NET user interface DWP modifications needed Create test set during design stage

  36. Grids .NET 1.1 has a basic grid It has more capabilities than the Progress browse but is pretty basic The Infragistics grid is very popular in the Progress .NET community .NET 2.0 will offer a much better grid

  37. Example Infragistics grid

  38. Current project status Already 100% over schedule (second time) You cannot plan a research project Even with our previous experience, a stable architecture and very detailed specifications There is a lot of communication and translation needed to bridge the gap between Progress 4GL and C# First pilot projects will start this Summer

  39. Question time

  40. THANK YOU FOR YOUR TIME! More information: • www.dynamicwebclient.com • www.netsetup.nl • dwp@peg.com (peg email group)

More Related