View from the Edge

OpenEdge 10.2A coming soon

OpenEdge 10.2A is scheduled to be available soon.  OpenEdge is the only platform that is optimized for the building of Service-Oriented Business Applications.  It differentiates from other offerings in the market because:

• Its purpose to simplify building your data- and transaction- and service-centric business applications with the highest productivity
• Integration and interoperability features are built-in, thus making it easy for you to connect to any application regardless of the technology or platform its built-on
• Support of a broad and rich set of open interfaces and integrated UI capabilities to ensure your applications can be built with any UI technology you choose, and even support multiple UIs with a single set of business logic
• High performance and scalable embedded database that ensures that all your data management needs can be met

OpenEdge 10.2A focus on the commercialization of the OpenEdge GUI for .NET which provides developers with the ability to build competitive, state of the art, contemporary user interfaces for their applications using Microsoft .NET Winforms technology.   What makes OpenEdge 10.2A offering better is that developers can do so in a highly productive manner because the new functionality is built into OpenEdge, integrating in OpenEdge Architect the new development tools such as the brand new Visual Designer and the extended Class Browser, empowering you to use only ABL, the best business-purposed programming language, and being fully compatible and interoperable with your existing OpenEdge GUI, to adopt at your own pace.

No one else provides such ease of use, productivity and business functionality, all within a single purpose development environment.

But 10.2A is anticipated to have much more than the GUI for .NET!  From a host of customer-driven usability and performance enhancements in OpenEdge Architect, as well as new XML and WSDL editors, to more OO extensions including garbage collection, through a new TIMEZONE session attribute to ease the deployment and reduce the operation costs of global applications, or sparse ProDataSet XML serialization for lower resources and increased performance, or OpenEdge server products support for Windows 2008 64-bit, to mention just a few.

The very high number of members and level of participation in the 10.2A Beta program, one of our largest and exciting beta programs ever, should be a good indication of the enthusiasm and anticipation that the Progress community is showing for OpenEdge 10.2A.  So, stay tuned for more information coming soon, and hang on, just a few more weeks to go!

Salvador

* For informational purposes only. Information in this posting may not be interpreted as any commitment on behalf of Progress, and future development, timing and release of any features or functionality described remains at our sole discretion.

Business-orientation and object-orientation

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

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.

Of OpenEdge, Toasters and Vacuum Cleaners

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.