Reason #17: Magic xpa has a Built-In Licensing Mechanism

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

One of the deficiencies of C# as it compares to Magic xpa is that it lacks any sort of licensing mechanism. Licensing is important for software publishers who want to use Magic xpa to create and protect commercial software. It also provides an added measure of security and risk prevention to corporate software users. Licensing mechanisms help to prevent unlicensed software usage and therefore reduce the risk that a company can be sued for copyright and other violations. When considering migration of Magic eDeveloper to C#.NET or ASP.NET or Java (or uniPaaS or Magic xpa), it is important to consider your need for licensing mechanisms.

 Magic xpa’s built-in license-metering mechanism uses your local area network (LAN) to communicate between Magic xpa instances running on different machines on the network. As part of our ongoing commitment to comply with the latest and highest industry standards, Magic introduced a new policy for the activation of our software licenses in 2012. The improved process, implements a highly secure, automated method of license protection, enabling you to better monitor the use of your licensed software.

You activate and receive your licenses after validating your Product Key on Magic’s License Activation Portal. The metering mechanism helps organizations avoid any unintentional violation of the license. The license-metering module ensures that no more than the allowed number of connections uses Magic xpa concurrently.

Magic xpa includes a license management scheme. The license management system comprises three main components: a License File, which stores all the license information for a specific site; the Magic xpa Engine, which uses data from the License File to allow or prevent user access to an installed Magic xpa product; a License Server, which provides license information to the Magic xpa engine, and also counts the active users of the installed product.

Magic xpa offers three license modes: no license, demo license and permanent license. The Magic xpa License File, when initially created, contains a default demo license. This demo license has no time limit but is limited in its functionality and cannot be used for the development and deployment of mission-critical applications. Permanent licenses have no time limit. When you load Magic xpa with no license, essentially without specifying a license name, the Single User Edition will run.

The single-user limitation is relevant for both the development of the application, as well as its deployment. Magic xpa Single User Edition provides almost the complete range of features found in the commercial edition of Magic xpa, excluding multi-user related features and capabilities.

Magic xpa also includes convenient mechanisms for counting licenses and running floating licenses. To count licenses, you can run MGSTATIONS.exe from the Magic xpa directory to verify the license count of a specified license on a network.

Magic xpa's default behavior is that you have to define the number of licenses that each server uses during the execution of a project. This number is checked across all the servers in a multi-project environment to ensure that it is within the license limitation. For example, if you have a license with 20 threads, and you have two projects running in a multi-project environment, you have to distribute the threads in advance. Project A might receive 15 threads, while Project B receives 5.

In a multi-project environment, each server runs a different project. This means that the capacity of each server (project) is a key issue, and the ability to share licenses (threads/users) is very important.

Magic xpa's floating license mechanism lets you make optimum use of these licenses in a multi-project environment, by sharing licenses between servers. Therefore, when a particular project is idle, other projects can utilize its licenses.

Because the Magic xpa broker controls the servers and their capacity, it needs to know the total number of licenses that are available for its servers. The broker adds up the total maximum threads and users belonging to each server. The broker uses this figure as the total number of available threads/users. If the broker sees that a particular server is not using its allocated number of threads/users, the floating license mechanism means that they can be used by other servers.

Using C# to manually license software is a fool’s errand. Using C# to bind in a third-party licensing scheme is also very expensive and time consuming. The advantage of the Magic xpa Application Platform is that licensing is built-in to the platform as a protection to both corporate end users and software developers.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here.

Reason #16: Straightforward Security Management

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Magic greatly simplifies security issues for developers, giving them the power to create highly secure applications without a lot of hassle. This is another reason why Magic eDeveloper or uniPaaS to .NET migration via C#.NET is a mistake compared to upgrading to .NET with Magic xpa.

User rights management is simplified in Magic because the developer and administrator/supervisor use Magic xpa’s built-in Authorization System, Active Directory or LDAP. The Authorization System enables developers and certain users to control access to Magic xpa projects in Studio modes. This control is achieved through setting access keys to various Magic xpa project elements, and by assigning specific rights to users and user groups.

As a repository based system, Magic xpa is vastly superior to the tedious coding required for rights management in C#. The Magic xpa Rights repository lists the name and keys of all the rights defined for a project. The developer can define a bank of rights and assign them to the project's various repositories and elements. Any project element that has an access right assigned to it will be blocked to users who have not been assigned this right. Project-layer security is always defined during development.

