Tuesday, May 17, 2011

Mobile Enterprise Application Platform: Any Device…

When choosing a mobile enterprise application platform, the ability to deploy to any device is an important consideration. While you may only plan to deploy to one or two device types today (such as BlackBerry or Windows Mobile devices), you will want to choose a platform that can give you the opportunity to deploy to Android and iPhone devices later on. But the “any device” issue goes much deeper than this.

Your mobile enterprise application platform should support the native user interface capabilities of the target device. In other words, a BlackBerry application should look like a BlackBerry application and an iPhone app should look like an iPhone app. Too many of the solutions being used today such as Citrix and Terminal Server are reminiscent of screen scraper technologies that were used for putting green screen applications on a Windows device. The device changed but the interface was essentially the same. Users became dissatisfied when they realized they had basically the same old application interface but just running somewhere else.

With Magic Software’s mobile offering announced today, you will be able to develop using a single paradigm and yet deploy natively to each target device. This is a major differentiator and key benefit for both developers and end users. Without Magic Software’s Mobile Offering, you would need to program in .NET Compact and Windows Forms for Windows Mobile devices, Java J2ME for BlackBerry devices, Java J2SE for Android devices, and Objective C for Apple’s iPhone devices. Magic Software’s Mobile offering leverages metadata to allow you to develop in a single development paradigm and yet it is deployed natively to all of these devices and you have the ability to specify use of the native look and feel.

For more information, please click here to download Magic Software’s Mobile Offering Technology Overview.

Friday, May 13, 2011

Mobile Enterprise Application Platform: Any App...

Enterprise mobility is in part a decision about “how to” develop and deploy mobile applications but it also involves serious questions about “what” applications to deploy. The fact that a good mobile enterprise application platform can make core enterprise software systems accessible remotely by a handheld device does not necessarily mean that all data and functionality should be exposed. Serious decisions need to be made about which data is accessible and which business functions are to be mobile-enabled. In this regard, it is important that you have all the tools in place to allow you to selectively integrate enterprise applications rather than simply providing wholesale access to your back end systems and processes.

With the announcement of Magic Software’s Mobile Offering yesterday, a new discussion of the importance of complex mobile business process and workflow was begun. See for example, the article in Dr. Dobbs Journal subtitled: “complex workflow support for mobile deployment of enterprise apps.”

Magic Software offers the mobile enterprise application platform you need to develop and deploy mobile apps and it provides the integration platform that enables connectivity and data interchange with your existing enterprise applications. Rather than engaging in extensive retooling of an existing application, you can use Magic Software’s iBOLT integration platform to automate the orchestration of data transformations, business transactions and application messaging with backend systems.

This automated approach to integration is the first step in reducing the effort required to mobilize any application. We then return our consideration to the mobile enterprise application platform itself. As a metadata engine, Magic Software’s uniPaaS application platform is a readymade business application engine containing prewritten technical and administrative functions and services. It frees the developer to bypass the intensive technical codewriting stage of application development and move quickly and efficiently to deployment.

The easiest way to grasp this concept is to see uniPaaS in action. The uniPaaS development environment is really a visual representation of application ‘assets’ and business rules stored in XML based ‘metadata’. This metadata business structure can be easily transferred from one deployment scenario to another (for example, Windows Mobile to BlackBerry) with minimal effort. And as discussed in our previous entry, it isn’t a matter of developing one core application and force fitting it onto various devices. Applications designed for iPhone and Android should have the unique look and feel of those devices. Instead, Magic Software’s Mobile offering allows you to customize your core business application for each device without having to refactor your core business logic or data structures.

For more information, please click here to download Magic Software’s Mobile Offering FAQ.

Monday, May 9, 2011

Event-Driven Programming

Event-driven programming in uniPaaS allows for the flow of the program execution to be triggered by events and handled in a desired manner. Event-based software development in uniPaaS is based on the very powerful uniPaaS engine.

The uniPaaS engine distinguishes the uniPaaS application platform from other approaches to application development and deployment. With pre-built capability to perform complex data manipulations that are transparent to the developer and end-user, the uniPaaS engine is key to the productivity and performance provide by Magic Software’s approach to application development and deployment.

The engine includes a set of operations for the developer’s use in creating applications. It also serves up a structure of execution steps called logic units, which work with the operations to perform tasks for the end-user. The developer doesn’t have to tell the uniPaaS application platform how-to do its job. The uniPaaS engine already knows how to perform such actions as opening files, reading records, sorting, displaying data on the screen, and more.

Contrast this with traditional 3GL and 4GL languages where the developer has to provide detailed instructions through program code to tell a program how-to implement each and every step, regardless of how tedious, repetitive they are. Programmers developing in Java and other languages get very frustrated by the fact that they have to repeat programming done hundreds if not thousands of times before by others. Many throw up their hands on the whole process of programming and say “Been there, done that” while others almost seem to enjoy being slaves to their code. By contrast, uniPaaS saves the developer considerable amounts of time by supplying these built-in operations and execution steps.

Naturally, the uniPaaS engine includes extensive support for event driven programming. Events, triggers and handlers are built in concepts. uniPaaS lets you define the uniPaaS logic as a response to implicit and explicit events that may occur during the execution of a task.

For the uniPaaS developer, an event is simply a logical definition of an occurrence. An event can be handled by an event handler to perform a flow of operations that the developer chooses. An event can also be assigned as a trigger of another user-defined event. When the triggering event is raised, it triggers the user-defined event. But uniPaaS isn’t just aware of events, it also allows the developer to handle events very specifically. In uniPaaS, a handler is a set of operations designated to be performed when a specified event is raised.

There are a number of different event types managed by uniPaaS.

System events are triggered by defined keystroke combinations. uniPaaS developers can define keystroke combinations for system events in a dialog box.

A uniPaaS internal event is usually handled by uniPaaS itself. But you can define a new or additional handler for these internal events.

Additional user events can be defined in the Event repository by the developer.

Timer Events within uniPaaS are based on durations, so that for every time interval of a specified duration, the event is invoked.

Expression Events are vents that are triggered when an expression evaluates to True. If the expression evaluates to false, then the event is not triggered.

Error Events are invoked when database-related errors occur such as a duplicate index or record that has been changed by another user.

ActiveX events are still used in some programs that use COM objects and Active X. An ActiveX event is raised for COM objects. If the event has built-in variables, they are created in the handler. It should be noted that ActiveX events are not supported with rich client tasks.

.NET events are preferred in rich client mode, where uniPaaS includes full support for .NET variables and events. When an event has built-in variables, they are created as parameters in the handler with the relevant .NET type. You can also define an event handler without defining a variable. In such a case, you can write the object from which you want to select the event.

uniPaaS events can be project-related events, triggered during the execution of any of the project's programs or task-related events confined to a specific task in which they are defined or to the task and its subtasks.

An event can have more than one trigger and more than one handler. Each trigger can raise the event in a different scenario. One or more handlers can handle the event for each scenario. This allows for complex event driven programming while avoiding the complexity of line-by-line coding. The uniPaaS application platform is available commercially from Magic Software Enterprises.