View from the Edge

Eclipsecon 2009 and Eclipse 4.0

Recently I attended Eclipsecon 2009, an Eclipse community conference in Santa Clara, CA. Like previous years, the conference was very well organized and had sessions on various topics ranging from e4 (code name for Eclipse 4.0 release) to Cloud Computing. There was a lot of buzz and even a separate track for e4 - so let me begin by blogging on e4.

General sense I got was that Eclipse community has ambitious plans to make significant changes to Eclipse 4.0. More than 40 committers are working on Eclipse 4.0 release and the Eclipse community intends to deliver e4 Tech Preview in July, 2009 and the GA in summer 2010. They plan to provide a compatibility layer from Eclipse 3.x to Eclipse 4.x so there can be gradual adoption of Eclipse 4.0 J.  Following are some key highlights of the areas that they are planning changes –   

• There was talk of "How the current Eclipse platform UI is very rigid". To make the UI work across multiple platforms and web technologies, the SWT team is working on a model driven UI called XWT – which will leverage EMF based models and CSS style-sheets to render UI on multiple platforms and also on web using FLEX/action script, GWT or Silverlight. There is also separate effort to create declarative UI language for defining UI. So in summary, there is a lot of work and planning going on to provide different skins to the Eclipse platform.

• Eclipse resources are being enhanced to better support linked resources, groups and various resource filters are being added to Eclipse environment.

• Couple of Mozilla guys have teamed up with Eclipse committers and are working to provide ability to edit code from the web (by providing the same level of rich editing capabilities) using (I think) Bespin technology.

• There is a lot more work happening in different areas and I could go on ... but you get the idea. These are big changes and a lot of cool and new things to look forward to...

From OpenEdge Architect Perspective, we would need to keep an eye out on developments in e4 so that in future, we can leverage the full potential of the e4 to provide lot of these cool productivity enhancing new features to the OpenEdge developer community.

Could This Happen to You?

This was an interesting article that came across my desk from a colleague at Progress (thanks Dave C.!) regarding a disaster that has gone largely unnoticed.  I thought it was an interesting example of what you can plan for (or not plan for).

The article talks about a small town in Northern California called Morgan Hill.  The challenge is that this type of man-made disaster could happen anywhere in the US.  How you build a contingency into your Disaster Recovery Plan for this is very difficult.

You could make sure you have ham radio operators on staff, but that seems a bit eccentric.  You could also buy satellite phones for key personnel, but they may not work either (and still need to be charged). 

There are times when you can’t do or plan for everything.  There are, however, things that you can do to help mitigate these types of disasters.  You will not completely eliminate the impact of them, but you can minimize the affect they might have on your business.

The first is to establish a good rapport with the local emergency services personnel.  These include police and fire department.  But you should not limit yourself to those agencies.  You can also connect up with your local CERT (Community Emergency Response Team) organization as well as the local Red Cross.  Communicating with other businesses nearby is also critical to all of your success.  There are organizations like this in almost every country.  There are often times when you can work with other businesses to share resources to ensure that both of you are successful.  This also helps you know and understand what Disaster Recovery plans they may have in place that you may have overlooked.  For example, it would be nice to know that your office is close to their chemical processing plant.

The second thing you can do is ensure that critical systems are available during this type of an outage.  For example, can you run your internal network without an internet connection?  Some companies rely heavily on the internet from the corporate office to the remote branches that they become crippled if the network connection is not there.  Are the remote offices part of the critical business application that needs to function?

Lastly, you can choose to accept the risk that this type of a disaster will cause an outage to you.  As long as you quantify the outage and understand the impact it will have on your business it is acceptable.  This is similar to being self-insured when it comes to insuring your vehicle.

Have you seen or been a part of a local disaster that you would like to share?  I’d love to hear about it!

Until next time – Failure to plan is an option – just not a good one!

Brian B

Leveraging all the OpenEdge Architect Has to Offer

I recently came back from a trip to Europe where I presented the OpenEdge Strategy and Roadmap at the ProAlpha user conference held in Frankfurt, as well as at the OpenEdge 10.2A Partner Technical Forum held in Frankfurt and Vienna.  And while it is always fun to be able to talk about our strategy and roadmap with customers, let me say what I found most impressive was seeing the way that our strategy is really starting to payoff for many of our customers specifically in the way they have enhanced and extended the functionality that is provided by OpenEdge Architect to provide their own purposed tools in OpenEdge Architect’s Eclipse-base framework.

For example, Gunnar Schug from ProAlpha discussed with me how they are working on building their own tools Eclipse-based tools for OpenEdge Architect that do code analysis to ensure that they fit in with ProAlpha’s coding conventions.  ProAlpha is also leveraging the Mylin Eclipse plugin to improve and automate task management as part of the SDLC lifecycle.

Robert Prediger from ic4b AG demonstrated his Web4Biz framework and showed how he used the BackBase Eclipse plugin to build an Ajax interface for his OpenEdge Content Management System application.  The back-end architecture is all OpenEdge ABL and Application Server driven.