In addition, Magic xpa includes a flexible authorization system to control what each user can and cannot do in Magic xpa. The authorization system lets the application developer or system supervisor limit access to various activities in Magic xpa to those users specifically authorized to have such access.

The authorization system exercises its control through sets of rights and the use of built-in Magic xpa functions. Rights can be thought of as keys to locks. Rights assignments connect users, who are classified by role, with the application’s components, which are classified by accessibility. This means that certain classes of users are allowed to access certain parts of an application.

The person in the role of Supervisor can assign rights that give each user access only to the activities for which that user is authorized. Any activity that is not specifically restricted by the Supervisor or the developer remains accessible to all users and does not require any rights assignment. To access the authorization system repositories, the developer must log on to the system as a user which has the SUPERVISOR GROUP assigned to the user. This group is reserved by Magic xpa, and is automatically included in any Magic xpa system. In addition, a Supervisor user (which has this group assigned to it) is also automatically included in any Magic xpa system.

Typically, when one is implementing a security system in Magic xpa, rights are granted according to the user’s job function, which corresponds to a Magic xpa Group. That is, a user who is a bookkeeper will have a different set of menus and screens than a person who is in Sales. Other rights, however, may only be granted to certain individuals, such as the ability to approve paychecks or adjust time cards.

Managing rights in C# can be like looking for a needle in a haystack. Instead of having to search through potentially millions of lines of code to find everywhere that a role is checked, Magic xpa provides a single, consolidated location known as the Rights Repository. What a nightmare it would be to have to parse an entire code base to learn and document what roles are assigned to what permissions.

For additional information on how an upgrade to Magic xpa is superior to Magic eDeveloper to .NET conversion please convert here.

Reason #14: Web Services

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Today's entry in the reasons not to convert Magic eDeveloper, uniPaaS, or Magic xpa to C#.NET code is Web Services. If you ask Microsoft how-to incorporate Web Services into an application, they simply refer you to ASP.NET. Why? Because C# is considered an unsuitable match for developing programs that publish or subscribe Web Services.

But let’s suppose you decide to be stubborn and persist in migrating your Magic Web Services to C# which uses a line-by-line coding approach.

In a simple example, just to pass a SOAP header, your C# code would look something like this:

<%@ Page Language="C#" %>

<asp:Label id="ReturnValue" runat="server" />

<script runat=server language=c#>

 void Page_Load(Object o, EventArgs e)

 {

  MyHeader mySoapHeader = new MyHeader();

  // Populate the values of the SOAP header.

  mySoapHeader.Username = Username;

  mySoapHeader.Password = SecurelyStoredPassword;

  // Create a new instance of the proxy class.

  MyWebService proxy = new MyWebService();

 

  // Add the MyHeader SOAP header to the SOAP request.

  proxy.MyHeaderValue = mySoapHeader;

  // Call the method on the proxy class that communicates with

  // your Web service method.

  string results = proxy.MyWebMethod();

  // Display the results of the method in a label.

  ReturnValue.Text = results;

 }

</script>

Here’s how you do it in Magic xpa: interact with the dialog box Header field.

Also, when consuming Web services (either by using the Invoke Web S or Invoke Web S Lite operation), the Magic xpa engine does a lot of work for us.

Magic xpa lets you call a Web service directly or uses the Systinet Web Services framework (named "Systinet Server for Java") for providing and consuming Web Services.

Magic xpa provides rich Web Services support including:

·         SOAP 1.1 and SOAP 1.2

·         WSDL 1.1

·         WS-I Attachments Profile 1.0

·         MTOM/XOP support

·         WS-I Basic Profile 1.1 Compliance

·         Transport level security – SSL\TLS

·         WS-Security 1.0 – authentication, encryption and digital signing of SOAP messages

Ask yourself this question: Is my company in business to write programming code? If writing code is not your business and not at the heart of the charter of your company, then why spend so much time managing code when you can manage applications that support your business instead?

For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.

Reason #12: Converting Magic to C# Leads to Loss of Portability

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

While it is tempting to assume that the need for portability is subjective, normalized standards for software quality do look at portability as a key component of software quality. If you convert Magic eDeveloper, uniPaaS or Magic xpa to C#.NET you suffer a significant loss of portability.

