OpenEdge Perspective

Lions and Tigers and Bears... Oh My!

2008-07-01T13:36:57-07:00

I'm back from Exchange and vacation and I would like to share some of the questions (and concerns) I heard regarding the Advanced GUI. First and foremost, let's get talk about a new name. It was announced at Exchange that the new names are OpenEdge GUI for .NET and OpenEdge Ultra Controls for .NET. I like these names as they convey exactly what the feature and product is.

Exchange was a great experience for me this year since this year is the culmination of all of the hard work we've been doing to natively integrate a .NET user interface into OpenEdge. I was at both Exchange workshops and sessions for the "Advanced GUI" - presenter of "A Deep Dive into the Advanced GUI". The interest was gratifying for me and most everyone was excited with the feature. I got a lot of accolades. But the looming question in everyone's mind was how hard is this going to be for me . I have a few comments on this.

GUI programming is GUI programming. An application gets into a wait state and an event loop takes over any processing. GUIs can be well architected or not. This remains true with .NET.

The OpenEdge GUI for .NET can easily be compared with the current OpenEdge GUI and there are a lot of similarities. I gave out a 2-page handout at Exchange on this topic. The following is an excerpt:

DEFINE VAR

C-Win

WIDGET-HANDLE.

CREATE WINDOW C-Win ASSIGN …

DEFINE VAR custForm AS CLASS CustomerForm.

custForm = NEW CustomerForm( ).

DEFINE QUERY CustQry FOR Customer SCROLLING.

…

DEFINE QUERY custQry FOR Customer SCROLLING.

…

DEFINE VAR custSource AS Progress.Data.BindingSource.

custSrc = NEW Progress.Data.BindingSource ( custQry ).

DEFINE BROWSE CustBrowse QUERY CustQry …

DEFINE VAR custGrid AS Infragistics...UltraGrid.

custGrid = NEW Infragistrics…UltraGrid( ).

custGrid:DataSource = custSrc.

DEFINE FRAME Default-Frame CustBrowse …

ENABLE CustBrowse WITH FRAME Default-Frame IN WINDOW C-Win.

InitializeComponents( ):

Controls:Add( custGrid ).

…

(controls enables by default)

VIEW C-Win.

custForm:Show( ).

WAIT-FOR CLOSE OF THIS-PROCEDURE.

WAIT-FOR Application:Run( custForm ).

While it might take some getting used to the syntax to create and access .NET controls, it is not that hard and as you can see often a one-to-one mapping. The complexity of OOABL comes with using inheritance, interfaces and polymorphism. Getting started with the OpenEdge GUI for .NET generally does not require the use of any of these concepts except within generated code from the Visual Designer. It's good to have some of the hard work done for you!

The challenge really comes in with using the extensive features provided by the .NET controls. There are common properties, methods and events that will easily become second nature. The more specific, custom behavior of each control is more difficult to navigate. To help with this learning we are translating the samples that come with the Infragistics controls from C# to ABL. These demonstrate a large amount of custom behavior of the controls. These samples will be available with the FCS of 10.2A.

I have seen a growing beta participant list for 10.2A which is very exciting. So get out there and catch the wave! I'll try to keep back the lions.

-Shelley

Ajax in Perspective

2008-06-26T15:22:44-07:00

Don’t get me wrong. I am a big fan of Ajax. In fact I spoke on Ajax at the Progress Exchange conferences in 2006 and 2007, and was very excited to see that several customers were speaking at Exchange 2008 on how to use Ajax with OpenEdge. However, given all of the hype around Ajax, I was surprised to see a recent Forrester Research report, reported on by ComputerWorld, that Ajax is not exactly living up to expectations.

You see conventional wisdom would say that with Ajax, we have finally solved the rich vs. reach problem. No longer do we need to decide if we want our applications to give users a rich dynamic experience that is tightly integrated with the desktop like a traditional desktop application, or do we want to allow our users to have access to our application where ever they are without installing anything by building a Web (browser)-based application.

