The New Magic Software Application Platform and the .NET Framework: The Best of Both Worlds

The new Magic Software Application Platform, uniPaaS 2.0, implements a new .NET deployment engine, which turns any existing uniPaaS application into a native .NET application. According to Microsoft, the .NET framework is comprised of a Common Language Runtime (CLR) that provides an abstraction layer over the operating system; Base Class Libraries that deliver pre-built code for common low-level programming tasks; and development frameworks and technologies offering reusable, customizable solutions for larger programming tasks. The new uniPaaS 2.0 engine uses the Windows Forms .NET library as the GUI front-end for applications. To be clear, Windows Forms is the name given by Microsoft to the graphical application programming interface (API) included in the Microsoft .NET Framework. Windows Forms provide access to native Microsoft Windows interface elements by wrapping the existing Windows API in managed code. uniPaaS 2.0 seamlessly leverages this capability to provide superb RIA and client/server GUI capabilities. In fact, uniPaaS 2.0 provides full integration with the Microsoft .NET framework to significantly enhance application design, functionality, and overall user experience. uniPaaS 2.0 also offers new RIA-related enhancements.

With uniPaaS 2.0, Magic Software will soon be offering its first Mobile Enterprise Application Platform with support for devices running the BlackBerry OS or Windows Mobile 6.5 as a client deployment platform immediately and both iPhone and Android in the near future .

In a press release last month, Magic Software Enterprises (NASDAQ:MGIC) included a quote from a Microsoft product manager regarding use of Magic Software’s integration platform for SharePoint integration. With the release of uniPaaS 2.0, it becomes clear that Magic Software is now even more closely aligned to leverage underlying Microsoft Windows and .NET framework technologies.

In fact, one might even say that uniPaaS 2.0 is a .NET programming language (just as one might also say that it is an IBM i programming language or an AIX programming language or a Linux programming language). So the difference is that last week you could only really say of uniPaaS 1.9 client/server programming was that it was a Windows programming language. Now, one can see Magic’s application platform as fully supporting and being fully supported by the .NET framework. In this sense it can sit alongside Visual Basic.NET and other .NET programming languages for Windows servers and clients just as it can sit alongside RPG and COBOL for creating IBM i server applications, etc.

The good news for enterprise IT departments that have adopted .NET application development as an enterprise standard is that uniPaaS 2.0 now meets (and even exceeds) the requirements for being a .NET framework application platform. This is good news because unlike existing .NET languages, uniPaaS supercharges .NET in a way that no other approach can.

How does Magic Software’s uniPaaS 2.0 application platform turbocharge the development and deployment of business applications? First, uniPaaS accelerates the development on .NET framework application by providing straightforward and streamlined development methodology that further abstracts the development process without sacrificing control. Then, it stabilizes the performance and operational integrity of applications by leveraging our proven, highly scalable application platform technologies.

This release is just another example of Magic Software's long history of providing solutions that protect your applications from the underlying changes in operating system , client, server and other technologies. By future-proofing your business applications with the use of the Magic Software application platform, you are able to outperform your competition and surpass all expectations for your ability to adapt to whatever changes the future may bring. To learn more, please access these resources.

Take A Load Off: Use RESTful Web Services in uniPaaS

Take A Load Off: Use RESTful Web Services in uniPaaS

We’re pretty good at keeping "well-guarded" secrets at Magic Software. Sometimes we even release useful new features that few people know about. We made a lot of fanfare when we started supporting Web Services based on the SOAP protocol. In fact, I think I wrote the press release back in January 2002.

Here we are nearly 10 years later and uniPaaS now supports REST (Representational State Transfer) approaches to Web Services and few of us paid close attention when this feature emerged in the product with the release of uniPaaS 1.9e. But it is worth paying very close attention because RESTful Web Services can be accomplished without the complexity and overhead of SOAP Web Services.

REST isn’t something new at all. In fact, it is the way the Web has worked all along but with some rules added to help everyone get along.

What are RESTful web services?

