As a a product manager, I’m often asked “what’s new or what’s coming?”., and the simple answer is : “Change” We have all heard the quote “Change is our friend”, although in many cases I’ve not been completely sure, but it is a fact: change is a trademark of the IT industry.
I started out as an IT professional developing CICS and COBOL applications. Even at that time change was underway… we were in the midst of changing from Macro to Command level CICS programming interfaces. That change was definitely good for both customers and IT. Customers got more, IT was able to deliver more easily.
Then came the client/server revolution. Certainly customers got beter ways to view and process - but it was unclear if IT was able to do more. I don’t think I would ever say that C and the Windows programming model and API’s were easy.
With the advent of the Web, it certainly was clear to me that users could get more information more readily to support better business decisions and business processes: all in all customers received lots more value. Phenomenal value. But it was also pretty clear that instead of doing more, with the proliferation of technical complexity , IT could be doing less. Not because IT staff wasn’t working harder –they were – but because of the growing number of artifacts, technologies,languages, and the fact that runtimes did less and code had to do more.
To compound the problem, as complexity grew, the economic climate and business demands increased the pressure on workers, who were expected to be more and more productive. On average between 3 and 6 percent more productive according to overall worker productivity economic estimates. I think you get the picture.
Then SOA and web services emerged. Really cool stuff that enabled transaction managers and platforms to seamlessly communicate. Again, customersgetting more. Like that. But some fairly good complexity built in as well : SOAP, XML, WSDL, WS-Security, WS-Transaction, WS splat, headers, payloads, and so forth…. Left me wondering why it all just couldn’t have been implemented in a simpler fashion.
Now it’s the time of Web 2 and Rich Internet Applications. With Web 2, we’re realizing the power of the Web by exponentially increasing the power the browser can deliver to the users. We’re also getting a simpler and cleaner programming model. Client side programming and application flow stays in the client tier, facilitated by client side scripting languages. Server side programming focuses on flows and processing of business logic and data. It’s clean, and separates concerns. The architect in me likes that. And customers that have standardized on business processing in J2EE, CICS, IMS and other transaction managers can continue leverage them for back-end (heck, whoever wanted those high valued business systems to be processing User Interfaces anyway?). Now we’ve certainly got something for the users with significant value , but what about IT?
That's where EGL comes in. It’s a simple common language for the various elements of the application. Both the UI as well as enabling integration – including Web Services – and all the way to back end business and data processing. EGL provides something for IT as well, it enable developers to deliver more with less effort, simplifying innovation.
But most importantly it’s an Easy General Language. The idea here is that a standard language across application tiers makes developers more productive. And also hedges an organization's bets that the next great platform, runtime, language is coming. Let’s see – you ever hear that said about PHP, Groovy, etc. The point here is that EGL is an Extensible Generalized Language. Support for new runtimes, languages, frameworks and technologies continue to be added as needed. To net it out EGL applications are meant to be portable between runtimes and platforms, yet not be constrained by one specific architecture.
So does the world need another language? Whole heartedly I say yes. In fact we’ll see many many more new languages and runtimes over the next 20 years. What we don’t necessarily need is for IT to have to code in them all to accomplish a single business system. Think about the change from TV to HD. You get a converter box – everything just works.
Finally, I’m asked will EGL be a standard. If a technology having a set of processes, API's, extension points managed by an open community can be considered a "standard" then the answer is absolutely! The community is this one, the EGL community. We’ll shortly be implementing a process, accessible on this site, where all members of the community will be able to participate in the development and vision of the language. So you’ve heard it here first. The current target for the establishment of this process is late 2008, after the next major release of EGL and RBD.
I encourage everyone to become an active member of this growing community, so hit the EGL café “JOIN” button and let's talk EGL![Read More]
This EGL Cafe blog will contain announcements, discussions, and experience reports on topics such as:
- web2.0, what it means to us and what it means to you
- the value of Ajax and how it impacts the programming model
- how Dojo can be used successfully to build professionally-looking applications
- how Rich Internet Applications differ from server-side applications
- using end-to-end EGL for developing browser-based business applications
- adding a Google map to your application
- examples of real-life usage of EGL Rich UI
- how to call SOAP and REST services from EGL
- how security impacts the deployment story
- and so on
We will have various members on the EGL Rich UI development team contribute blog entries over the time to come and we will invite others to blog here also. Let us know if you have a specific proposal for a blog topic, and we'll write something on your favorite topic here.
Thanks for visiting, and we hope you will visit us often in the future.
Chris Laffra, EGL Rich UI Architect, RBD Product Architect, IBM Rational[Read More]
Hello from Mark and Dave.
We hope this will be a blog that is of interest to many people. We work with a lot of customers who have existing applications running on System z in CICS, IMS, or batch that access files, DB2, or DL/I. The focus of this blog will be how you can transform existing z-based applications into a more modern architecture using EGL. This could include using EGL to wrapper existing applications into web services for SOA based systems, to restructuring applications to segment out the business and data logic, front-ending existing services or callable programs with EGL JSF or EGL Rich Ui (Web 2.0 capability currently in AlphaWorks), integration of EGL web technologies with the web services capabilities in Rational Developer for System z, and other appropriate topics.
We welcome your participation in this blog and hope you will share you thoughts, solutions, or other information related to using EGL to modernize System z based systems and environments.[Read More]
Welcome to the EGL Development Team blog! The EGL development team consists of the testers, developers, writers and architects who make the magic of EGL technology happen. This is a highly talented group of individuals who are dispersed around the world: North Carolina, US (our main site), Connecticut, US, Beijing, China and Toronto, Canada.
In this blog, you will hear from us what we are up to with driving our technology and products forward. Occasionally, you might even hear about what we are up to with our personal lives. We hope to develop a virtual connection with you, our users. Please give us feedback by commenting on our blog entries.
I am very excited about what we are doing and where we are headed with the product. My team and I look forward to sharing our excitement with you via this blog.
Wing Hong (Albert) Ho, Senior Manager, EGL & RBD Development[Read More]
NorthCarolina 120000QHDE Tags:  ca_cool:gen cobol eglcafe ca_telon ca_ideal vb adabas application_modernization rpg application_conversion application_transformatio... powerbuilder maestro natural 2 Comments 7,175 Views
The Application Transformation Blog is a forum for IBMers, customers and business partners to discuss the who, what , when, where , how and whys of transforming legacy applications written in VAGen, SmallTalk, I4GL, Natural/ADABAS, RPG, CA Cool:Gen, CA Ideal, CA Telon, Maestro, APS, Powerbuilder, VB, and other 4GLs to Rational Business Developer featuring EGL technology.
This blog should be used by customers who have spent huge sums of time and treasure developing custom applications that set them apart from competitors and optimally support their specific business processes. Yet when it comes to functionality and technology, these custom applications can quickly grow old and lose their value. So th ey need to find alternatives that leverage their investments.
Who is a candidate for Applicaiton Transformation?
Literally any IT organization running older legacy systems that are core to the business, not necessarily broken, but are on life support due to the software being in maintenance mode, a lack of skilled IT programming staff in the older language or an IT strategic direction is to move to a new , modern software development platform.
When is it appropriate?
That depends on the specific business need, for example:
Extending the application lifecycle
Transitioning to an SOA
New UI (User Interface) requirements - Web/JSF, Rich Client/Web 2.0
Improving agility and Increasing competiveness
Vanishing RPG developer skills - Consolidating development teams
Through maintenance, functional aging can be circumvented or at least significantly slowed. Most of the time, however, technical aging goes unnoticed until unreasonably high maintenance costs arise later on in the lifecycle; application agility declines; or the development platform begins dying a slow death. These are all indications that it's time to migrate an application to a new technological platform before its costs outweigh its benefits.
When they reach this point, companies often find themselves in a bind. They realize that it's not cost-effective to simply replace their legacy applications with modern standard software. And few can afford to continually rewrite all of their custom software to keep it up to date. Even if they can afford rewrites, companies realize that the money could be better spent on a more cost-effective approach to modernizing and migrating to the latest technical standards.
How do you approach application transformation? What's involved? Which technologies? Are there phases?
There are three main phases in any applicaiton transformation:
Discovery aNd Analysis(DNA)
Implementation, Testing and Deployment
From a technology perspective the target of all Rational Application transformations is Rational Business Developer featuring EGL technology. Embedded in Eclipse, EGL offers a modern, service-oriented language for the efficient development of different application types, including Web programs, database applications, Web services, and batch and high-performance servers for fast transaction processing. Thanks to the tightly knit integration in the IBM Rational tool chain, EGL development can be embedded in a professional development process or lifecycle -from requirements management to modeling and coding, to testing and deployment. EGL's ease of adoption helps facilitate the transformation of RPG applications. Because EGL is easy to learn, it enables RPG developers to transfer their valuable business know-how in just a fraction of the time it would take for those same developers to transfer to Java technology.
Where does it occur?
Some tasks can be performed off-site on secured servers - the initial DNA and actual code transformation. The actual code transformation is typically performed off-site on secured servers. An EGL Project or Projects would be delivered to the customer site for implementation and testing which can be performed by the application owner or a service provider. Other tasks must be performed on-site - Education & training, code remediation (if required), implementation and testing.
Who performs which tasks?
Depending on the legacy source code environment, IBM & IBM specific business partners will perform the analysis and code transformation. The code remediation (if required), implementation, testing and deployment can be performed by internal IT staff with or without assistance from IBM, IBM SI or IBM Business Partners.
None of this is trivial, but it is all doable. The best advice is to contact Ed Gondek at IBM Rational - firstname.lastname@example.org and start the discussion![Read More]
Hi, and welcome to the Extending RPG Applications to the Web with EGL blog. This is a blog by some of the IBM i application development tools team members at the IBM Toronto Lab. We've all been involved with RPG and related application development tools for 10+ years (each of us, not cumulative!)
We all believe in using the right tool for the right job. RPG is a very powerful business language on the IBM i. EGL is a powerful language for working with new technologies such as AJAX, JavaServer Faces (JSF)and Web services. So this blog will focus on using the two together; taking business logic written in RPG and providing a Web user interface or Web service interface to it using EGL.
To that end, we hope to provide tips, techniques, stories, pointers and probably even a few questions in this blog. If you are an RPG developer and are using (or looking to use) EGL, we encourage you to comment on blog postings.
Claus, George F, George V, Satish, and Don[Read More]
I am the chief architect and inventor of the EGL programming language. I would like to use this blog to involve the community in issues that revolve around the language itself such as:
Tim W Wilson, STSM, EGL Chief Architect [Read More]
Hayden Lindsey here. Let me be one of the first to welcome you to the EGL Café!
First, let me introduct myself. I am responsible for Enterprise Tools & Compilers within Rational, which includes development and jumpstart services for EGL and the Rational Business Developer product. I have been with IBM for almost 23 years now, and for my entire career, I have been involved in one way or another with what is now EGL. While I have seen many great technical advances, customer success stories and the like through the years I have never been more excited about the potential and WW momentum that I am now seeing around EGL.
The goal of this Café is to accelerate that momentum and, in particular, accelerate the growth of the EGL community. Customers, business partners, and IBM employees can use the Café to connect with each other, share best practices, share code, get access to the latest product information, and learn from each other. Of course, like any social network, the value that you will gain from the EGL Café is directly tied to the active participation of the community--if you participate, you increase the value for everyone; if you do not...well let's assume that will not happen.
In the last 2 years, I have travelled extensively, meeting with hundreds of cusotmers worldwide. When discussing their IT challenges, I frequently hear the same set of issues...customers wanting to know how they can:
So, again, welcome to the EGL Café. Let's all participate in order to raise the value of this venue for everyone.[Read More]
Who am I?
On the surface, I am responsible for IBM Rational's Enterprise Modernization tools and compilers. EGL is included in that category because it is a key element of our strategy to help customers modernize their applicaiton portfolios. EGL is multi-dimensional, though, so lets be careful about pigeon-holes. Much more on this in future blogs!
A second answer to who am I can be found in what I have been. Prior to working for IBM, I joined a small start-up System 38 Independent Software Vendor that focused on the Oil & Gas industry. For the 11 years that I spent with that company I built or managed the building of line of business applications for that industry in the RPG language for the System 38/AS400/iSeries/System i/IBM i platform. We were "business developers" before anyone had coined the term in the software industry. This meant that our understanding of the Oil & Gas business was valued as highly as our ability to write killer applications for that industry quickly. This blending of business and technical knowledge and a keen focus on solving business problems with software applications was a perfect match for the System 38 and its successors. This is because that platform was targeted at providing a well-conceived, complete, end-to-end, highly productivce, yet simple application environment that encourages a focus on solving the business problem, not technology issues. So, this tells you that I wrote business applications and liked the i platform...
What does EGL mean to me?
This description of the System 38 can also help to describe a key aspect of EGL...that is, its keen focus on helping developers to solve business problems. Specifically, It's designed be a highly productive, complete, well-conceived, yet simple way to build business applications from one end to the other, with the added advantage of being able to run in several different runtime environments.
My hopes and aspirations for this site
Community is essential to a language today and we've had countless suggestions from our customers and partners that they needed a central place to meet, share experiences, and get the latest on EGL. The EGL Cafe is that place. I expect to see blogs from partners and ISV's that are leveraging EGL and have parts or services to share or sell. I expect to see additional forums spawned around specific sub-communities like Web 2.0 development with EGL or ISV's or exploiting IBM i or ... These sub-communities can drill deep and talk about things that are specifically interesting to them. I expect to see Jon Sayles' extensive portfolio of EGL content exposed to more EGL developers in "Jon's Corner". I expect to see all sorts of documents related to the wonderful world of EGL application development. And finally I hope to be surprised with new and interesting content and ideas for the EGL world![Read More]
I am getting ready for RSDC 2008, where I will be showing off EGL Rich UI in the Rational Labs sessions at the exhibit floor, and presenting at session EM09. To organize my way around the conference, I wrote a conference scheduler with Joe Pluta, and together we showcase EGL being used end-to-end, starting at an IBM i box to WebSphere to a UI running on an iPhone.
See you there...[Read More]
EGL Rich UI is all about Rich Web Applications. In this blog post, I will spend some time discussing what the buzz is all about around web 2.0.
Rich Web Applications, sometimes also called Rich Internet Applications, are applications offered via a browser that behave like desktop applications,. They typically serve up data stored on one or more servers, and display that data in a highly responsive user interface. Both validation and business logic can run inside the browser and no installation is required. Typical examples are applications to process a travel expense account, do tax processing, perform a mortgage calculator, or find the perfect house based on a wide variety of requirements.
Most rich web application are situational in nature, meaning that they are used infrequently or from different locations and/or computers. The web is the ideal distribution medium for those types of applications. Namely, unlike desktop applications, rich web applications are easy to maintain because new versions can be offered by simply refreshing the current page in the browser. There is no installation required, so new users get going faster also.
Furthermore, when compared to traditional static websites, rich web applications have operational advantages. Rich web applications tend to do most of the orchestration in the browser itself, thereby moving presentation logic from the server to the browser. This is why people refer to those applications as "mashup" applications. This reduces the load on the server, thereby increasing both throughput and improving transaction rates. Finally, the type of services calls invoked by rich web application tend to be more stateless, improving the opportunity for caching of results both inside the server and on edges, such as inside proxy servers.[Read More]
EGL Rich UI makes the development of Rich Web Applications much easier. Why is that?
EGL Rich Web was specifically developed to easily develop these highly responsive rich web applications. EGL strives to provide abstractions that are at just the right level, allowing developers to focus on the "what", rather than on the "how". All user interfaces are expressed in a declarative language, and Ajax calls are very easily implemented because EGL Rich Web automatically parses the resulting JSON and XML documents and turns them into easy to manage EGL data structures.
Furthermore, with the addition of EGL Rich Web support, it is now possible to write an entire web based application, from server to the user interface, in EGL. And, once you have learned EGL for one specific application tier, you can immediately transfer those skills and be productive in all parts of an application.[Read More]
It's been an interesting few weeks as Chris Laffra and I have been working on the scheduler application for RSDC. To give you a quick overview, I'm running the EGL part of the application on a Windows workstation (in fact, I'm running it inside of RBD's test environment). That in turn talks to my IBM iSeries model 270 and exposes the RPG business logic as web services. The front end that consumes the web services (written in EGL Rich UI) is being served either through that same RBD instance or from a public PHP server in Norway somewhere.
So as it stands, you could be using a browser in South America to talk to a server in Chicago that talks to an iSeries in the same room, or you could be using an iPhone in Japan to talk to a PHP server in Norway that talks to that same iSeries in Chicago. And all of this without Chris or I having to write a single line of Java code or do much of anything except generate the WSDL using RBD (me) and consume it (him). And all with excellent speed. And you should see it when the whole thing is on a single LAN!
Anyway, the really interesting bit happened last week. The iSeries (and its successors, the System i and now the IBM i) share an incredible reliability. They're very good about handling RAID disk and they also will tell you about any problems they're having. I happen to have two servers: an older workhorse model 270 that I own and that I use for day-to-day application serving, and then a newer development box that I lease, getting a new box every year or two to keep up with the latest technologies.
Well, the production machine, where I was running the application, started telling me it had a pending disk drive error. I love that - not only does it support RAID, but it also tells you when one of the drives is acting up even before it fails so that you can be ready to replace it. And while replacing a drive is easy enough, rebuilding a RAID set takes time. Since we were getting close to the conference and actually had the application up for live testing, I didn't really want to bring the machine down for the couple of hours it would take to rebuild the RAID set.
So I made an executive decision. I brought down the WAS server in RBD, did a save/restore of the RSDC library from the production i machine (the model 270) to the development i machine (the model 520), changed the server name on the Linkage parts, did a quick regen of the app, and restarted the WAS server. All of this took about five minutes, and nobody was the wiser. And reflecting on this, since I use a hardcoded HOSTS table on the workstation, I could have simply changed that entry to point to the other model 520 and saved myself two of those five minutes.
The point of all this? Well it seems that the architecture is doing exactly what it's supposed to do. Chris was able to do initial testing without even needing the back end. Then, once the back end was up, it was easy to run the front end simultaneously on two different machines. And as for the back end, failing over to a different machine is as easy as changing an address in the HOSTS table. Chris and I have been able to concentrate on features rather than infrastructure, and that really is the promise of EGL.
Joe [Read More]
Well, of course it was William Shatner, not Captain Kirk, but it was still outstanding. Through a series of terrifically funny anecdotes, Shatner related the software development industry to the movie production industry, and often had the audience howling. It was all great fun.
Seeing my boyhood idol was just one more of the surreal bits of my time in Orlando. Through my own lack of prior preparation, I had to stay offsite, so both days I found myself cabbing through Disney World. It was always a bit of a mental clash to go from the high-energy environment of the conference to looking out the window of the cab and seeing the Tower of Terror.
I would have loved to stay longer, but there are just too many things to do back here at home. When I gave my session, it was clear that the attendees saw the power of the tool, and how EGL could provide them with the fastest way to extend the business logic behind their green screen code to the web and beyond. It's a great story: a few lines of code and you can call an ILE program. Drag and drop an array on a page, and you have a table of data. Or, check a box and turn a function into a web service. Just a few lines of EGL turns the IBM i into a full-fledged participant in modern application architectures.
But it doesn't stop there. Add onto that the new Rich Web Services capabilites and now you're at the very leading edfe of technology. I stuck my head into a Dojo session, and I know that the RWS team is looking at the GWTx toolkit. And that's what puts EGL head and shoulders above things like RPG-CGI and PHP. Instead of spending their time figuring out the plumbing needed to add basic web capabilities to their existing systems, i developers can use EGL to do the plumbing for them and can instead focus on architecting the next generation of applications.
Joe [Read More]
Green technology as a core corporate strategy is an ever increasing initiative with companies across the globe. Gartner Group recently published it's Top 10 technology strategies for 2008, ...and Green IT was #1 on that list. We at ClearBlade see the opportunity for a "green" approach to your existing code and data. Similar to it's hardware counterparts, by re-cycling software there are not only energy efficiencies and adherence to social responsibility, but additional costs and human capital savings to be realized.
We see technologies like EGL as a viable and long-term solution for Green Code practices which supplement and adhere to an overall Green IT strategy.
Too often, we see large, resource-heavy company-wide code and technology migrations fueled heavily by the neccesity for enterprise modernization as a paramount business driver. The problem is that the legacy code and data often finds it's way to the "software scrapheap" in these initiatives. The ability to leverage EGL and the Rational suite of products and metholodogies for refactoring, refacing, or transforming legacy code as an enterprise modernization solution is a prudent way to re-use not only your existing code, but your existing human capital as well. Green Code in it's finest hour. Existing applications and talent are among the most valuable assets a company owns. Why waste both the physical and intellectual energy to constantly re-modernize, when a technology like EGL cleanly serves the triple bottom line (3BL/TBL) of people, planet, and profit.
The goal of the Green Code blog is gain awareness on the "Green Code" approach, share insights on how best to evangelize this win-win solution, and provide best practices on what we see as the next evolution in Green IT. We welcome your participation![Read More]
JoePluta 100000KMX3 Tags:  business_logic egl application_modernization rpg i eglcafe 4 Comments 5,626 Views
I noticed that I have been somewhat remiss in that I haven't actually written a formal "Welcome to my Blog" post. This is my first blog, so perhaps you can forgive me that transgression. (I told my good friend David that I had finally releneted and was blogging. His response? "I AM LOCUTUS OF BLOG! YOU WILL BE ASSIMILATED! RESISTANCE IS FUTILE!" Guess he's right.) Anyway, it's that time - time where I try to let you know what this corner of the Internet is intended to be about, and you can decide whether you want to follow the bouncing blogger.
I have a very straightforward goal. I want the i platform to continue on being the best darned business logic server ever designed, and EGL is the way to do it. The reason is simple: the IBM i, whatever it's name or incarnation, has always been about simplicity. You could, with enough work, get another platform to do most of what the i does. But it was always easier, and faster, and more productive with the i. Not only that, but until the advent of the Web, the i was perhaps the last bastion of the one-person IT shop; one good programmer could literally do everything required to keep an i shop running. If you knew DDS, CL and RPG (or COBOL), and knew how to hit F1 and F4, you could pretty much run an i and keep its users happy.
However, in the brave new world of Web development, the i message got a little fragmented. Rather than there being a single path to getting your work done, there were many. RPG-CGI, Net.Data, Java, and now even PHP; these were all heralded at one time or another as the way to the web for i shops, but for one reason or another, they never lived up to the hype. It seemed that the technology was either easy to use but a little out-of-date, or else so bleeding edge that developers couldn't keep up. In either case, the i slipped further behind the curve and we know the outcome: it became that "old" box in the corner that just wasn't glitzy enough. Forget that it had been running all applicaitons flawlessly and with nearly zero downtime for years; the new generation is all about the glitz, and what have you done for me lately.
Enter EGL! By combining a procedural syntax with the concept of hiding complexity, EGL does what i developers have been asking for: it gives them a clean, consistent way to write web applications where they can concentrate on the business logic rather than the plumbing. In many ways, EGL is the spiritual successor to the 5250. While it far surpasses the 5250 in rich user experience, in many ways it's as easy, if not easier, to use than the old green screen SDA. Combine that with a carefully crafted and deceptively simple CALL Interface, and EGL does for the web what display files did for the green screen.
There's a subplot here: using EGL and RPG together. Note that I said RPG; you could also use COBOL if you were so inclined, and lots of EGL folks do. In fact, EGL will generate COBOL and I will spend some time with that particular piece of the technology over the coming months. But I am an i guy, and for the majority of us, RPG is the language we use to code business logic. And while there are lots of really super-bright people working to make EGL a complete, self-contained business language, my particular self-appointed niche is going to be making sure that all those RPG programs (and more importantly, those RPG programmers) can use EGL to enhance and extend their existing applications, letting them co-exist with brand new applications (written in EGL, of course!).
Programmers may some day be able to write entire ERP applications using nothing but EGL; that's certainly the goal of the EGL team. But for now, i shops already have business logic - logic that they've spent years (even decades!) developing - and the best initial use of EGL in those shops is exposing that logic, either directly as browser-based web applications or - moving to the true SOA approach - as web services that can be consumed by other internal and external clients. Then, they can combine that newly enabled business logic with all the rich application features of EGL to create new integrated applications they never dreamed of.
And my goal will be to explain how to do that quickly and productively.[Read More]
Although it's not really the focus of this entry, I just like saying that. It's such a good marketing phrase; I wish we'd see more like it. And we could, you know - the EGL team is putting together the kind of glitzy eye-catching technology that could be showcased everywhere from a YouTube spot to a Super Bowl ad (do I have to pay to say that?).
I guess though that catchphrase is indeed germane to this entry; in a way it really epitomizes a large part of what I want this blog to be about: moving the i into the future (I'm not going to make all the *i*'s blue this time - bold ought to be enough). I want to really delve into those areas where the particular strengths of EGL and the i work together the best. For example, in the case of the RSDC scheduler, Chris Laffra and I were able to make three technologies - EGL Java/WebSphere, EGL RUI and good old RPG - work together flawlessly. Development was at a pace unlike anything I've done in a long time, and the fact that we could concentrate on the business requirements rather than the plumbing allowed us to deliver code at the speed of thought. It was quite an exhilirating experience, actually.
But what exactly does that mean for my core constituency? What can EGL really do for the long-time IBM midrange customers? These are customers who have entrusted their business to the midrange since it had names like "System/3" and technologies like CCP, customers whose most important asset right now is not even their programs so much as their programmers - programmers with a skill set that all signs indicate is becoming harder and harder to find.
What can EGL do for these folks? Well, in my vision, EGL is nothing short of the wonder drug for these shops. First, it will allow procedural programmers to write web applications. The popularity of languages like Visual Basic and PHP ought to make it clear that not all code need be written in OO, and that procedural programming is still an important otol in the business toolkit. This is particularly good news for business programmers becuase the procedural nature of EGL removes one of the biggest hurdles between RPG/COBOL programmers and the brave new world of the web. The WYSIWYG design tools and the declarative nature of the EGL syntax is putty in the hands of people who have written RPG code.
But if the tool just put a new face on an old paradigm, it wouldn't be the future; it would just be a holding pattern. The future is where EGL really shines. Once you have your business logic encapsaulted in EGL library functions, you will be able to move forward into the world of AJAX and eventually to Rich Web Services (RWS or RUI, depending on which acronym you prefer). But the good news is that you don't have to do that wholesale. You can rewrite parts of your application with JSF (in fact JSF may be all you ever need for large parts of traditional green screen systems) and then apply the new technologies where they are best suited, such as for new executive dashboards or other Web 2.0 types of applications.
I always say thatyou should use the right tool for the job, and for i shops the right tool includes business logic on the i and then EGL for whatever user interface technologies are needed. The beauty is that the right tool for all of the new generation of UI jobs is EGL. [Read More]
esimone_clearblade 270000E5WV Tags:  green egl eglcafe rpg web2.0 soa clearblade green_code cobol 1 Comment 6,482 Views
Reuse is not a new idea, it's an "old school" mantra from the early 1990’s when objects and CORBA were all the rage (remember AD/Cycle? Grunge?). The more things change, the more they stay the same. We've been talking about the value of reuse for a long time now. The promise of reuse is compelling however it has not been widely adopted as a practice. Technology has made great strides in helping us reuse code more effectively, but at the end of the day most companies have had a hard time turning this potential into reality.
Why? Because it's hard. Regardless of the enabling technologies, reuse takes time, commitment and coordination. SOA and Jazz will help with future endeavors but today we are still bound by our history. The legacy code that runs the world’s systems today is not going away. On the contrary, it's growing. Gartner estimates there are over 230 billion lines of COBOL and RPG code in existence today with 5 billion added annually. We have to find ways to reuse this code.
Over the past 15 years, most technology advancements have manifested themselves as client and middleware solutions (i.e. browser technology and J2EE application servers). However, not much has changed with respect to the languages used to develop the legacy code? Now we have a new language that addresses this problem, EGL. IBM is the only company capable of creating a new language that easily interoperates these older technologies with the new technologies of SOA and Web 2.0.
EGL allows us to easily reuse and modernize existing code. We must extend what has already been built and utilize EGL to reduce the time and energy it takes to accomplish this. This is a requirement, not an option. At ClearBlade we are developing EGL design patterns and frameworks for reuse called Green Code. As we complete this code, we will make it available to the EGL Cafe to do our part to promote reuse.
We have no choice but to embrace, extend and reuse the legacy code in existence today. Rewriting and replacing existing code is not financially viable nor is it socially responsible. Reuse of our existing code saves energy by repurposing what we alreay have. Reuse is green, EGL is green.
Eric Simone – CEO ClearBlade[Read More]
I think for this initial posting I am going to introduce myself and from then on who knows what I will spout off about... I have a few ideas.
I have been involved in this product and it predecessors for the last 21 years. I started my career as a CSP/DB2/PLI developer working for Air New Zealand and after a few years migrated to the U.K where I freelanced for 5 odd years moving from CSP, to CSP/2AD, and finally to VisGen. I then came over to the development lab here and joined the team. It was about that time that the product got the VisualAge brand and became VisualAge Generator. I think the first release I worked on was 4.0 and I was involved with the processor and the debugger. My main value add was that I was fresh from being a 'customer'. I knew how enterprise customers worked, and how they used the product.
I moved off the product for about 5 years working on the WSAD Struts tooling and the Web Diagram Editor and then to the RAD team and worked on the J2EE Security Editor.
I moved back to the RBD product March 2007. An interesting piece of work I am currently involed in is something we have called the SWAT team. This is a small group of us whose job it is is to bear the initial work of any customer initiated issues. This can be anything from bug reports, suggested product improvements, to help our Eco Team out with Proof of Concept work. This all means we get to touch on areas of the product we would not normally be exposed to. An example of this was a defect we recently investigated involving a customers project that contain a great number of inter-related parts. They has an issue where a project build was taking 20 minutes. We tracked the problem back to the how we compiled parts when we detected cyclic dependencies. i.e. a requires b requires c requires a. In this situation we were not able to fully compile c since it needed 'a' to be compiled and the whole chain started when the request to compile a came in. Anyway, to cut it all short, through some clever caching we brought the time down from that 20 mins to under 2 mins.... cool huh? Well, I thought so. You need a big project with spaghetti like dependencies to see an improvement like this but it will be rolled out in the next 7.1 fix pack.
B.T.W The SWAT team is still waiting to be issued with our M16's and Kevlar jackets.
If anyone is interested in knowing more about life on the line as an RBD developer then feel free to post a comment with any questions or topics that you would like to see discussed here. Could be technical in nature... or not.
oh, and the title? ...... Go read some Douglas Adams. [Read More]
AaronAllsbrook 1100007U1F Tags:  eglcafe application_modernization web2.0 2 Comments 5,291 Views
Over the last few years I have seen a lot of parallels to the software landscape while watching television shows on flipping houses. Like building a house, software application development can be a tricky business. You pull together top architects, team with the most diligent developers, and inspire visionary usability experts to do great things. Upon closing day everyone cheers and hopefully makes a nice commission. Fast forward several years and the neighborhood looks different. Suddenly the expectations and work processes have grown; not just functionally but at the core of how they live and interact with your application. Although the foundation and purpose stays the same it's our job to meet those ever migrating requirements - in essence, to put down hardwood floors, knock down a wall or just apply a fresh coat of paint.
As developers today, we feel that dated pain when we admire our spiffy websites from a few years ago and hear words like AJAX, Web2.0, or mash-up. No matter how you look at the problem, ultimately, the work is now modernization. (Modernization doesn't just have to be moving a green screen application to the web - but rather keeping up with up the marketplace trends to meet business needs)
The good news is that the "need to modernize" problem is something people smarter than me have been solving for years. Some of the most popular buzz acronyms surrounding our field of expertise are MVC and SOA. Of course knowing those frameworks/strategies exist versus actually building applications that implement them is a whole other story. As much as we like talking to PowerPoint slides and waving our hands in the air while drawing imaginary boxes called services, there is a good bit of thought that needs to be done to make it actually happen.
Over the next few posts I hope to provide an approach, some general best practices, and practical examples that have grown out of my work over the last year of enabling EGL developers.
Personally, I hope that much of what gets presented here results in mental "AH-HA", or "OF COURSE", and "THAT'S OBVIOUS"; as these really are just MVC and SOA concepts in practice. What's gratifying about this is how much easier these concepts all become thanks to the abstract nature of EGL as it removes the need for a meticulous understanding of a particular framework.
Finally, this becomes a really significant addition to the overall EGL story. This approach - done
correctly - allows us as developers to quickly adopt the slickest new interfaces available; making what was a Mainframe program now a JSF implementation, or what was an EGL/PHP app now a Web2.0 RichUI that goes head to head with the best the web has to offer.[Read More]
Ha! I snuck in under the wire - it's been (just) less than a month since my last blog post. I hate when someone starts a blog and then just stops posting, but I assure you I had good reason. June was a super hectic month (including RSDC and OCEAN), and July hasn't shown any signs of letting up. There are things happening in the EGL world, some of which I can tell you, some I can't just yet. But suffice to say there will be a lot of things to talk about in the coming months - but you knew that would be the case, anyway, didn't you?
At the same time, I've had to keep up with the i world as well. Remember the name of this blog: EGL and i. Well, the i world has had some major announcements lately, many of which have to do with EGL directly or indirectly. For example, the ability to trade up from ADTS (the green screen tools) to RDi has been announced, which puts i programmers one step closer to EGL - hopefully once they play with RDi for a little while, they'll download a trial of RBD and find out what is really available!
Also, IBM announced the new Power 520 Express package - a powerful developer machine that includes a seat of RDi-SOA for EGL. IBM now has an entry level EGL machine for the RPG developer. This is huge. Anyway, I've been writing about that; you can read articles in MC Press and IBM Systems Magazine covering those topics.
But now I'm back and ready to roll with EGL. As many of you probably are, I'm waiting very expectantly for the next Alphaworks drop of Rich Web Support for EGL. As soon as it's available, I'll load it here at the Pluta Labs, and I'll strart letting you know what's up. Some say that Rich UI is a great complement for JSF, others say it is a replacement. I'll let you know what I think as I learn more about it, and this blog will be the primary place where you'll hear about my day to day struggles (well, here and in the forums :)).
Let's see how quickly this old dog can learn some new tech... [Read More]
The 2008 installment of the Rational Software Development Conference (RSDC) was held in Orlando the week of June 2. It was a great event, with >3200 attendees, interesting keynotes by the likes of Danny Sabbah (Rational GM), Grady Booch and William Shatner, detailed technical sessions in the various tracks and workshops, many customer and partner presentations, etc. The Enterprise Modernization track was very well attended, and we had several sessions on EGL, presented by IBMers, partners, customers and combinations.
The highlight of the week for the EGL fan was probably the skit done by Scott Hebner (Rational WW VP of Marketing and the MC of the conference) and Mitch Fatel (guest comedian and troublemaker) during the main tent on Tuesday. In short, Hebner challenged Mitch to create a Web 2.0 conference scheduler that runs on his iPhone within an hour...if successful, Mitch could have Hebner's job. 59 minutes later, Mitch returns with the RSDC Conference Scheduler running on the iPhone! How did Mitch do it? In his own words "EGL buddy! EGL!" (You will find a link to the skit on the EGL Cafe landing page.)
The backdrop to this skit is that Chris Laffra, our EGL architect and team lead for Rich Web UI, teamed with Joe Pluta of Pluta Brothers Design to create the RSDC Conference Scheduler using the upcoming EGL Rich Web UI support. Chris did the UI and Joe did the backend, which was a combination of EGL and RPG running on IBM i. It was advertised to conference attendees beforehand so they could access it from their iPhones, create custom session schedules, etc. We also highlighted it with a handout during the lunch on Wednesday. All in all, it was a great way to get the word out to a wider audience about EGL, and to show off a really cool new application of the technology.
The energy around EGL at the conference was very encouraging. We gave away ~150 of the new Rational Business Developer with EGL books--ran out early in the week. We gave away shirts and worn them ourselves--"EGL - Simplify Innovation". And most importantly as mentioned above, there were several talks by IBMers, partners and customers about EGL technology and how they are leveraging EGL to solve their business problems. For example, I was pleased to be joined in my Enterprise Modernization Overview talk in the Executive Summit portion of the conference by Carl Tilkin-Franssens, CIO of KBC. Carl described how his organization is leveraging EGL to create a large pool of business developers, located is various geographies around the world, that can work on projects independent of deployment platform--IMS, WAS, Unix--which KBC requires due to different infrastructure in different locations around Europe.
Finally, I was really encouraged by the enthusiasm of the many EGL business partners that attended RSDC this year. It is with their help that we can grow the number of EGL success stories so that the EGL presence at RSDC 2009 will be even greater!
This question is one of the most popular I get at IBM. It's often in the form of: Where do my new business developers, in many cases COBOL developers, come from?
I'll start with some background - beginning with: Why is this ? being asked?
Many industry forums and pundits have been saying that the COBOL community is aging. True.
As with any change - the aging and hopefully happy retirement of the COBOL developers that came on board with IT in the 70's needs to be planned for. A few best practices I've developed are as follow.
First, understand when they are retiring and what the potential scope of your problem is.
Second, document what their key responsibilities are today - and what skill sets you'll need to replace them. I'll give some of my thoughts. Some key attributes of business developers are: Great knowledge of your business, ability to churn lots of code and meet needs quickly, ability to not only do new development but understand and maintain vast libraries of legacy,
Third, define the labor pool you have to pull people in from.
Colleges. Think Information Technology, Computer Science, Engineering, and other Business majors. Contact your local college and discuss your needs with them. They may be very excited to work with an employer in the area on any custom requirements you have. As well, IBM is offering "free" education and curriculum materials to colleges for courses including many focused on the mainframe. See http://www.ibm.com/university.
Internal talent. Many organizations have technically oriented business people interested in Information Technology. Set up some courses - even night or lunch time courses - and educate them. Create a mentoring program - and the good ones - bring into IT.
Professional hires. Many, perhaps most, areas of the world have skilled resources available. There may however be geographic shortages. Take a look with your recruiters, http://monster.com, etc.
Offshoring. Another viable alternative. Works well when key sets of requirements can be fully documented - with check points often - maybe daily - on project progress. Also can work well with legacy where maintenance is reasonably controlled.
OK, now what will they do? or How do they add maximum value to your organization?
Business developers are all about adding immediate business value to a corporation's bottom line.
How? By understanding business problems and requirements, prototyping, designing and architecting, and then coding and completing processing. It's about being more responsive. A popular development paradigm you may have heard of to help developers be more responsive to the business is Agile development. Frequent interaction, delivering small discrete functional pieces of the application, getting feedback, and building to completion.
What types of applications? I firmly believe they will be Rich Web - architected to focus on the end user - with server based processing supporting business rules and data access, ultimately deployed as services in Service Oriented Architectures. Business developers will also need to deal with significant legacy processing. The best will perform well with both.
Many languages and transactional processors will participate in the movement to Rich Web. EGL, COBOL, Java, RPG and more. Languages and runtimes are about meeting specialized requirements - and will focus on supporting the back end of the application. But Web 2 is the defining architecture as it relates to the complete application - which will be driven through the front end or browser.
Perfect for the business developer community - meeting organizational requirements to do more.
As programmers, new technology is always interesting. But for most of us - when that technology surfaces in a usable programming model - is when it becomes real.
The Web 2 programming model is fundamentally different than the Web or ICCS programming models of the past.
The Web programming model revolved around designing a group of forms that in some way map to our desired business process. In many ways the information processed on each form was sequential; start here - do this - end here. As well, we were reasonably limited by what could fit on available real estate.
As a result, A user entered a request (form or URL), our application processes it, builds the next form, sent it, waited for a response, then built the next form sent it ... and on and on. After each request and before each response the user waits. 1 second, 5 seconds, 1 minute, etc. The traditional Web programming model is like this - and fancy enough - the traditional CICS programming model, albeit "green screen" driven, was also identical to this.
Things have changed. Users don't want to spend their time hitting buttons or function keys to move from form to form. And they don't want to wait. They do want to do more. They want to process more information now - the more information - the better the decision making process - and the more productive and ultimately revenue driven the user can be.
We still do requests and responses. But now the requests and responses can happen in an asynchronous manner. Only part, not all of the form waits for the response from the server. The user can go to other pages, other parts of the current page, even move on to other URL's.
Even better yet, as well the entire page - as in a traditional web application - doesn't have to reload and redraw.
And a side advantage - our back end servers aren't spending all their time serving up HTML web pages. They still do that on occasion. But the requests for information result in responses in XML. The web page doesn't have to be resent unless the application requires it.
And a second side advantage - the new programming model is easier. Developers need not be constrained by always having to manage the sequential form flows discussed above.
And yes, you can still create whole pages - that wait for responses - if that's what you like. But you'll still use the Web 2 model rather than the legacy Web model discussed above.
Wait, did I just use legacy and Web in the same sentence. Yes, any fundamental change has the potential to make the past legacy. I think this is a good thing. It means we're still being innovative and continue to evolve. And someday the Web 2 model will be legacy too. But the good news. The older Web model still works, is being developed - and isn't going away anytime soon, as the older CICS "green screen" model is still working and being developed as well. But as we've seen in the past and will continue to see into the future - there now is a better way. [Read More]
I am happy to announce that on July 25, we published a refresh for the Rich Web Support project at AlphaWorks.
In the coming weeks, we will start highlighting topics such as
Please try it out for yourself. Follow this link on this page: d-DOC-2395.
Note that we use the name Rich Web and Rich UI as synonyms for the same technology. The official name going forward is going to be EGL Rich UI.[Read More]
This seems to me to be one of the most fundamental, yet simple to understand issue that plagues IT today.
A ? that is tightly coupled with this is - Is IT going to be primarily viewed as an expense or as a revenue producer?
My view on this is pretty simple.
To deliver more value, IT organizations need to deliver more revenue producing applications faster. More processing, less time to market. Like I said - simple.
The average US worker improves productivity between 3 and 6 percent a year. Therefore every year - just off the top - IT developers need to deliver between 3 and 6 percent more value. Note, that's keeping pace with the economy - not creating any competitive advantage. How do we determine this improvement? One way to quantify what developers deliver is in lines of code, a second way to determine that is in business functions or key processes delivered. A third way is to measure profit of deliveries. The first is relatively easy to track; the second is harder but is certainly a more valuable indication, the third is of course the best way.
So who is the key to delivering value? Well, a sports team is in the business of scoring points, an IT organization is in the business of delivering processing. The skilled positions vary, but a key, maybe the key skilled position is the developer. They are the one doing the innovation and the creator of the new business functions or processing.
So then, how do developers do more? Strong tools enabling them to improve productivity, easier to implement architectures that deliver power and remove or hide complexity, and simple to learn, understand and write languages. That's it.
Yesterday I asked Tim Wilson, another blogger and the lead architect on EGL, how much productivity improvement can you get with EGL over other 3GL's like Java, COBOL, etc.? His answer was 10x. He's bold, but I believe him. My message to you is not too. Probably surprised you with that one. My other message to you is don't ignore his view. In other words, evaluate us, and most importantly, try it. The potential is worth the effort. And we want to work with you to make it even better.
My suggestion is this. As developers, look at delivering significant game changing impact to your organization. Leverage the new technologies that focus on that. Prove you can do it. In other words change the game.
At the end of the day, the more people that can innovate and do development, the better off your respective businesses and IT as an overall industry will be. [Read More]
Greetings. I thought to offer a perspective different from the ones provided by architects and system developers. Here you will read the idiosyncratic thoughts of a technical writer.
In sniffing the Web last weekend, I found a post from somone who was just learning about EGL and who had the impression that EGL is essentially an update to Cross System Product (CSP), circa 1990.
Let me give you an analogy. In the 1960's, Macy's wanted to build a department store in Queens, New York. The plan was likened to the city's Guggenheim Museum, which was designed by Frank Lloyd Wright. The Macy's building was to be more than functional; it was to be beautiful.
The firm bought most of the land needed, but could not sway Mary Sondek, an elderly homeowner who valued her residence more than she valued the money on offer. The Sondek house stayed. Macy's built a circular structure with a notch that broke the circle. The irregularity was there to accommodate someone who had an established right; but the building itself was modern.
EGL is like a circular building with a notch that accommodates those who wrote code with a predecessor language. Some aspects of EGL are there to allow migration of programs written with CSP, VisualAge Generator, or Informix 4GL. But EGL encompasses far more than those aspects. The language was architected for consistency and has a beauty that CSP never had.
And I should know. My first exposure to software generation was on the IBM project that converted CSP into a COBOL generator. At first, I was a technical writer, asking questions like "How do you spell MVS?" Later, I became a tester and then a CSP programmer and came to know quite a lot about software generation. EGL is a far cry from the technologies that preceded it.
In blog entries, I'll clarify aspects of the language.[Read More]
Hello there! It's been a very hectic few weeks here with lots of projects (some of which I can tell you about, some of which I can't... yet). I haven't been able to post as much as I had liked but I hope to be able to fix that over the coming months. I especially hope to give you some updates regarding the Rich UI and how that particular code works with the i.
To start with, I've managed to create end-to-end rich applications using nothing but the Rational tooling. These applications run from a Rich client in the browser written using the latest RUI release, through a web service written in EGL using RBD 7.1, to an RPG program written using RDi 7.1. It's fast and easy - the entire web service infrastructure, for example, only took a dozen or so lines. I'm looking forward to the day when all three components live together in a single workbench, but for now it's pretty easy. In fact, I run all three tools on my desktop at the same time in less than 1GB of memory (my Firefox and Thunderbird take up more!).
I've begun playing with the various widgets, including the Dojo widgets. I created a simple application that invokes a web service to get data and then shows that data side-by-side using a regular Grid object and a DojoGrid. I'm finding some interesting things about developing, including issues with the debugger and with passing complex objects (remind me to explain why you can't create a factory function that returns a DojoGrid).
All in all, it's been very interesting. Unfortunately, the real projects are taking most of my time, so I don't have a lot to share publicly this post, but I hope to be able to tell you more about some of those projects soon. And in the meantime, I'll try to keep updating you with what I've been up to. I see if I can figure out how to post my end-to-end HelloWorld application later this week.
Thanks as always for reading![Read More]
The stock market is down, COBOL caused it. Gasoline prices are up, COBOL caused it. Businesses and governments are not responsive? COBOL caused it.
See the attached link referring to the State of California? Titled: "California can't perform pay cut because of COBOL"; according to their Governor; http://developers.slashdot.org/article.pl?no_d2=1&sid=08/08/05/1816206
And over the last few years I've seen many more of a similar bent. Basically COBOL applications, developers, and infrastructures are the root cause of IT not meeting it's business requirements.
Are our business leaders, IT leaders, governmental leaders and publications - when discussing languages - out of their collective minds?
So some facts.
There are 2 Billion lines of COBOL code running worldwide large corporate businesses. There are 1.5 Million COBOL developers doing business development. Both according to Gartner Group. That's the positive.
Much of the COBOL business processing is delivered in older less changeable architectures of the past. That's the negative.
One person's conclusion. COBOL is a good business language. And COBOL developers are generally good resources. But at the end of the day - as noted in my other blog entries - it's about IT delivering value. And for COBOL only applications - and COBOL only developers - that's a problem today.
COBOL will be one of many languages forward. It's easy to write, and performs really well. Great language attributes. But it won't be the key language. Nor will the architectures of COBOL's past be the key ones either. COBOL is not great at Rich User Interfaces, and providing the front end of Web and Web 2.0 architectures - which will drive most design and development efforts. COBOL as a language is and continues to be relevant for business processing. So for delivering back end services in a service oriented architecture, it will be a key language. It's also unparalleled in batch processing which will continue to provide back end support for web applications. And many customers want to share transactional and batch processing as well.
I also believe COBOL as a runtime should be viewed independently from COBOL as a language. EGL can let us take advantage of the runtime positives of COBOL like high throughput, very fast access to data, and strong transactional processing in CICS, IMS, and other transaction managers. And EGL can also be used for the UI and front end part of the application.
People eat up lots of the IT cost structure. Reuse as well is much more important today - both due to cost of writing code as well as in meeting requirements for faster responsiveness. These modern architectures also promote reuse. No matter what the underlying language or languages.
COBOL developers will need to deliver value in new languages and infrastructures, like Web 2 and SOA, to stay relevant in overall application design activities. It's not COBOL that's the problem - it's about IT doing, or not doing, more. Blaming COBOL is ridiculous. Blaming those who hinder the endgame; won't change processes; won't get with the new economic realities on how we need to perform; is also probably not going to be productive. My message. For the COBOL developers - learn Web 2.0, do Web 2.0, make your mark. You're companies will do better with their revenues, you'll do better in your careers, and I won't have to read the any more nonsense about COBOL [Read More]