With Ajax I apparently get the best of both worlds. All I need to do is pick an Ajax library is write a little bit of Javascript code or better yet use a open source Javascript library like Dojo, Prototype, ExtJS, or script.aculo.us, to simplify the development process, and presto, I now have a rich user interface running in the browser just like it runs on a desktop.

And while that certainly would be great, according to Forrester, apparently things aren’t as simple as that. According to the Forrester report while Ajax is great for the “occasional user” or the “very infrequent user”, for the “power user”, that is the user that is using the application for a significant part of the day to do their job, Ajax just isn’t holding up.

You can read the Forrester report, or the ComputerWorld article yourself to get all the details, but suffice it to say that the reasons why Ajax is not holding up is centered around rendering performance when building complex screens, and network performance because most Ajax tend to go to the server to do validation much more than they do in a desktop-based client-server application. And while many of the Ajax libraries do a pretty good job of hiding differences across the latest versions of the most popular browsers, the problem is not completely solved because many IT organizations use several versions of many different types of browsers and incompatibilities still do exist even with the latest versions.

So, what does this all mean? Should you stay away from Ajax? Of course not. What it does mean, however, as Salvador Vinals points out in his post in the Progress SaaS blog, and as is discussed in the Forrester report, is that you need to pick the UI technology that meets the needs of the end-user, and if your application has multiple different types of end-users with different usage patterns, then it may be highly appropriate to support more than one type of UI.

So if you have occasional users or infrequent users, users that move around a lot, and need to be able to get to the application from where ever they are then you certainly should consider building a Web UI and using Ajax to get a richer experience. I certainly would encourage it.

However, if your users are power users using a complex UI and primarily using the application from one location, then using one of the more traditional desktop UI technologies may be more appropriate.

And because we know that needs of the users and UI technologies change fairly frequently, one of the most important things you can do is architect your application based on the principles and guidelines of the OpenEdge Reference Architecture so that you can more easily change your UI or support multiple UIs when the need arises.

OpenEdge 10.2A Beta

2008-06-23T13:08:58-07:00

The OpenEdge 10.2A Beta website is now open for those customers wishing to register for the beta program. The beta program is scheduled to run from 14 July through 1 December, 2008.

The focal point of OpenEdge 10.2A is commercialization of the OpenEdge Advanced GUI. In addition, OpenEdge 10.2A includes enhancements to OpenEdge DataServers and improved interoperability with SonicMQ, as well as support for Windows 64-bit.

As a beta program member you will be amongst the first to test-drive this important software release prior to its commercial availability. Not only does this gives you an early opportunity to see how the new capabilities provided by this release might fight into your product strategy, but you also provide a valuable service by helping to ensure the overall quality and functional completeness of the features provided with this release.

I therefore encourage as many members of the Progress community as possible to register for the Beta program.

Ken

Exchange 2008 Thank You!!

2008-06-23T11:47:43-07:00

With Exchange now more than a week behind us and most of us now back are at our “day” jobs, I would like to take this opportunity to thank all of you for a great conference. With over 800 attendees learning and sharing in more than 110 sessions and 3 pre-conference workshops the conference was a resounding success.

However, it wasn’t just the formal part of the conference that you folks came for. There were also numerous networking events including the Sunday evening Poster Fair, and the Expo’s on Monday and Tuesday, where you met with other customers and with Progress employees in a more informal setting, and where you could see demonstrations of the various Progress products as well as products offered by various Progress partners.

One of the areas where there was a lot of interest was the OpenEdge Advanced GUI, our brand new Microsoft .NET-based UI technology to be released in the fall as part of OpenEdge 10.2A. The morning workshop on the Advanced GUI was extremely well attended, and the afternoon one was sold-out.

Additionally, the 4 breakout sessions on the Advanced GUI were in high demand and I think it is fair to say that the demo performed by Shelley Chase and Peter Judge where they demonstrated some of the more advanced capabilities of the Advanced GUI was one of the highlights of the conference.

