So, if you're writing your own RPG version of the proxy, then you have to do all that bundling and unbundling. Then you have to invoke the target service. I, however, skipped that. Since I have control over all the pieces, I extracted the actual business logic and re-wrote the target service to call the business logic. Then I added code in the proxy to call the business logic directly.
It's not quite as complicated as it sounds and it works really well as a proof of concept. I can now say with certainty that it is entirely feasible to write a complete, Java-free EGL Rich UI application, using only RPG as the back end.
I'll clean up the code and export the project (including a savefile with the RPG code) in the next day or two.[Read More]
The developerWorks Connections Platform is now in read-only mode and content is only available for viewing. No new wiki pages, posts, or messages may be added. Please see our FAQ for more information. The developerWorks Connections platform will officially shut down on March 31, 2020 and content will no longer be available. More details available on our FAQ. (Read in Japanese.)
Matching: business_logic X
JoePluta 100000KMX3 Tags:  i rich_ui example egl rpg business_logic rui web2.0 soa richui eglcafe 2 Comments 9,790 Views
JoePluta 100000KMX3 Tags:  example i business_logic rui rich_ui rest rpg soa richui eglcafe 8,424 Views
Okay, I'm now in the pre-flight phase of version two. I'll leave V1 alone for the time being, although I may circle back to it later in order to investigate other pure client-side issues. But I want to get right to the core of what's important to EGl and i, calling business logic on the i. The purpose of V2 is to address the issue that EGL Rich UI requires WebSphere (or some other web application server) to run.
That's simply not the case. Rich UI handles both SOAP and REST service calls, which means that it talks to anything that does either of those. Most platforms can create SOAP services. The problem is that SOAP is over-engineered bloatware; the correct answer is to use REST.
Unfortunately, I don't have any examples of using pure RPG-CGI as either a SOAP service provider or a REST service provider. I could use the wizard provided with the standard i5/OS web administration tool to create a "Web Service Server" but that's still a SOAP service. I'm going to try a sidetrack to write my own code that will provide a simple REST response.
As always I'll be relying on groundwork done by others, in this case I'll probably be reviewing and probably liberally re-engineering code from Craig Pelkie and Scott Klement, as well as making use of Chris Laffra's service monitor. I'll need all the help I can get, because this is completely untraveled territory.
Wish me luck - I'll get back to you in a day or two.[Read More]
JoePluta 100000KMX3 Tags:  rpg rdi i application_modernization egl soa business_logic eglcafe 6 Comments 8,954 Views
I haven't been posting this month because I've been really busy getting ready for iSeries DevCon. This is one of the best technical conferences, although you might consider me a little biased; in four days, I give one all-day jumpstart (this year on migrating from PDM and SEU to RDi) and then 10 sessions and hands-on labs. It's always been a forward-thinking conference; I did sessions there on Eclipse and Visual Age for Java (Eclipse's predecessor) as far back as 2001, along with some of my first web-enabling sessions.
Since then, they've always been ready to present the latest technologies and so this year I gave what I'm pretty sure was the first hands-on EGL lab at an i technical conference, along with a number of other sessions and labs ranging from multi-tier architecture development to extending Rational tools with Eclipse plugins. My session on Eclipse, WebSphere and Rational was repeated, and even though the second one was in the last slot on the last day, we still had good turnout.
In the i space, EGL has to deal with all the buzz surrounding PHP and MySQL. To me, that buzz is nothing more than white noise because PHP just doesn't stand up to EGL when it comes to ease of use, adoption of advanced technology and integration - especially with the i. As a simple example, PHP's connection to the i involves using a PHP knockoff of IBM's Java toolbox, and while the toolbox is phenomenal technology, using it directly requires a lot of code; a simple program call might require dozens of lines of code. With EGL, it's a simple CALL statement. And when I demonstrated how easy it was to build entire applications using RDi-SOA to write EGL front ends and RPG back ends, people started getting excited. In a simple 90-minutes lab attendees with no prior Java experience were able to create an EGL record, build a JSF page, then flip over to the RSE perspective to compile the RPG business logic, and then back to the EGL to add a few lines of code to attach the two.
I also did a lab on multi-tiered architecture without EGL (using plain old JSP and Java) and the people who attended both really got an understanding of what EGL was all about: simplifying the plumbing. Even the simplest web application requires a significant amount of plumbing code in any 3GL, whether it's Java or PHP or RPG-CGI. EGL removes all of that for you. Not only that, but the very nature of the language makes it easy to reuse code, so that once you've created a JSF client, it's simple to turn around and create a rich client or a web service. I think that really hit home with a lot of the attendees.
Anyway, I'm back now and I'm focused on the Rich UI book. You'll see a lot more about that in the coming weeks. It's good to be back, and thanks for reading![Read More]
JoePluta 100000KMX3 Tags:  eglcafe i egl application_modernization business_logic rui_tips rui 7,520 Views
I can't think of a better title for this, but since I hope this becomes an ongoing series of posts, I want to make sure I stick a number in there. Maybe I should have made this one Number 0, because it's going to be sort of an introductory post, but that's okay.
This blog series will be based on things I find as I'm writing RUI applications. It will range from little things like tips for formatting (using a class to right-adjust grid columns) to major RUI topics such as how to implement services in a modular architecture (the answer is Delegates, but the devil is in the details).
Because of the book, I've already got a list of topics on hand. In fact, as I write the blog posts you'll get more glimpses into the book writing process. But I can give you a few quick previews. For example, I'm becoming pretty proficient at formatting Grids. This is important stuff for those of us in the i community; the Grid is the replacement for the subfile and it's crucial to being able to build applications quickly.
Another thing that comes into play is the fact that all the HTML for a RUI page is generated at runtime. Because of that, it's difficult to see the actual HTML which in turn makes it hard to diagnose CSS issues. I've figured out a way around that. I hope to make a generalized widget available soon, but I will at the very least post some example code. The trick is outerHTML...
Anyway, I'll be back posting more. Let me know if there are areas you need addressed.
JoePluta 100000KMX3 Tags:  i application_modernization business_logic egl rdi eglcafe rpg rbd rui rws 1 Comment 10,383 Views
No, seriously, what I mean is this is the next generation of posts on the RUI topic. A month ago I wrote that some exciting stuff was in the works, and now I can tell you about it. This will actually be a short blog entry - I just want to let you know what's coming.
Briefly, I'm writing a book. The book is going to be about using RDi SOA to build EGL Rich UI applications with the i. EGL Rich UI is the "formal" term for RUI, and if you haven't played with it yet, you should get yourself down to the alphaWorks site and get a copy (and yes I know the page says EGL Rich Web Support, but I have it on good authority that EGL Rich UI is the official name).
The book will show how to build a Rich UI interface using EGL and then connect that to a business logic back end written in RPG. Every step of the way will be written and debugged using Rational tooling.
And those of you who read my blog will get an inside look into the process of writing a book. It may inspire some of you to try your own hand at it. Those of you with clearer heads will run screaming...
Anyway, that's the short version. This ought to be an interesting project...[Read More]
JoePluta 100000KMX3 Tags:  business_logic rpg i egl eglcafe application_modernization 4 Comments 8,202 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]