Baiscally, a RESTful web service is a simple approach to web services implemented using HTTP and based on the architectural principles of REST. A RESTful Web Service has three resources defined:

• the URL address for the web service (you may call it a URI if you want, it is basically the same thing). The URL is the equivalent of a noun.
• the supported Internet media data type of the web service.
• the set of HTTP operations supported by the web service. Think of this as the verb.

The following table shows how the HTTP methods are typically used to implement a web service.

Unlike Web Services based on SOAP, there is no industry protocol for RESTful web services. In this sense, it is akin to a concept like Service Oriented Architecture (SOA) where a number of different approaches and protocols can be used to accomplish the objectives of the architecture. RESTful Web Services are based upon established W3C and OASIS protocols such as HTTP, URL, XML, etc. The REST architectural style is based on the idea that a client and server are interacting in a stateless manner with cached data via a uniform interface.HTTP 1.1 was designed to conform to REST. Unlike SOAP and XML-RPC, REST does not really require a new message format. Nevertheless, XML is the most popular type of REST message format. When you use XML, it becomes easier to represent the information resource in a variety of ways using XSLT and Cascading Style Sheets (CSS).

In uniPaaS 1.9e, we improved upon the ability of uniPaaS developers to employ RESTful Web Services by adding a new function: HTTPCall. This function may be used with a proxy server and supports SSL\TLS with the client certificate password protected and both basic and digest authentication schemas.

HTTPCall runs an HTTP request and returns the results. You can consume REST services by using HTTPCall with any and all verbs. This function can be used instead of the HTTPGet and HTTPPost functions, thereby simplifying implementation of RESTful Web Services in uniPaaS. The syntax within uniPaaS for the use of HTTPCall is as follows:
	HTTPCall (verb, service URL, message, [header1], [header2], …)
	The “verb” is a string indicating the method. The options include GET, POST, PUT, DELETE, and HEAD. You can GET a list or a specific member of a collection. POST is like an append operation in that it adds a member to a collection. PUT replaces an entire collection or a specified member of the collection. DELETE erases the entire collection or a specific member of the collection. HEAD is a header that provides additional header information. The “service URL” is the string that represents the HTTP address where you will retrieve the HTTP request. The HTTPCall function can easily pass a user name and password to the service URL for a secure, rights-based approach to Web Services. For example, when a uniPaaS client is accessing a web server that requires a user name and password, the URL should be HTTP://User:Password@[URL]. uniPaaS will also support secret names by following this approach: HTTP://%user_secretname%:%pass_secretname%@[URL] Obviously, the “message” is a string with the text of the message. There is no limitation on the message content. Messages are self-descriptive and stateless. The use of “headers” is strictly optional and you may include as many as needed. Each header may contain a string that provides additional header information as requested.
	As one might expect, the HTTPCall returns a BLOB containing whatever information results from the HTTP request. If the function fails to make the connection, a blank value is returned. You can get the response headers using the HTTPLastHeader function. Magic Software provides both Online and Rich Client sample programs that detail the use of the HTTPCall function. Look for sample programs EL23 and REL23 to get an idea of how this function can be implemented. One of the traditional disadvantages of REST is that it doesn’t do well with complex data architectures such as those of relational databases. In this regard, using uniPaaS allows you to bridge the gap between REST and traditional databases. With uniPaaS, information is exchanged and represented using RESTful Web Services while at the same time you can store enterprise data in industry standard databases. REST advocates will simply say databases are too complex and should change to conform to the way the Web works. With uniPaaS, you avoid that argument altogether. It just works.

Mobile Enterprise Application Platform: Any Time

Ten Key Questions to Help Compare MEAP Vendors

Comparing mobile enterprise application platforms (MEAPs) can be challenging. Quite often those that are seeking a MEAP solution do so precisely because they do not want to invest in developing in-house expertise in all of the programming languages and environments required to provide native client solutions for major mobile device environments such as BlackBerry, iPhone, Android and Windows. The IT departments ability to anticipate the challenges of each target device environment is often limited due to lack of familiarity with the differences in all these environments.