But there were many other great sessions during the conference including sessions on the newest capabilities in OpenEdge Architect, ABL object-oriented extensions, database administration, and using OpenEdge Adapter for Sonic ESB native invocation mechanism. This new way of using the adapter really simplifies the development process when using OpenEdge and Sonic together. There were also session on using AJAX and other Web 2.0 technologies with OpenEdge. And, of course, there were a number of sessions which provided you with use cases and deep insight to all of the products that make up the Progress SOA Portfolio.

Certainly, one area that got a lot of attention was the structured error handling sessions where over 200 people attended the 2 sessions that were presented. Both sessions did a great job of showing not only the basic capabilities, but also showed you how you can migrate your existing application to use this new capability in an incremental fashion without breaking your existing code.

And I certainly would be remiss if I didn’t mention one of my own session, the OpenEdge Roadmap and Strategy session that I presented with Salvador Vinals, where over 170 attendees where brought up to date on what are some of the latest capabilities that you can find in OpenEdge, and got some insight into what are some of the things we are planning for a future release.

So if you went to this year’s Exchange, we thank you. If you missed this year’s Exchange, or just want to take another look at the slides for a session you attended, or maybe one you missed, you can find copies of all of the presentations on the Exchange download site or on PSDN. And, checkout the Exchange Virtual Expo, an on-line version of the exhibit hall where you can get detailed information on all the vendors that demonstrated their products and services at the Expo.

In any case, we look forward to seeing at next year’s Exchange, which will be held in New Orleans. If you have ideas for the kinds of sessions and workshops you would like to see at next year’s conference, please submit them to the Exchange Forum and in the interim, consider attending a regional event especially if you weren’t able to make this year’s Exchange.

PSDN Live will be held in Boston from September 7-9, PTW Asia Pacific will be held in Queensland, Australia from August 17-19, and PTW Mexico will be held October 9th with other regional events still being planned.

Thank you.

Ken

OpenEdge and the Not-Quite-Accidental Architecture

2008-06-18T14:26:35-07:00

We’ve been talking for a long time now about the OpenEdge Reference Architecture (see a host of definitional and example materials at www.psdn.com under the new Service Oriented Business Application Expertise Center). The OERA is the diagram with the layers from Presentation and Enterprise at the top down through Business Components and Data Access to Data Sources at the bottom. A lot of people at Exchange and elsewhere where we’ve had a chance to connect in person find the discussion stimulating but intimidating. “Thanks for the presentation. I see now how complicated this architecture stuff is now.” Hmmm. That wasn’t exactly the message we were trying to convey. It’s understandable how the layers make it seem like it is going to be harder to implement a well-architected service-oriented application, but the intention is just the opposite: to help you make it easier, not harder, to get your application to where it needs to be for all that loosely-coupled agility that you know you need.

So how does it wind up being easier? I have a couple of simple principles I have been trying to get across in more recent materials:

1. Let each component of your application (a procedure or a class, whatever) do just one job and one type of job.

How many procedures in your application are there that do a whole application operation from soup to nuts, as it were, from user interface to business logic to database transactions? If you can break those up into pieces that do one type of job – user interface, business rules, mapping to database tables, or database transaction – then you’re well on your way to having components you can reuse when you need them, rather than copying and pasting old code into new places and then changing it to suit new circumstances.

2. Do each job once and only once.

And how does this wind up making your development job easier?
Well, how many places are there in your application where the code… – fill in the blank here with your own list of completions to the question: calculates a price, validates the correctness of an order, checks a user ID for access to an application module, joins six related tables in the database, whatever. If you can factor out redundant or similar code for any of these kinds of activities, you’ve certainly simplified your maintenance and testing job, and probably made it simpler to do a related version of the same job the next time you have to.

