Businesses are utilizing Web technology to further system integration and business interoperability.
While IBM i computers traditionally have been standalone servers taking care of a company's internal needs, the past five years have seen a jump in the need for interoperability. Whether from mergers and acquisitions, partner mandates for integrated supply chains, or just a greater need for disparate systems to share data, Web services have emerged as a foundation that provides a common highway for disparate systems to work in harmony.
Essentially a set of standards that allows heterogeneous systems and processes to work together, Web services can offer the type of integration IT professionals have long wished for but rarely achieved. Nowadays, developers are tasked with increasing frequency to develop new Web services that will allow one application or server to work with another. What tools should they use? Where do they go for information? What is on the horizon in this emerging area that they should be aware of?
Along with Web services are even more rapid changes in Web application development with trends leaning toward a greater reliance on the cloud and an emerging interest in the potential of mobile applications supporting business. We devised a set of related questions we thought readers might be interested in reading answers to and then posed them to several tool vendors who work with users on the midrange platform. Below are the list of questions and the summarized comments several vendor experts shared during recent talks with MC Press Online.
- What are the driving forces in business today behind providing users with Web services?
- Is there more of a tendency to Web-enable existing legacy applications or to write separate browser-based apps?
- What are the tools most commonly selected to do the favored choice?
- Has connectivity to the IBM midrange platform(s) been a challenge, and if so, what help is on the way? If not a challenge, why so?
- What is coming down the road in the realm of Web services that we may not yet have seen?
- Where and when do security issues come into play? Any emerging directions?
- Where do mobile devices fit into the Web services matrix? Are mobile devices likely to generate much work for developers?
Marcel Sarrasin
Technical Sales Manager
Business Computer Design Int'l, Inc. (BCD)
A Web service is really two servers, whether IBM i or another platform, communicating with each other. In many cases, the end result will appear in a browser, but that doesn't have to be the case. A back-end RPG program can consume a Web service and perform functions on the data it receives without outputting data to a browser.
Web services have been around for a long time, and I would not consider this an emerging area. I would say it's just something that is part of Web development nowadays. It's not really any different from creating a Web page or Web application. The difference is that instead of the request being initiated from a browser and being displayed in the browser as the end result, a server instead makes the request, and then it usually receives an XML file, which it then parses. It can then output the parsed information to a browser or it may just save the information somewhere or perform some functions on it.
Our customers have been doing it for a long time, and it's been possible with our tools for a long time. Having said that, if you go back five years, not many people were doing Web services in our industry. Nowadays, we rarely get calls from people who say, "I need to do a Web service, and I don't even know where to start!" They tend to understand it now. We have functions in WebSmart ILE and WebSmart PHP to help them create Web services. Even last year we added new XML functions to make parsing the data easier because writing the code that will parse the XML files is usually where the time is spent.
Where a Web service is different from HTML is that it's XML data and there is a predefined structure to the file. Predefined structure means that it still uses tags for all the data. Let's say you have an XML request for some contact info—first name, last name, company. Well, those bits of information are going to have tags around them, predefined, that indicate they are first name, last name, etc.—whatever naming convention people are going to use. What happens is a company will publish that and state that if you want this information from their server (assuming that you are authorized), this is the format that it is sent in, and here is how you make the request. So it is a standardized way for all servers to send and receive data. You get an XML file, and here's first name, so you're looking for the first-name tag; OK, I have the first-name information right here. And so on. That's what we mean by parsing it out. So you can have multi-transactional data in one request, say 10 orders to add to your file and just parse to each individual one.
When someone asks us how to get started with Web Services we point them to our WebSmart reference guide and to the code samples on our web site. Then they just replace our code with their own sets of information and tags. Most people understand the concepts now, so it's just a question of learning how to do it. Should they need further understanding we can explain some of the higher-level concepts to them.
There are about five different types of calls we get on Web services, depending on what people want to do with them. These pertain to the following:
- UPS shipping costs when you're doing any type of e-commerce site; people want the shipping information before they make a purchase decision. What is always driving these things is that customers want a seamless experience. They don't care if the information is coming from UPS instead of the iSeries where the shopping cart is created and where the e-commerce application resides; they just want to know the shipping info before they make a decision to buy.
- Another area is when you have a credit card payment on a Web site. There are a lot of credit card gateways. If you don't have that support for a Web service, it means someone is making a phone call or you simply don't know if their credit card is authenticated.
- Another common area is from people who have e-commerce sites on different platforms. The bulk of the data is on the IBM i, but they may have a similar file on another platform of their e-commerce application. But they need real-time pricing and inventory availability information that is on IBM i so they can make a request in real time and, say, how many items are available and what the current price is. And that information will be coming from the IBM i. We always say, start from scratch and create the e-commerce site on the IBM i, but some people already have had a site elsewhere on a different platform.
- With an e-procurement solution, you can make purchases from different suppliers all from the same interface. However many suppliers you have, you make a Web service in your application. You may have a single Web application, but you have multiple Web service requests—one for each supplier—and the app pulls all their information together, so if you're the purchaser, you don't have to log into each individual supplier site. This also seamlessly handles the log-in and authentication; it's all built into the Web service. In this example, the end user benefits greatly from the Web service.
- Finally, your back-end RPG program can make a request, but you don't need a Web interface. Some people refer to a Web service as a Web API, and it is using HTTP to make the request, but it does not mean that there needs to be an HTML page. So that just means an RPG program can make requests. We have one customer that has a batch program that sends out requests to multiple places for shipping quotes and does it as a batch process. It requests a shipping quote for a described product, and then sends it to multiple places, and the servers send responses back with a quote. And there is never any Web interface. It allows RPG programmers to create Web services without needing to know how to code an HTML browser page.
If it's just Web services that they need, I would probably recommend WebSmart PHP, but that is always dependent on what their background is. If they're an RPG programmer, then I would recommend WebSmart ILE. A lot of people look at the two WebSmart tools as Web development tools, but you can also use them to create Web services. The distinction is small between what needs to be done between a Web page and a Web service, and we have two functions for making the request and receiving the request. And then we have the functions built into the product that parse the XML.
In terms of Web application development, what you're seeing upcoming, and it's not standardized yet, but we're starting to get some questions about HTML5 and CSS3. You do need the most up-to-date browsers to take advantage of the latest and greatest that HTML and CSS have to offer. Our clients are inquiring about them, but the first thing we ask them is which browsers their end users use. Many organizations do not use the latest browsers. We've discontinued support in our products for IE6; we have followed Google's lead on that. When we announced it, we had a few customers call us—but not many. What happened with most of them is they had older software packages—Web-based—but the companies that developed them aren't making improvements. Their position is, it runs on IE6, and that's it. In those cases we recommend that organizations allow their users to install additional browsers (Firefox, Chrome, or IE 8) which work much better with newer web apps and sites and take advantage of the latest web technologies and have better standards.
Web app development for mobile devices is slowly coming along in the IBM i market. Some people are asking about it, some people are already doing it, but most don’t have any real plans for it yet. It will definitely be a high growth area in 2011. It's one of those things that people are excited about, and there’s often a lot of useful information you can make accessible via mobile devices for customers' or employees' potential benefit. However, you still need to make a business case for it. If you have sales reps on the road that need information, and they are always on their smart devices, then yes, it's worth it. But if you haven’t even started making web apps part of your IBM i strategy there might be other areas of web development you should start with first. Web applications created by our WebSmart and Presto products can be accessed on mobile devices. While browsers on the latest generation of mobile devices can access any Web page, it is better to have web applications that are optimized for these devices. It’s very easy to add a couple lines of code to detect the type of device and resolution that are being used. You will want to design them differently such as not having as much data on the mobile versions.
I do think this is going to generate work for developers. It might not be this year for every organization, just as some were slow to get to the web in the first place, but I would not be surprised if within the next three years every organization has apps that are mobile-device-friendly. Hopefully most IBM i organizations are already focusing on HTML and Web skills which will greatly reduce the mobile device web app learning curve.
The question of Web-enabling versus writing a whole new app constitutes the area where I receive most questions today. Whether to Web-enable legacy versus write a separate browser-based app, I would say it's about an even split, and it's always on a case-by-case basis. We have a lot of customers who do both. The typical example is that you have a third-party green-screen app but you don't have the source, so you can't modify it. Instead, you are going to Web-enable that, but in the process, you can make some UI enhancements, and you can even add a little functionality if you so desire.
However, if somebody has a large internal application they have written, often they want to improve those apps or add functionality. You may want to make a major change to the application, and you plan to use this opportunity to improve it. What you can do is identify the most important screens—or programs—within the entire application and rewrite them with WebSmart and then Web-enable the other 80 percent with Presto, which instantly gives your green screens a Web GUI. So people are doing a combination of those two things, whether with ILE or PHP depends on whether they are RPG programmers or they need multi-platform with PHP.
You also get people who have a mandate: it's got to run on various different platforms. So that's an easy decision. We're seeing some really interesting things where they are doing a combination of the same thing in the same screen. For example, we had someone who Web-enabled a JD Edwards application. They expressed a wish to have additional fields in a screen. So what they did was use WebSmart PHP to write a call within the Web-enabled screen to grab information from the database and pull it directly onto the screen. To the end user, however, it's just one application; they have no idea that PHP is being used to retrieve other information. Such things can sound intimidating to developers new to the Web, but it's amazing what is possible for the people who take advantage of these technologies.
As far as emerging trends, the IBM trend is clearly business intelligence. We have Clover that serves that need, though people don't always come from that direction when they contact us. A few do, but they usually just talk about getting on the Web.
I saw another publication list 2011 trends, but I don't think they had business intelligence. I would have added that. If you look at the IBM Smarter Planet initiative, a lot of it is business analytics. We're well-positioned for that with Clover. Our tools are built for flexibility, ease of use, though Clover is a little different because it is also for the end user. In many cases, we give people the tools to create whatever they want as quickly as possible rather than a canned approach that might not have as much flexibility. We ask people, do you have a need for this— dashboards? Yes. Web reporting? Yes. They add, "Oh, yes, that would be awesome. The decision-makers would love that." Well, then take a look at this Clover product, we say.
Since flexibility is key, we like to say, OK, you're going to spend a little extra time, but you're going to be able to do anything you want as far as business intelligence or Web applications. Clover by itself is meant to be a DB2 Web reporting tool. But in early 2011, we're adding support for MySQL and Microsoft SQL Server, so you can access other databases.
We have clients who crunch data from different databases with our WebSmart products because those already support multiple databases from the same program.
Alex Roytman
Chief Executive Officer
We don't really view Web services as the technology to do Web applications. Web services are a standard for different types of technologies to work together, and that doesn't necessarily mean it's the right way to do Web applications every time. Sometimes there is a fit for it, but a lot of times, just because you're trying to create a Web application doesn't mean you have to dive into Web services.
Basically, Web services are way to have two different types of servers—two disparate servers—talk to each other. One server makes a request to another server using Web services and requests information. In the case of the IBM i server, it could be that the IBM i is requesting some information from another server, or it could be that another server needs some information from the IBM i. That's the definition of Web services that I go by.
Simply getting access from a browser-based device is just having a Web application. Web services are one server getting information from another server. There is a standard; there is SOA—service-oriented architecture—how you publish information, how you get information. One server might be running RPG code, another may be .NET, and there is a Web services standard, and they know how to talk to each other. It is used anytime you have an operation where you may have some data on the IBM i, and you have data on, say, SQL Server, and you want to present that on the same screen to an end user.
For modernization purposes, let's say you want to modernize your system or build applications that are going to work with your IBM i data. We think the right way to do it is right on the IBM i. Have the Web applications running on the i, rather than, say, build a .NET application and use Web services to go over to the IBM i and grab information. We continue to see this frequently within industries, but we think it is the wrong approach.
Way back in the days—and it's still done today—people would migrate data to a Microsoft server with the idea that somehow that Microsoft server could do a better job at Web application serving. But it's not really the case.
In fact, we have a recent customer who tried that approach using Web services and it took weeks to develop a very small proof of concept. Instead, it literally took a couple of hours of one of our guys on the phone to get the same application going with our technology that runs directly on the IBM i, where it has direct access to the resources and data on the system.
The browser can connect directly to a Web server that is running on the IBM i, and the IBM i just needs to send it back out through HTTP protocol in the standard HTML, JavaScript, and CSS. As long as the IBM i knows how to generate that in the appropriate format, and there are tools out there that do that for you (and we provide a tool that does that), then there is not really a need for Web services.
We view that as the more effective—and more cost-effective—way to build applications, but there are instances where Web services are the right method. Maybe you are already invested in another server in some way or maybe there is some information on the other server. In this case, the IBM i becomes the server that consumes the information. But for your typical shop, it's much more cost-effective to have the Web-serving technology right on the IBM i system. And the IBM i has always had that ability to host the Web application right on the server. Lately, with some of the things like RPG Open Access, those things have become even easier.
There may be vendors whose strategy is to hook their Web application on a Microsoft server. There are a few vendors whom we compete with that do it that way. There are vendors out there that have created the RPG language in the .NET environment, which to me is not the right way to go, and they may be promoting the idea of Web services more than we do. And I have nothing against Web services, but I think there is a right time and a wrong time to use them. Just because you want to get a Web application going, or even a mobile-device application going, that doesn't mean that there necessarily is a need for Web services.
We definitely see mobile devices as a future trend because we're already seeing a lot of that. Customers weren't concerned about them before, but today, they're more inclined to build things for the iPad and other mobile devices. As far as development goes, it's not identical, but it's similar to browser development. Even though each one of the different devices has used different standards, what is happening now is that they're all standardizing on the WebKit engine and HTML, CSS, and JavaScript. [WebKit, which powers Google Chrome and Apple's Safari, is a layout engine designed to allow Web browsers to render Web pages.] You can build it once, and if you do it the right way, it will run on all the different mobile devices that support WebKit.
HTML5 is an emerging standard and will include much that has to do with mobile devices such as an ability to work with touch-screen and detecting many new device features. HTML5 is still being developed, but the vendors behind the mobile devices as well as many browser vendors are ahead of the curve. They will have implemented a lot of the HTML5 features defined to date. But it's not in final form, and not everything has been defined, but a lot of things have. If you look at the iPad, it contains a lot of the HTML5 features, as does Google's Chrome browser. We hear that Internet Explorer 9 will have quite a bit of HTML5 compatibility. Even though HTML5 has not been finalized, the browser vendors and mobile device vendors are implementing HTML5 already.
For next year, mobile devices will be a significant trend. In the area of the iSeries and IBM i, naturally, I believe RPG Open Access will be big. It's a way to open up RPG. It opens up possibilities for modernization that were not possible before. You can tap into existing RPG code and modernize without a complete rewrite. It goes far beyond just screen-scraping for 5250 output; it's true modernization without a whole rewrite. I don't think that was ever possible before Open Access. For us, we're trying to capitalize on that possibility. Though not 100 percent perfected, we're to a point where we can actually take (and we've done it with customers' code) a pretty large system and convert the green-screen definitions into graphical user interface definitions while preserving the RPG code unchanged. We basically can unlock or untie the output from the 5250 data stream for a fairly large application, something that was not possible before. Previous methods were essentially screen-scraping, and if there were segments you needed to truly modernize, they had to be rewritten or handled as modules.
We're now working with a lot of customers, getting our solution out there so our handlers get exposed to different types of coding techniques; we have a tool called DDS Conversion [part of the Profound UI suite]. With DDS Conversion, you basically are operating at the source code level. You can take your old green-screen DDS source files and convert them into DDS source for rich display files—native IBM i objects that fully support a robust browser interface.
The tool eventually will support every possible keyword. We've made a lot of progress and now support close to some 80 percent of the different types of keywords—the most commonly used ones. Nevertheless, we're still encountering different types of keywords all the time, and so we're just perfecting that technology to where we think that, fairly soon, it will be close to perfect—or at least close to where, if you run it through a big system, there will be very few things to tweak.
DDS Conversion is an automated process that takes a green-screen definition and it converts it to a graphical user interface definition. Out of the box, the screens may still look similar to the original version, but there will be a number of automated enhancements. Basically, anywhere that you had an input field, you're going to have a text box; if you had a function key, you're going to have a button. But there will be some features that are much more advanced than what you can accomplish with screen-scraping. For example, assume you have a screen with a subfile listing records where you loaded 1,000 records. With screen-scrape technology, all you could show is one screen of those records at a time, and you're basically just paging through data. With DDS Conversion, you know that there is a subfile, and you actually have access to all those records. After you do the DDS conversion, you're still working with something that looks similar to the original green-screen, but it's now running in a browser. However, when you go to enhance and add new functionality, there is no limit to how large the screen is, to how much data you can put on the screen, or what the application can do.
I think Open Access, HTML5, mobile devices, and JavaScript rich UI will be significant trends in 2011. We've always seen the latter as significant but it seems that now everyone is recognizing that as well. The idea behind it is HTML5, a great concept, but when it comes to coding, we think that you should not be coding in HTML. We believe you should be coding at a higher level for business languages where the HTML is dynamic. We call it dynamic HTML, and that basically means there is going to be a client-side library that handles a lot of things for you. Many projects can translate into a lot of coding with HTML and JavaScript if you had to do them from scratch. In our environment, we have widgets. You put one on the screen, and here is my database, here are the fields that I want to tap into. It's a quick configuration and you're done with it. Basically, it allows things to sit on a smarter platform for business application development rather than coding things from scratch in HTML. We concentrate on IBM i and business applications. We want to be the JavaScript framework that people choose to work with rather than starting from scratch every time. Within our product set, we have over 125 different widgets, and we have a platform where, if one of our widgets doesn't provide something you want, you can build your own.
Kent Mitchell
Director, Product Management
I think Web services are here to stay, and I think in the midrange market, they're trying to figure out, "How do I expose all of this information that I have in my back-office system in some way that is safe, reliable, and doesn't require me to write some massive program?"
In general, one of the reasons why Web services is such a big trend—and I don't know how much this will touch the IBM midrange platforms initially, but eventually it will—but there are a lot of social media and Facebook-type apps emerging. If a company wants to provide information for people who are building these social media apps, then it will likely be through Web services. In the realm of B2B communications, these typically are heavier-weight SOAP-type Web services, but these new social media applications are moving toward lighter-weight Web services applications along the guidelines of RESTful services.
The interesting thing about PHP is that you can actually write a PHP application that will service all three options: You can write a Web-based application that presents the information in a browser, you can expose that same information instead of in a nicely formatted browser output, you can often take the exact same output, format it differently and return it as a RESTful service, and you even have the option of using something like Flash from Adobe to create even a little desktop Air application that talks to those Web services to gather the data and present it in interesting ways on the desktop. So you have the ability to create a wrapper around some existing RPG logic, existing information stored in the DB2 database, presented up in a number of different ways.
We have one customer, a company that does equipment rental. They had a sales team [that] needed access to an existing database and existing RPG application to authorize a transaction. Literally in a few weeks, they built a PHP application that presents information via Web services to a little iPhone app that they wrote. And they gave all their salespeople iPhones so they could basically pull up the information on the iPhone, put in the customer information, put in the equipment the customer wanted, get the authorization from the back-end systems, and process the order. That was something that before that they had estimated how long it would take to build this application. One of their developers said well, it can't be that hard, and he just built it in a week and a half. I think that is the power of Web services; in addition to rich clients, you can even have mobile devices on the other end. So there are a lot of trends toward that concept, and a lot of it is being driven by mobile devices. A lot of mobile devices will allow you to present a browser-based interface or a lightweight browser-based interface. So there is device detection; can you detect an iPhone versus a BlackBerry, etc., which makes a difference in what you present. And if you're going to write a true app for that platform, go out and write an actual iPhone application itself, it still needs to communicate to the back-end to get to that information. And again the classic way to do that is through Web services. That's what we see in general.
It all depends on what you're trying to do in a Web service. A lot of Web services out there are providing information. Maybe you need some basic log-in authentication to control [whether] the other person should or shouldn't have access to the information or not, so you're just exposing the Web service that anybody can access, but simple log-in credentials are pretty easy. It's pretty easy to do that kind of thing. If you're talking about something more sophisticated, like a business-to-business Web service, it's been one of the challenges for some time, or can we come up with a way to provide that level of rigid security that the IT administrators want but still provide the flexibility, and there are dozens of ways to handle that, all of which have their pros and cons. I don't think there is any magic bullet there, and I don't see anything on the horizon that is going to solve this in a magical way. But most of what you see in Web service security is simple authentication. Let's say I'm a salesman for the rental company, so I might have my own user name and password, and in the app I put in the user name and password, and it passes along through the request of the credential, and that information is used to authenticate that I should have access so that if someone just hits that Web service with a browser, it's not going to work because they're not going to use someone's user name and password.
That is one of the challenges we have in modernizing things with customers from the midrange space. There seems to be two kinds of security they are worried about, and they have never really had to worry about external security so much because it was a green-screen, so there is no external access, so a lot of times they're worried about internal security, which is protecting the machine from people who are actually authorized to access the machine. One advantage I think you have with PHP is that the PHP processes themselves can run as a particular user ID that has very limited access, so by definition, all requests can be funneled down to a very restricted access, and you can end up using the user ID and password access only when you need to access specific data at the database layer. So, in general, the process is safe, and if it needs to connect to the database under a specific user ID, it can do that. So you have the ability to still utilize the IBM i internal security within the Web processes. It's why a lot of people like it.
We see two major trends right now. There is an absolute explosion of mobile devices, so literally everybody is asking us for mobile support. There is a new release of Zend Frameworks that came out at ZendCon that has a whole bunch of mobile support built into it—mobile device detection, the ability to reformat output for different mobile devices, and you're going to probably see more of that over the coming year as that market matures, especially with the launch next year of many new products.
The second trend, and I don't know how much it is going to impact the IBM midrange space, is the cloud. It is the hot IT trend, it does have huge advantages for companies that experience seasonal or other event-driven traffic, and some of those companies are on midrange systems. I don't know how that is going to be handled, but there are a couple of companies now that are offering cloud-based IBM i services. I think it is going to be an interesting trend overall in the industry, but I'm not so sure how much of that will affect the midrange. In the IBM midrange market, what we're seeing is people really trying to figure out how to access the Web. And mobile devices seem to be hot for these people too. They may ultimately simply skip the browser era. They may go directly from green-screens…to smart phones, which is kind of interesting timing. They're finally moving to the Web and then skipping over an entire generation of technology.
In a lot of cases, what they're doing is exposing applications out to their own business users. For example, we have a hospital client that has issued tablets to all of their nurses as they walk around. They input the information into these tablets, and it's going directly into the back-end system. We've got this rental company that has its salespeople out there. It's a smaller device for them to carry around than an entire laptop. When they're trying to expose information out to their own people, it's almost better to go directly to one of these devices. In the case of more consumer-oriented things, I think you're going to see e-commerce sites, content management sites—things like that utilizing open source. Those will present Web-browser-based as well as mobile interfaces, but it is interesting that this one hospital [has] basically skipped the browser interface entirely. They have a browser interface that they use to test it in their labs, but all of their user community is using tablet-based computers.
The iPad era has changed the nature of how these services are delivered, at least in a few cases, and I think it's going to do so further. If you're a company today and you plan to equip the sales team so they can work on the road and don't have to return and sit down at a green-screen terminal or the equivalent—PC emulation software—then what are you going to give them today? Laptops? Other technologies? If I were a guy on the road and you were asking me to travel around and do a bunch of stuff and needed to access the data, or if I were a nurse walking around the hospital, I would much rather have an iPad than a full laptop. And since most of the heavy lifting is done by the back-end, you don't need the power of a laptop, and you can get by with something like an iPad or one of the Samsung tablets.
Roy Hart
Vice President, Business Development
Web services address silos of business information that need to be exchanged. B2Bs need to share and use information, and Web services are one way to facilitate publishing and consuming business information. It is interesting to note that in the medical IT world, one doesn't hear much about Web services versus HL7 interfacing; Web services have not been embraced there.
It is not a realistic scenario to "rip and replace" both code and data. However, keeping existing data is totally possible with certain tools that read existing data structures. For cost reasons, I think there is a tendency to want to leave as much of the legacy application as possible. However, many times additional functionality is needed, or a completely different UI is being requested, or a user-focused Web portal (such as for sales) must be implemented, or the current work flow does not meet the need, or there is a need for some new analytical reporting. That's where a modern tool can be used, but not screen-scraping.
GeneXus is a sophisticated IDE that has a lot of features for better programming versus the manual way. If the app is originally written in GeneXus, then it is easy to publish and consume Web services.
We have a feature called database reverse engineering (which builds a data view object) that reads the System i native files or the SQL tables directly, so interfacing with the IBM midrange platform should not be an issue.
What are new are RESTful Web services, but, as a practical matter, they are already here. This is the protocol that our tool is implementing with the new Smart Devices Generator. Web services are generally implemented with the SOAP protocol.
The explosion of smart devices is an important trend and needs to be addressed by IT shops. The demand for business apps on them is just starting. We are supporting multiple environments: iPhone/iPad, BlackBerry, and Android initially, then Windows Phone 7, now in Beta 1. By the end of January 2011, we'll see Beta 2. There will be two ways our customers will be able to develop for this huge market: as another generator within the IDE (like RPG, .NET, Java, etc.) and also as a SaaS GX IDE in the cloud (Smart Devices eXpress). So a developer can develop an app once and deploy it to multiple types of devices; it works directly with System i data stores.
Jeff Stevens
Chief Technology Officer
I'm not certain whether it is a trend, but in our case, I try to get rid of old code as much as possible. However, the old database structure and process is the part of a legacy system that I believe should be salvaged. There are times, of course, where parts of the legacy code are very important and should not be rewritten. But when developing a new presentation layer, I'm not big on trying to salvage old legacy code. This is where the GeneXus IDE helps so much. You can use the existing database structure, keep the data housed wherever it was before, and develop a new presentation layer for the browser and smart devices.
I use the GeneXus IDE almost exclusively because it generates Java or C#, and I can run it on Apache Tomcat or Windows servers.
It's really not a big problem connecting to data on the midrange platform. Setting up connections is tricky and not always well-documented. Expertise is difficult to find. We did finally abandon trying to use the IBM midrange platform as an application server in favor of Linux and Tomcat servers and just kept the IBM midrange as our data server.
I think more systems—data systems—will be housed in more than one server and in more than one format. For example, our transaction processing system and our Salesforce.com systems are housed in two completely different environments, but both are very vital to the success of our organization. However, both systems need to feed and take information from each other. That requires Web services on both sides: interfacing with existing Web services on the Salesforce.com side, developing our own Web services on our side. This same data system is seen in companies involved in mergers combining existing systems.
I think the larger mobile devices [i.e., iPads, etc.] will be used more in the browser environment. I currently have 13 iPads deployed, and, although we've looked at the actual smart-device-written programs, there are few that we actually wind up keeping. However, I think that on the smaller smart devices [i.e., phones], specialized written systems for that form factor will have to be done. But in our sales environment, I really don't see the phone being used as a smart device much anymore, as the iPads can remain with the individual about as readily.
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online