ISO 25010:2011 provides a standardized way to evaluate software quality by defining six sets of attributes by which we can evaluate software. These attribute sets are functionality, reliability, usability, efficiency, maintainability, and portability. So what do we mean by portability?

Portability, is the ability to run applications in new environments. This can also be impacted by the developer, and not simply by the tools used. Attributes of portability include  

• Adaptability
• Installability
• Co-Existence
• Replaceability
• Portability Compliance

The Magic xpa application platform and all previous Magic versions provide you a pathway to portability. Magic xpa currently supports Application Servers in all of these environments:

Microsoft® 32-bit Windows on Intel processors:

·         Windows XP

·         Windows 2003 (Standard Edition)

·         Windows Vista®

·         Windows 2008

·         Windows 7

·         Windows 8

Microsoft® 64-bit Windows on Intel processors:

·         Windows 2003 (Server Edition)

·         Windows 2008 (Server Edition)

UNIX

·         IBM AIX – 5.3 to 6.1 on PowerPC processors

·         Sun Solaris 10 on SPARC processors

·         Linux Red Hat Advanced Server 5.5 on Intel processors

IBM System I (requires PASE)

·         System i V5R4 on IBM servers with PowerPC processors

·         System i V6R1 on IBM servers with PowerPC processors

·         System i V7R1 on IBM servers with PowerPC processors

With Magic xpa, you have a software development environment for application development, testing, and deployment that enhances software quality through portability.

Portability in high-level computer programming is the usability of the same software in different environments. The prerequisite for portability is the generalized abstraction between the application logic and system interfaces, something completely lacking in C#. When software with the same functionality is desired for several computing platforms, portability is the key issue for development cost reduction. So portability has a number of benefits:

• Long-term viability of the application: There’s no need to completely rewrite your applications to make them usable from one version of an OS to the next or from one OS to another.         
• Resource allocation: With Magic xpa, developer resources can be focused on new features and products because developers aren’t spending time debugging for the latest OS version or porting applications to other operating systems.         
• Scalability: Portable software is inherently more scalable and can be designed to accommodate users elastically with either small or massive amounts of data.         
• Versatility: It’s easier to add features and have the assurance that they will run on all platforms.         
• Future-proofing your application: An application platform approach that supports multiple servers across different operating systems gives you the flexibility to adjust to changing future requirements including the new operating systems of the future. The new mobile client operating systems and Magic xpa’s ability to support these is a great example of the benefits that a portable application platform provides.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here.

Reason #8: Client-Server Interactions Must Be Programmed Manually in C#

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #8: Client-Server Interactions Must Be Programmed Manually in C#

We’re continuing our series of articles for those comparing migrating Magic applications to C#.NET or ASP.NET and the simpler alternative of upgrading Magic to Magic xpa, which is fully .NET based. Since so many Magic applications are client-server in nature, we need to consider what a client-server application loses when it is stripped of its platform.

Are you really eager to maintain a code base that is machine generated and that does something you’ve never had to do as a Magic programmer: manage low-level client-server communications? Creating a client socket in C# with ordinary .NET functions is messy, to say the least. And once you have the socket, you need to create an instance to get event-driven access to the data. Receiving data with  doesn't guarantee your messages arrive in one piece, though. So more manual programming is required.   You’ll need to program ways to keep messages together, for example you might create one suitable for simplistic text messaging and one suitable for arbitrary message-based communication.

So you’ll have to write programs that are also able to pass text with a suitable end marker, such as a new line. But what if a new line is a part of the data you want to pass? Oops, more programming. Now you’ll have to create handlers for data received in read events.

On the server side, you also need to be receiving and sending information (just like a client). But a server has to also keep track of who is connected to it. More programming. It might also be necessary to be able to broadcast messages, that is send them to every client currently connected. More programming.

You’ll also have to write (and/or maintain) code that gives you the ability to protect a socket, using encryption algorithms. More programming. You have to be able to pass an encryption type. More programming. How many encryption types might your application need to support? Oops. More programming for each one! Skip this step by just not telling your boss and you’ve taken a formerly secure Magic application and completely exposed it. Not good.

But wait we’re not done with discussing what you have to do and maintain for encryption in client-server communication layers. First, remember that the server needs to be able to send either a public or private key; because if the key is sent unencrypted, this is not very secure, but it does mean that the communication is not in plain text. The client will also need to generate a symmetric key and encrypt it before sending it to the server. More programming. This is the only way to be sure that the key is never visible to a third party and the connection is kept secure; to access the message you would need to break the encryption algorithm.