And where does the not-quite-accidental part of the architecture come in? One of the key messages we could do a better job of communicating is that you don’t have to tackle the whole job at once: the OERA represents a set of guidelines and ideal goals, not an absolute all-or-nothing necessity. So if you think in terms of making your application structure a little bit better each time you change it rather than a little bit worse, then you’re headed in the right direction. And you’ll see that starting in on principle #1 is really a prerequisite to principle #2. If you start breaking out chunks of code based on what one job they do, then it will be much easier to reuse them. Take all those price calculations; factor out the common code and parameterize the variations; create a straightforward API that lets another part of the app call in with needed inputs and get back needed outputs; and eliminate assumptions in the code about the nature of the caller; and voila! – pretty soon you’ve got a Business Component with a Service Interface (that’s the common API part) on the front of it. At that point OpenEdge makes it easy to call that Business Component through the Service Interface from all over, including from other applications and new user interfaces.

Find all the places where your code checks a user ID against permissions on an application module; move them into a single procedure that does that job and call it wherever it’s needed; and voila! – you’ve got the beginnings of Common Infrastructure. So you don’t need to solve the whole problem at once. Just head in a direction that makes it easier for you to identify what all the bits and pieces do, and sooner or later you’ll have an application code that has got a real architecture to it. And think how much easier that will make your life in a world of new UIs and Web services and all the rest of what you have to deal with. Follow the right principles and – not quite accidentally, but pretty close – your application will start to have an architecture after all.

Business-orientation and object-orientation

2008-06-04T07:47:19-07:00

With enhancements in the OpenEdge 10.1x release family, ABL (Advanced Business Language) is being extended with standard formal object-oriented (OO) functionality: objects, classes, methods, polymorphism, inheritance, delegation, statics, properties, strong typing, and more.

A big differentiator from other traditional object-oriented Languages is that ABL does not exclude other programming methodologies though: ABL is not “pure OO”, and at Progress we think that is a good thing for our customers!. With ABL, developers can combine and integrate classes with procedures and vice versa. As a matter of fact ABL is the only business application's development language with this capability!

In addition, ABL’s unique and powerful built-in data awareness further differentiate it from the rest of mainstream development languages. Again, ABL is the only business application’s development language that provides uniform and comprehensive built-in capabilities to access, manipulate and store data from different data sources and formats (including relational databases, XML, structured and unstructured files, user-defined formats, etc.) intertwining it with sophisticated business logic, making ABL particularly suited for world-class business applications.

The requirements of modern business applications for modularity, open access and reusability through disparate interfaces have never been higher. The object-oriented extensions ease the implementation of robust business applications that adhere to SOA principles, and integrate with other systems, platforms and applications --- including non-OpenEdge ones of course --- in today’s interconnected and heterogeneous business environment, thus furthering our commitment to openness.

Where encapsulated, modular, reusable functionality is required, developers can build on the inherent capabilities provided by ABL’s formal object-orientation. Where tasks, workflows or processes are needed they can take advantage of its continued support for procedural development methodologies.

We are very excited to hear from customers using ABL object-oriented extensions (OOABL for short) reporting that they are indeed helping them simplify their Service-Oriented Business Applications, and in some cases make their code up to 40% smaller --- your mileage may vary ---, with less integration points which makes the code more uniform and easier to reuse.

I encourage everyone to take a look at the OOABL extensions. Even if you are not familiar with object-orientation I think you’ll be pleasantly surprised with their ease of use and you’ll be able to quickly realize development productivity benefits, and will make your applications even more robust. And remember, you can adopt and use them at your own pace alongside or integrated with procedural methodologies. And stay tuned, there’s much, much more to come!

Balancing relational data with an object-oriented approach to managing it

2008-04-29T14:03:23-07:00