Klaus de Vries and Klaus Erichsen from IAP demonstrated their OF-1 framework which allows an OpenEdge developer to generate an OpenEdge GUI, an OpenEdge GUI for .NET, Java, and an Ajax UI from a common model, based on common visual designer, and have integrated this all into OpenEdge Architect.

Mike Fechner  from  Consultingwerk  focuses his time  on mentoring application partners to embrace the new OpenEdge 10.2A capabilities. During the forum he demonstrated his Dynamics for .NET framework showing how he has extended the Dynamics framework to support the OpenEdge GUI for .NET interface.

He also introduced “WinKit – Windows Integration Toolkit”, which simplifies the programming model when using the new OpenEdge GUI for .NET feature by adding a “productivity layer”,  and also takes advantage of  smart coexistence capabilities to run classic OpenEdge GUI Windows in an OpenEdge GUI for .NET MDI container. 

He built and developed these controls using the OpenEdge GUI for .NET capabilities built into OpenEdge Architect, but the other great thing is because the visual designer built into OpenEdge Architect is so extensible, he can access these new controls directly in the visual designer itself.

But a slick user interface needs a powerful business application in order to be useful, and Mike is working very closely with Thomas Wurl from Taste IT Consulting for that part. Together they have set up a joint project to merge the concepts of ADM2 and OpenEdge Reference Architecture (OERA)  with the OpenEdge GUI for .NET and Object-Orientation.  This framework and set of design tools includes Mike’s Smart Component Library – “Smart” GUI for .NET Components – with Thomas’ “tic-Enterprise” Developer and Framework.

It generates  an object-oriented OERA (O3ERA) backend from an imported Database Schema, defining Business Entities and generating classes and everything needed to have a full OERA Implementation.  

The above are just a few examples of why the value of OpenEdge Architect is greater than just the functions and features that you get with the product.  If you are using OpenEdge Architect then great.  Start leveraging some of the more advanced features, learn about the OpenEdge GUI for .NET, and try building something with the Visual Designer.  And now is a great time to start learning all that the Eclipse community has to offer so head on over to the Eclipse Web site.

If you are not using OpenEdge Architect, then it’s time to get started.  Work with your Progress account team to figure out the best way to introduce OpenEdge Architect into your environment, and checkout the OpenEdge Developers Corner for lots of good content on how you can get started with OpenEdge Architect.

 

Ken

 

 

Are you ready for your next Disaster?

When a disaster strikes are you going to be ready?  If you can’t answer this question with 100% surety then you have a challenge in front of you.  There are many different plans to prepare yourself for a disaster.  One that I have seen used both in the public sector in the United States and the private sector is the National Incident Management System (NIMS) and more specifically the Incident Command System (ICS).  These have been developed over the last 20 years to help agencies in the United States respond to a disaster.  There are similar systems available in almost every country and region around the world.

While both of these programs have been developed to respond to a public disaster – typically a natural disaster – they provide a very good foundation for the complete disaster management cycle.

ICS breaks the process down into 4 discreet components:  Mitigation, Preparedness, Response and Recovery.  On PSDN, Marv Stone and I will do a webinar / podcast on these components and how OpenEdge 10 meets these needs for your application.

Mitigation deals with identifying requirements (business and safety for example) and minimizing or avoiding those risks altogether.  An important part of this process is identifying where you are vulnerable.  Once you have identified this you can start to figure out what you “really” need to worry about.  This moves right into the planning component of your Disaster Recovery plan.

Planning addresses what options are available, choosing the appropriate option to meet your needs, implementing that option and testing the plan.  This is one of the most critical components in the process.  It also takes the most time.  It is an iterative process and will never be done…

The next component is Response.  This is execution of the plan.  The first part of this is declaring the disaster.  This would seem like a simple thing to do, but it isn’t.  I will talk about this in my next blog.  This is where your testing with your solution will pay off.  Whether it’s OpenEdge Replication, Failover Clusters, or After-Imaging, if you haven’t tested thoroughly then this could turn into a nightmare.  A critical part of this process is documentation.  Documenting what is being done, who is doing it, and when it was done is critical to the post-mortem (or Recovery) component of your environment.  If you don’t document and learn from your mistakes, you will inevitably make them again.

The last component is Recovery.  This can be interpreted in several different ways.  In the public sector it revolves around returning to life as usual (or as usual as it can possibly be).  In the private sector it involves failing back to your production environment and getting the complete business back up in business as usual mode.  This is also affected by your planning process.  Failing back should be planned and tested in the Planning component of your plan.  Documentation is also critical in this component in order to clean up and prevent additional outage time.

Marv and I will chat about these and where OpenEdge 10 plays a part in all of these components of your Disaster Recovery plan.  Be sure to listen in!

Until next time, a disaster is only a disaster if you are not ready for it.

Brian B