If you choose to use encryption in a Magic application, very little is different in your programs and nothing is needed to secure communication between the client and the server. However, in C# programming for your server, you’ll have to program a way for the server to know when the client is ready because the encryption protocols have succeeded. More programming. Otherwise, the client is called before key exchange is complete and the client is not ready to send and receive data. Do you really want to be responsible for maintaining all of this code?

If you attempt to send data to a client before it is ready, it should result in an exception. Similarly, if you want to send data through an encrypted client socket, you should be prepared to write code that will respond to a ready event or check an encryption ready property before even sending data. Stupid, useless (but absolutely necessary code) that the conversion generates by machine and you must maintain ad nauseum into the future.

Imagine in C#, just trying to create a basic server class - without the guts. You’ll need to write programs to create a TCP listener. (Have you got to the business logic yet? No way, not even close!) You’ll need this to wrap up the underlying socket communication, and open threads which will be listening for client connections. You’re also going to need to write functions that listen for clients and that can be used to manage the start up of threads. 

This function is going to have to start up TCP listening and then sit in a loop accepting connections. Oh joy, loop programming in C#. You’re also going to need a function to call TCP clients and these will have to be blocked until a client has connected, at which point you need more code to fire off a thread to handle communication with that new client. You’re going to have to write code that allows your thread firing mechanism to be parameterized too. Otherwise, how will you efficiently handle client communications?

I’m sorry, but I have to stop writing this article. We aren’t even one fourth of the way through discussing the kinds of programming required for client-server communications. Do you really want to be responsible for maintaining all of this? You and what programming Army? Right now, you do have a programming Army that protects you from all of this: it’s Magic!

For additional information on how an upgrade to Magic xpa is superior to Magic uniPaaS to .NET conversion please convert here. 

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

Some conversion vendors offering Magic  to .NET conversion won’t even admit that Magic v5-8, Magic eDeveloper, uniPaaS and Magic xpa don’t need to be converted to C# in order to become 100% .NET based applications. An Upgrade to the latest version of Magic xpa will take advantage of the .NET platform without locking you into a non-platform based language like C# that requires large programming teams.

Thousands of companies worldwide have made a clear commitment to an extended life for their Magic applications, as they represent solid, comprehensive, core business functionality within their companies. These decisions are congruent with the key Val IT principle that “IT-enabled investments will be managed through their full economic life cycle.” (IT Governance Institute, The Val IT Framework).

In this series of articles, we will review 10 reasons to upgrade rather than convert. Let’s look at reason number one.

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

By upgrading, you gain a platform with built-in component resource handling capabilities and maximum compatibility with your existing application logic. The Composite Resource Repository (CRR) in the Magic xpa Studio contains all of your objects for making calls to external components.

From the Magic xpa CRR, you can:

·         Reload a component interface or load a new component by selecting Load/Reload Components from the Options menu. When an ECI file is loaded or reloaded, Magic xpa checks the component type defined in the interface and changes the Type property of the CRR accordingly. This would require extra manual programming in C# or Java.

·         Invoke a wizard that will both create a component that connects to an external resource and create the component’s interface. This would require extra manual programming in C# or Java.

·         See the component interface by zooming from the Name column.

·         Assign rights to a component. This would require extra manual programming in C# or Java.

·         Use the Locate mechanism to locate a specific component type. This would require extra manual programming in C# or Java.

If you convert older Magic applications to C# or Java code instead of upgrading, your business logic is stranded or isolated and has no access to the Composite Resource Repository. Regardless of whether you currently deploy Magic v5, Magic v6, Magic v7 or Magic v8, or even a later eDeveloper of uniPaaS application that has not yet taken advantage of the Composite Resource Repository, upgrading is a more efficient way to leverage your Magic application and modernize your application. All development becomes manual in C# and Java and loses the significant inherent advantages of platform based computing. For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

Before you get into the thicket of C#.NET, ASP.NET or Java programming, you might just want to consider how much more difficult it is to deal with transactions in these manual languages than it is with the Magic xpa Application Platform. These 3^rd Party Vendors offering Magic Software Migration services forget that you are going to need to write your own code in C#.NET, ASP.NET or Java to make up for the transaction capabilities of the Magic xpa Application Platform.