One of the major new areas in OpenEdge 10 is the language support for classes. ABL now lets you define source files as classes, as an alternative to procedures, to take advantage of many valuable object-oriented features established by languages like Java and C#, including inheritance and strong-typing of object references. One major pragmatic value of this new direction is the greater ability it gives you to define within your source code just exactly what things refer to and how different classes are related, so that the compiler can cross-check your references and give you much more feedback on your code's correctness at compile time, rather than waiting until runtime to see whether you've defined all the pieces correctly. So rather than defining a reference to a procedure as a handle variable that could point to anything at all at runtime, you define the variable as a reference to a specific class, and by gosh, the compiler will make sure that every reference to a property or method of that class is correct, and that you don't use that variable to reference anything else. This is a clear advantage to developers, and has little to do with any need for a deep understanding of object orientation.

So far, so good. But one of the major benefits of using ABL as a high-level programming language, as distinct from Java or C#, is the tight integration into the language of business logic that knows how to deal with relational data (and after all, most of the data managed by a business application written in any language is still relational), and that knows the details of the data's schema and lets you program accordingly. This is the key to the value of ABL, and goes all the way back to the language's FOR EACH Customer: DISPLAY Customer beginnings. In today's ABL we support the same kind of data manipulation, whether it's against the physical data schema (the database) or the logical schema of an application (temp-tables and ProDataSets).

This combination of support for classes with its object-oriented approach to code design, juxtaposed with the still very relational view of the business data, poses some serious challenges. Should you now try to treat each data item (a customer, say) as a true object? Does a set of all the customers in Ohio now become a collection of objects, that is, independent running instances of an ABL .r file, each holding the data for a single customer? This kind of approach has been tried in at least a few cases, and seems to go very much against the grain of the relational advantage of being able to treat these customers as an organized table of information, and presents the potential for serious performance problems as well.

There has been work in some areas on balancing the usefulness of a relational table as a way to hold and access multiple objects (like customers in Ohio), while using a more object-oriented approach to represent a single customer object, as properties of a class. See for example this thread on the PSDN Principles and OERA Forum:

http://www.psdn.com/library/thread.jspa?threadID=7645&tstart=0

There is also the question of how to balance what we traditionally describe as 'static' references to tables and fields – taking advantage of the compiler's knowledge of database and temp-table definitions – with the more dynamic approach of using a reference to a set of data (a handle, in this case) as a way to access its tables and fields and values more indirectly, using syntax like httCustomer::CustName, for instance. The static approach requires, at this stage of the product's evolution, having all the table definitions coded (perhaps as include files) in every class or procedure that references them, which is not a very encapsulated, object-oriented way of constructing things. The dynamic approach sacrifices some of the simplicity of the traditional FOR EACH...WHERE coding style along with some of the ability to count on the compiler and other tools to make sure references are correct and efficient.

So in short, we find ourselves in a transition between a more or less strictly procedural way of dealing with more or less strictly relational data, and a much more object-oriented way of dealing with what is mostly that same data. The product itself is always evolving. Future language features and other enhancements, always influenced by the experiences and the requests of our customers, help bring us closer to an ideal of really simplifying the hard job of building successful business applications. Open discussions about best practices, that is, how to do the most effective job of using what the product provides at any given point in time, are also a key component of creating a common understanding of how best to proceed.

I won't attempt any definite answers here. That would turn a blog entry into a full-blown white paper. And the point is, the answers are still in flux, and not as definite as we all would like. But the topic is important, and needs everyone’s input and experiences. There have been a number of threads on the OpenEdge Principles Forum on one aspect or another of the issues around handling relational data as objects, and you should take a look at them. To stimulate a continuing discussion, I've started a thread for comments and discussions on the subject, with this entry as a starting point. Join in. We need the participation of the broader OpenEdge community to help us guide where we go from here with the product, as well as with the discussion of how best to use it and apply its distinct and still considerable value. Here's the link to the thread, just in case you don't yet know your way around the forums:

http://www.psdn.com/library/thread.jspa?threadID=9532

Hope to hear from you.

Eclipsecon 2008

2008-04-18T01:15:33-07:00