To complicate matters more, MEAP vendors are rarely what they appear to be. It is first of all necessary to try to separate out current capabilities from future plans in the vendor roadmap. One must then ask, what is the vendor history in living up to the promises in their roadmap?

Even once you have all this sorted out and have separated out marketing hype from actual platform capabilities, the task of making comparisons gets tricky. Is device management a necessary part of the evaluation, or should we consider that a separate category just as we consider development tools and IT operations software as separate systems in the data center? Evaluators need to carefully consider their own rollout plans versus the vendors plan for device support.

More important than any of these tangled issues, however, is the question of productivity. The reason for adopting a MEAP is to reduce effort. In order to live up to the need to develop and deploy mobile apps at anytime and anywhere, you need a MEAP that is truly metadata based, employs fully native clients, and has seamless capability to develop and maintain enterprise data center, enterprise cloud and enterprise mobile apps without duplicate programming efforts.

Here are a few key questions to ask a MEAP vendor?

1. Are native coding skills required to complete projects or make changes? Some MEAP vendors surprisingly do not complete the process of creating the mobile app for the target device. Manual programming and tweaking is required.

2. Will we need to use the native debugger to test our applications? If the MEAP forces you to debug their deployment capabilities on a target device, then you that means you are likely to be required to write code to fix any problems you find.

3. Can my MEAP platform also create desktop, client server and web applications? Some MEAPs are mobile only and have little or no capabilities for supporting other types of applications. This lack of support means duplicate coding for those environments.

4. Does the MEAP platform allow me to control the look and feel of the application so that I can develop with a native look and feel for each device? Will BlackBerry apps look like other BlackBerry apps? Will an iPhone app look and feel like an iPhone app? etc.

5. Does the MEAP platform vendor have a solid track record of back-end integration? Do they have a complete set of integration tools to allow you to integrate enterprise IT systems, data and processes with your MEAP platform? Integration to backend systems is a crucial component of providing B2E, B2B, and B2C applications. Without a straightforward solution for integration, you may end up spending months of unnecessary development time trying to integrate your mobile apps to existing enterprise systems.

6. Is the solution multilingual and can the vendor provide multilingual support? If you need a global solution, some vendors have limited reach in North America but not beyond.

7. How long have you been in business? Too many vendors are in startup mode with no guarantee that they will stick around.

8. Will you provide financial statements showing your revenues, profitability, cash on hand and debt position? If a vendor is unwilling to provide financial statements, then you are at significant risk that you may be dealing with a vendor that is on the brink of imminent financial failure.

9. Does the MEAP vendor have a parent company whose objectives are different from those of the independent software vendor that it acquired? If the parent company acquired the MEAP platform to serve the needs of its larger client base, will that be at cross-purposes to your needs?

10. Does the MEAP vendor have a coherent strategy for enterprise systems, mobile apps and the cloud? Can the vendor ensure that all of these solutions can be based on the same service-oriented architecture (SOA)? Is the platform capable of compositing existing application logic from Java, .NET, COBOL, RPG and other environments? A good MEAP platform will be capable of leveraging all that you have today and have a coherent strategy for deploying solutions in all of the environments that you need to be in tomorrow. A vendor that can future-proof your efforts will ultimately be the smart choice for development of mobile apps.

Once you have a satisfactory sense of what your vendor can offer, the question of how it is licensed and priced is appropriate. Some vendors adhere strictly to a per user pricing strategy. Others offer a per server pricing model. Some offer both or a hybrid. If you are developing a B2C enterprise mobile app, then per user charges are unappealing. But if you have a fairly small target B2E or B2B audience, then hefty per server pricing may be disadvantageous. In the final analysis, you will need a vendor that is willing to work with you to assure complete satisfaction and success. Evaluate vendor technical support, training and professional services. All these things combine to make the selection of a MEAP platform a difficult decision. But if you know the questions to ask, you are on the right track. To see a video announcing the Magic Software Mobile Enterprise Application Platform (MEAP), click here.

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.

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 ready‐made business application engine containing pre‐written technical and administrative functions and services. It frees the developer to bypass the intensive technical code‐writing 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.

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.