Business applications frequently require transactional programming techniques. How easily one can program a transaction depends on the language and platform. The Magic xpa Application Platform enhances the .NET platform making it possible for Magic programmers to create transactions with significantly less effort than C#, ASP.NET or Java developers.

Transactions are an integral part of developing data-bound applications. A key to developing applications in a database environment is the ability to optimally use transactions to ensure data integrity.

The word “transaction” is used very often when discussing SQL applications. A transaction is an integral part of a process, contributing to the composition of the whole application, and it can be defined as the execution of a set of logically related data modifications, which must be committed (completed and written to disk) or aborted as a single unit.

This means that either the entire process succeeded or the entire process failed. There is no middle ground. Several operations such as UPDATE, DELETE and INSERT may create a single unit. Only if all the operations are successful, will this logical unit be successful.

A transaction process may be an entire business logic process or a smaller unit that is part of a business logic process.

Transactions can be used to secure Read operations, as opposed to Read/Write operations. A Read transaction ensures that the data read within the transaction is not modified by other users.

The transaction processing technique automatically logs all of the updates of a transaction to a temporary transaction file. The updates in this file are cleared only when the transaction is complete, that is, the updates to all the regular database tables have been completed successfully. If a problem is detected in any of the tables affected by the transaction, the entire transaction is canceled and the database is rolled back, that is, restored to its original state before the transaction occurred. The rollback uses the information stored in the Transaction Log file to restore the project.

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

There are many challenging issues when implementing transactions using C# or ASP.NET. The first problem is isolation. The volatile resource must adhere to the isolation property of ACID, lock the underlying resource it manages, and prevent access by multiple transactions. However, C#.NET and ASP.NET only offer thread-based locks, which prevents access only by concurrent threads, not concurrent transactions. The second problem is state management. The resource manager needs to enable the transaction to modify the state of the resource and yet must be able to roll back any such changes if the transaction is aborted.

Magic xpa offers extensive transaction-handling capabilities that avoid heavy manual programming efforts in C# and Java. For additional information on how an upgrade is superior to  3^rd Party Magic Software Migration conversion please convert here.

Reason #2: Cost Savings

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #2: Cost Savings

One of the logical fallacies put forward by vendors offering Magic  to .NET conversion is related to the idea of cost savings. When you upgrade to the latest version of Magic xpa you get full access to the .NET platform without all of the manual programming overhead that a non-platform based language like C# automatically entails.

Cost reduction is easily demonstrable in the upgrade from Magic v5-8, eDeveloper and uniPaaS to Magic xpa. Magic Software offers an ROEI Assesment Document to help you calculate the savings made possible by an upgrade versus the significantly higher (order of magnitude) costs associated with converting an application and maintaining it into the future.

Reason #2: Cost Savings

In narrative form, these cost savings can be summarized as follows. First, Magic xpa yields development productivity increases when creating new components, features and enhancements to your Magic application. Second, given the improvements in the development capabilities in Magic xpa, the costs of maintaining or modifying the application vs. C# or Java are reduced by as much as an order of magnitude.  Third, as it is faster to implement Web services, development time and cost will also be reduced with Magic xpa vs. C# and similarly tedious languages. Magic xpa differs from older versions of Magic in the way it implements and consumes Web services. Fourth, by eliminating the need for a database to store code/instructions (Btrieve) , you can save costs by moving to Metadata / XML. It also improves performance for the application & developer.

If you convert older Magic applications to C# or Java code instead of upgrading, your business logic requires manual programming to implement all of these improvements. No one knows this better that the companies who have made the mistake of converting. Their hiring patterns since converting their applications show a marked increase in the need for non-Magic developers. Not only does this leave Magic developers looking for a job, it ends up costing these companies a fortune to hire two to three times more developers to maintain an application in a non-platform environment. Upgrading is a more efficient way to leverage your Magic application and modernize your application. As stated previously, all development becomes manual in C# and Java and loses the significant inherent advantages of platform based computing. For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.

Reason #1: Superior Developer Productivity versus C#, ASP, or Java

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #1: Superior Developer Productivity versus C#, ASP, or Java

I'm starting a series of articles for those deciding between Magic eDeveloper or uniPaaS to .NET conversion by upgrading and Magic eDeveloper or uniPaaS to machine code generators to C#, ASP or Java. The topic for today is developer productivity.