Last month, I had the pleasure of attending Eclipsecon 2008, Eclipse conference, in Santa Clara, CA. The conference was well attended with 1404 attendees representing 37 countries. There were 10 parallel tracks and with a wide range of sessions from “Getting started” to “How to make money with Open Source”. In the past couple of years, the Eclipse ecosystem has grown rapidly with 11 top level projects that cover many of the areas of SDLC tooling. With the recent announcement of the Runtime (RT) project, they now have a significant traction on Rich UI client (using RCP technology), Rich Web UI (using RAP technology) and the application server areas with OSGi and “Server Side OSGi” projects.

The conference in general had a lot of buzz about web as a platform for Eclipse and AJAX tooling. I have attended Eclipsecon for the past three years and the previous conferences have been very technical with lot of sessions on “how to” in Eclipse where they would get into code within the first 10 min of the session. But I noticed a slight change in focus this year – there were a lot of success stories, reference implementations, adoption related sessions and many business focused sessions like “How to make money from open source”. In my opinion this change somewhat reflects the maturity process for the Eclipse ecosystem.

You can browse thru’ the conference materials at http://www.eclipsecon.org/2008. Happy reading!

So in summary, Eclipse has gained significant momentum and looking at the future direction of where Eclipse tooling is headed further strengthens OpenEdge Architect strategy of providing an open and productive tooling platform for OpenEdge customer base. The continued growth of Eclipse ecosystem will continue to enable OpenEdge customers to take advantage of the Eclipse platform and ecosystem.

One of the goals for OpenEdge Architect is to make OpenEdge n-tier business application development iterative and more productive. Looking at the different Eclipse projects, there seem to be definite synergies between Eclipse projects like Web Tools Project (WTP) for providing AppServer and Webspeed tooling support, Mylyn and the need for task based development environment, Dynamic language toolkit (DLTK) makes it relatively easy to add more editors feature quickly, Data tools project (DTP) for database schema navigation etc…. So we are looking to further prototype and explore of some of these Eclipse projects to meet OpenEdge customer needs.

Following is a brief summary of some of the sessions that I thought were interesting - more details about this can be found in the conference material on the link above.

1. Eclipse 4.0 (e4) – There was a lot of discussion about the next generation of Eclipse tools – Eclipse 4.0 (e4). E4 is expected to ship in June 2010 with a prototype ready by June 2009. Web as another platform for Eclipse and SWT was one of the main themes for Eclipse 4.0 platform team. The platform team had a few cool prototypes and demo on possibilities. Eclipse committee seems to be still undecided on the definite direction on how Eclipse will be available on Web. Some of the AJAX solutions that were being considered included RAP, GWT, DOJO library with Java compiled to JavaScript, Flex and Action Script, Silver Light etc…

2. Rich AJAXPlatform (RAP) – RAP technology is very promising and provides Rich UI on Web for applications that are built for desktop. The RAP platform takes an application that is built using RCP (Rich Client platform) and renders it on the Web – without many changes to the application source code – single source multiple platforms. RAP dynamically exchanges SWT widgets with RWT widgets that work in client-server distributed mode. Branding for the RAP based web UI provided by Themes.

3. Eclipse Dynamic Languages Toolkit (DLTK) – Very promising technology for adding new editor features to IDE’s. The DLTK relies on a standard “Structure Model” to provide functionality like outline view, search, open type, open declaration, documentation access, code completion. Internally DLTK has a selection engine that provides a lot of capabilities mentioned above.

4. Mylyn – The task based development paradigm promoted by Mylyn has lot of traction and I heard lot of developers starting to use it. The Eclipse 3.4 release seems to further add more stability and extensibility and a host of other SCM (software configuration management) tools are integrating their solutions with Mylyn.

5. Data Tools Project (DTP) – DTP functionality keeps getting better and better – they provide Data source configuration, navigation, SQL editor, SQL query builder etc... DTP’s real value is in its integration with other projects in the Eclipse ecosystem – like BIRT which makes the story very compelling.