Comparing uniPaaS and Java: Can’t We All Just Get Along?

Recently, we conducted an interesting challenge with uniPaaS Jet. We asked an independent developer already familiar with Java programming and having no previous uniPaaS experience to download uniPaaS Jet, learn it and create a simple program using uniPaaS Jet. (We had earlier asked them to create the same program using Java.) We asked them to take careful notes of the resources required and the effort involved. uniPaaS proved itself more efficient in every category. uniPaaS used half the memory and half the file storage. uniPaaS required barely 1% of the logical lines of code and 7% of the physical lines of code. The uniPaaS program executed for the first time in 1/10th the amount of time. The applied effort was 202 hours in Java and only 3.2 hours in uniPaaS. The project duration was 2.63 months in Java and part of a single day in uniPaaS.

Our purpose in reporting these findings is not to engage in Java bashing or point out Java weaknesses, in fact uniPaaS is very Java-friendly. We have some Java developers in our R&D department. And most important we believe uniPaaS can offer much to Java development teams to provide them with tools that can take advantage of their investment in Java while providing them the kind of advantages experienced by the independent developer mentioned above.

The Java Integration built into uniPaaS allows uniPaaS to interface with a Java class or Enterprise JavaBeans (EJB) by using pseudo-references that represent instances of Java classes or EJB files. Pseudo references are an identifier representing the values from a class instance in a BLOB variable. Programs must pass this identifier to access the methods and variables of a class instance. A Java class is a template definition of the methods and variables in a particular kind of object. An object can be a specific instance of a class and can contain real values instead of variables. For integration to Java classes by a uniPaaS application, you can access static methods and variables without the pseudo-reference.

Java instances, static methods and variables are invoked by uniPaaS’s Java and EJB functions. In Java, a class instance is a specific implementation of the Java class while a static class method is a class method that can be called without instantiating the class. Likewise, a static class variable is a class variable that can be accessed without instantiating the class.

An Enterprise Java Bean (EJB) is an architecture for defining Java program components that run on a client/server network. The uniPaaS EJB Component Generator is a wizard that generates a component containing uniPaaS programs that call a Java class or EJB functions. A Java Native Interface (JNI) lets non-Java programs interact with Java programs. The Java Component Generator is a wizard that lets uniPaaS automatically access Java classes or EJB files by creating a component that eliminates the need to specify JNI signatures. You can also use uniPaaS to generate Enterprise Java Beans (EJBs). Clients operating within a J2EE environment are able to view and activate uniPaaS programs as EJB methods. You create the EJBs using uniPaaS’s Component Builder utility.

uniPaaS can create an instance of a Java class that lets you activate a method, or query and update variables using a pseudo-reference. The pseudo-reference is a BLOB variable that represents the Java class instance. When a method is invoked, the BLOB variable returns values to the uniPaaS program as function return codes. Class static methods and variables can also be accessed without having an instance of the Java class by using the class name and the method or variable name.

The uniPaaS Java functions are used to simulate the calling methods in Java. Each context of the engine internally maps between the pseudo-reference and the actual reference.

For example, a uniPaaS program can call the JCreate function to create a pseudo-reference as Virtual Variable A. The actual reference to the instance is then internally associated with Virtual Variable A. Any uniPaaS program in the context will be able to access the methods and variables of the object by using JCall(A,...).
The Java functions can be called by a uniPaaS program to:

• Create a new instance of a Java class
• Call a method directly from the Java class or from an instance
• Report and return exceptions
• Query and update variable values

The EJB functions enable uniPaaS to explore and invoke Enterprise JavaBeans.

I think the important message here is that uniPaaS can help Java programmers make efficient use of Java classes and EJBs while benefitting from the efficiencies of uniPaaS’ smart application development platform. For additional information access the Magic Software DevNet or contact your local office.