Many longtime followers of the advantages of Magic development will recall that Magic developers repeatedly won the international development competitions of the 1990s. Not only did Magic teams win multiple years in a row, they also were winning every place in the contests. They had to stop having the contests because the advocates of defeated languages stopped showing up. Why bother? Magic developers had proven themselves superior in all respects.

Everyone knows that the environments for the development of business applications have grown increasingly complex in the two decades since those amazing victories. And while it is tempting for followers of C#, ASP and Java to try to put forth claims that they have caught up to Magic’s development capabilities. The reality is that the gap has widened. As environmental complexity has increased, the Magic paradigm of platform based metadata development has become even more essential to development efficiency.

To understand this, one needs to consider the COCOMO II Model of software estimation perfected at the USC Center for Software Engineering. (Go Trojans!) The COCOMO II model can be simplified as follws:

Effort = (Team) x (Tools) × (Complexity)^(Process)

The concept is fairly simple. As you increase the number of developers (team), effort increases. As you increase the number of programming languages needed (tools), effort increases. And as you increase the functional requirements of the application to be delivered (Complexity), effort increases. The relationship between these three components of effort is factorial. Why do you think third party companies are offering so many different conversion paths for Magic (C#.NET, ASP.NET, Java, etc.)? Because to replace all of the development capabilities of Magic require not one new tool but an entirely new set of multiple tools. Migrating to .NET by converting to .NET with a  code-generator instead of migrating to .NET with an upgrade to .NET with Magic xpa will create a bubble in the center of the COCMO II formula above the number of tools needed for enterprise application development goes from Magic xpa to:

·         C#.NET            or Java J2EE for Server Side Apps

·         ASP.NET or Ruby on Rails or PHP for Web apps

·         Java J2ME for BlackBerry client apps

·         Java J2SE for Android client apps

·         Objective C for iPhone and iPAD client apps

·         Microsoft Silverlight or Adobe Flex for RIA clients

 Now consider that you can accomplish all of the above with one toolset: Magic xpa Application Platform. The Magic xpa Application Platform can create client-server apps; Web apps; BlackBerry, iOS, and Android mobile apps; and RIA apps. Magic xpa = all of the above. As a result, the value of “Tools” in the COCMO II model is 1. In essence, Magic xpa adds zero effort.

Lest you conclude that you should just stay with eDeveloper or some older version of Magic, however, let me remind you that Magic xpa is a huge improvement over eDeveloper. In essence, upgrading to Magic xpa brings the value of Tools to less than 1, further reducing effort.

Magic xpa introduces development productivity enhancements that dramatically decrease new function development time, and increase maintainability for existing functions. These are only a few examples of the many enhancements developers enjoy when using Magic xpa:

o   New IDE look and feel – By grouping dataview and logic statements under different tabs and allowing collapsible code snippets, developers find it easier to navigate the code

o   Functions – By enabling developers to create functions, developers can create cleaner and leaner code, increasing reutilization of code snippets.

o   Debugger – The new enhanced debugger allows stepping through code, adding break points, variable watches, and real time debugging, dramatically enhancing maintainability and bug fix delivery times.

o   XML integration – By exposing XML files as data sources, Magic xpa enables developers to consume and provide web services, completely removing the need to read, write and analyze XML files.

o   The Project File – Magic xpa utilizes XML source files. This creates a faster development environment, eliminates the need for a RDMS system to manage code, and enables usage of standard version control systems.

o   Web Services – Magic xpa differs from eDeveloper in the way it implements and consumes web services, to facilitate an enhanced web service offering Magic xpa leverages Web Services standards for SOAP and RESTful Web Services.

o   SubForms – The subform is a new UI control in Magic xpa which revolutionized the way developers create, develop, design and call subtasks.

o   Argument Matching – Magic xpa has full argument matching on task calls and automatic parameter creation on event handlers which eliminate code syntax errors

o   Line Level Comments – Allow eliminating inline documentation, therefore enabling cleaner and more readable code without forgoing documentation and allowing hint and developer help creation,

o   Studio and Runtime Separation – Allows developers to test application crashes without breaking the development studio therefore creating stronger and more robust applications.

o   Multi Tasking – By allowing parallel execution of programs, Magic xpa allows developers to create a productive user interface for application customers.

o   .NET Controls – Magic xpa is fully .NET based therefore creating a better looking and native looking user interface for the application customers.

For additional information on how an upgrade to Magic xpa is superior to Magic eDeveloper or uniPaaS to .NET conversion please convert here.