6. Security in Eclipse 3.4 – The security improvements in Eclipse 3.4 are significant. Trusted bundles, ability to encrypt sensitive data in Eclipse workspace and Certificate store in RCP world are some of the enhancements to the Eclipse 3.4 release.

7. JMaki – This open source client-server AJAX framework is mainly driven by Sun and the Glassfish guys and conforms to Open AJAX standards. I was very impressed with the demo and it appeared to be very easy to build Mash-ups. This has Eclipse integration. This framework makes it easy to use most other AJAX toolkits (DOJO, etc…) and it acts as a standardized layer below the AJAX toolkits. More details at http://jmaki.com

About That Scalability ...

2008-04-17T12:10:00-07:00

Does scalability only apply to very large deployments ?

Try this, fold a piece of paper in half by bringing the top edge down to meet the bottom edge. Now imagine an OpenEdge application with a 20GB database that uses either wifi or cabled network to run a small business. Imagine the business system occupies that half-sheet of paper, uses 2 watts of power, weighs two pounds, and costs $400 US.

That's reality today. I bought one of those little Eee laptops recently, and was delighted at how easy the linux system is to use, and how easy it integrates with my Windows-dominated infrastructure. Nice job. Linux even runs my spreadsheets and presentations unchanged (you can even change the laptop to XP if you want). What a nice parallel this "mini-system flexibility" is to OpenEdge! The ability to scale down is partly one of architecture and partly discipline in the implementation.

But why scale down? One reason could be new products or new markets. Another reason is to focus on providing a consistent service at a high performance level. Have you seen applications that have just seemed to grow and grow. Application bloat leads to a loss of control over the key function of the software, and it seems that poor usability and uneven performance come right along for the ride. So maybe scaling down is another way at looking for clear boundaries between layers of an application as well as separation of functions in an application environment. That highly connectable 2 pound workstation was no accident! It was drawn from the OLPC (One Laptop Per Child) design effort which is spawning a lot of creativity in the Ultra-Mobile PC market. A solid software architecture has some similarities in terms of defined interfaces, guiding principles, and scalable design.

Does your application scale up? Or down? Or out? Sometimes a "readiness review" of your architecture from scalability or an service-oriented view can lead to a plan that leads into the business roadmap by opening up new options. We hope that the new capabilities in OpenEdge ABL can help you implement that roadmap in a smooth way that phases in the stages you plan for your evolution. Are you trying this approach? How well is this working for you? The AutoEdge application gives some nice examples of how the ABL supports the scalable OpenEdge Reference Architecture. I was just reviewing a presentation about AutoEdge that will be done for Exchange in Paris. If you are attending, this session could be very useful. Another interesting session shows a racetrack example which illustrates how a SOA environment comes together with Sonic, OpenEdge, and other fine products. Check them out and let me know what you think.

What about Deployment?

From the deployment side we still support efficient storage of data, so that 20GB database on the tiny laptop might hold a surprising amount of business data. we still support compatibility of the database from the little laptop up through large systems too. With OpenEdge 10.1B, every database can grow to have very large tables, wide indexes, and a full range of datatypes. You even get built-in management features like automatic defragging now. On a small database, it is easy to make it run "hands off". For large databases, you get on-line management of table space, schema additions, and the ability to increase some key performance parameters without taking downtime. OpenEdge needs less tuning than those big databases, and we are still the #1 pure-play database for applications that need a capable database "built right in". Our vision is to let your production environment evolve smoothly with a self-tuning, self-healing, and self-provisioning database that handles the transactional business load. What else? Well, improvements in appservers keep coming, as do improvements in the reporting capabilities of OpenEdge SQL. Similarly, support for Sonic keeps getting easier with 10.1C, and we'll talk about that in a separate note. We do take performance and manageability seriously, and the roadmap for this area really features a lot of customer-requested capabilities. We really appreciate your advice and insights into your needs. Please keep them coming! What are your top 5 needs in the database and appserver area?

Whatever happens in the scalability area, one thing remains. Scalability is not about standing still. It's about a dynamic range and that means opportunity for you and for us. Together.

Of OpenEdge, Toasters and Vacuum Cleaners

2008-04-14T07:07:20-07:00

Are toasters and vacuum cleaners ultimate examples of commodities? Of course!, right? Well, think again.

A few months back I read ‘The Myth of Commoditization’ by Michael Schrage, an article in the ‘MIT Sloan Management Review’ magazine and ever since I find myself getting back to the facts and the concepts masterfully described by Mr. Schrage in his two-page article.

By know, I hope that you’re a little intrigued and you will want to read on this, my first, OpenEdge Perspectives blog. There are many aspects of what Progress Software has done with OpenEdge over the years that in my opinion share parallelisms with Toasters and Vacuum Cleaners not being commodities: Quite the contrary, retaining and extending our, as their’s intrinsic and perceived value. Progress (the product and the company shared the name back then) was first released in the early 1980s and throughout 25 years of innovation cycles driven by our customers (Thank you!), the market and the IT industry we have kept our mission: “Simplify the job of building the world’s best business applications”.

How many evolutions and revolutions!: From the minis, hosts, personal computers, client-server, application servers, to the Internet. From character, GUI, one-tier, two-tier to global all-tier. From procedural, event-driven, object-oriented to SOA and software-as-services. How many opportunities to become commodity! And nevertheless Progress is not.

As information technologies evolved, the more the unfulfilled promises from many for simple, easy to use offerings to build long-lasting and ever-changing business applications. Simplify is difficult!. First you need to make something possible. Many products stop there. Then you can simplify. Very few actually do.

Let me tell you a story: Long ago, when I was a programmer using Progress and working on-site, one of the company’s line of business manager said to me: ‘You see, I’ve been looking for a while at what you do and no matter what I ask you to do, or how complex my request may be, you always, always do the same thing: You start a tool that I noticed is called Procedure Editor. Then you type a few lines of code which for the most I can actually understand and voilà you have the information I needed. Quite often in a format that is not pretty I have to say, but boy you are fast!’

That company had Progress-based applications, and a bunch of other ones they had purchased, acquired or developed over the years. All in all a hodge-podge of C-ISAM and an early Oracle database, COBOL, BASIC and some C, and an IBM mainframe with RPG of course. We had installed Progress and the Oracle and C-ISAM DataServers (back then Progress called them Gateways). Many of the ad-hoc requests I was getting from LOB managers meant to cross-reference and join information from many of theses systems, and yes, I always started with the Procedure Editor, connecting to the data sources, looking at their schemas (nevermind some were not even relational), and writing a few lines of ABL. Such was the power of Progress.

Many customers tell me that today they are doing similar things with OpenEdge Architect with IntelliSense, auto-completion, dragging-and-dropping from database schemas to the code editor and the works compared to my character-based Procedure Editor. Perhaps some of them even have to gather information from web services. What’s the drill? Get and look at the WSDL, connect, and RUN, where I used to connect to Progress, Oracle and C-ISAM, check the schemas and RUN.

So what’s the moral? Our customers tell me that Progress OpenEdge’s unique, intrinsic and sustained value to them is its business focus. If we managed to simplify building complex business applications including reading, writing, and managing data from displarate data sources, now we are simplifying to build, extend and integrate heterogeneous business applications using messaging, Enterprise Service Bus, Web services, and SOA-principles with OpenEdge, .NET, Java and standard interfaces.

Progress cannot just make things Simple, because businesses are not. We make things Simpler! As for Toasters and Vaccuum Cleaners, commoditization is a misleading guide to innovation, a race to the bottom. At Progress Software we prefer races to the top. In the long run, everything is not a toaster. Not even toasters.