Reason # 18: Distributed Application Architecture

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

Magic xpa Application Platform utilizes a Distributed Application Architecture that offers a high level of choice between different computing environments. The interoperable nature of Distributed Application Architecture also means that Magic xpa applications have the ability to operate in multi-database, multi-platform, and multi-network data processing contexts. Using the simple interface common to all Magic xpa applications, every user, from any workstation, can access any type of local or remote database, execute queries, and update the data. As we shall see, Magic xpa Application Platform provides capabilities for distributed architecture, application partitioning, MDI, and secure communications out-of-the-box. When converting Magic eDeveloper, uniPaaS or Magic xpa to C#.NET, these advantages are lost.

In an environment where multiple computers are connected by a Local Area Network (LAN) or Wide Area Network (WAN), Magic xpa’s distributed application architectures automatically utilize a specific form of distributed processing.

Fortunately, when you install Magic xpa, you don't have to know how the distributed application architecture is set up, however you can adjust the settings if desired. The diagram below illustrates what is happening behind the scenes in Magic xpa's distributed application architecture.

The process begins when a client, such as a browser or Rich Client application, makes a request to the enterprise server. It does this via a requester, usually a Web server. Each client has its own requester.

The requester uses the broker to communicate with the Magic xpa enterprise servers. This is a Magic xpa Runtime engine (MgxpaRuntime.exe) functioning as an enterprise server. The broker scans its list of prioritized servers to find a server that is not busy and informs the requester which engine is available. If all the engines are busy, the event is added to the broker's request queue.

Once an engine has finished handling a request, the Runtime engine sends the request results directly to the client and notifies the broker that it is available to process the next client request. A check is made if there are pending requests in the queue which are for the same application as the one loaded in the Magic xpa engine. If there are pending requests, the broker extracts the requests with a higher priority and sends it to the engine.

The term application partitioning is used to describe the process of developing Magic xpa applications that distribute the application logic among two or more computers in a network. In the simplest case, the application can run on a single PC, as a remote service, and send task requests for execution to a server. In more advanced cases, the application logic can be distributed among several servers.

The first step in creating a partitioned application is choosing which components of the application run on the server system or systems. The criteria for making the choice are the components that would most benefit in performance and maintainability, if they were to run on the server. Note that the decision whether a program or task runs in the Requester Client or in the system need not necessarily be made when the application is designed, but the design must take this into consideration as only background-mode tasks are applicants for partitioning.

In Magic xpa, background enterprise servers and Online programs are multi-threaded. This gives you the ability to have parallel task execution in your projects.

Each thread accesses a different Runtime context, and does not interact with other threads. To work with multiple threads in Online programs, Magic xpa provides you with Multiple Document Interface (MDI) and Single Document Interface (SDI) functionality.

Communication between the Magic xpa client and the Web server (requester) is compressed while communication between non-Magic xpa clients (such as Web clients) and the Web server (requester) is not. The Magic xpa developer secures these communications using the https protocol. The https protocol (SSL\TLS) encrypts the communication between the client and the Web server and ensures that the server is a trusted one.

Communication between the requester, broker and engine is encrypted using Asymmetrical and Symmetrical encryption. No hard-coded keys are used and it is possible to define the Symmetric encryption mechanism and the key length.

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

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 #15: Magic xpa Surpasses C# in Interoperability for .NET

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

The Magic xpa Application Platform is a particularly strong platform in terms of interoperability of applications. While C# .NET is designed to be proprietary, Magic xpa Application Platform, while .NET based, is designed to deliver greater interoperability. This is one of many reasons why converting a Magic eDeveloper, uniPaaS or Magic xpa application to .NET in C# using a code generator makes no sense. 

Developers looking for fully .NET applications should instead upgrade to Magic xpa.

That’s why Magic xpa provides direct support for technologies like Java, SNMP, MSMQ, JMS, WebSphere MQ, LDAP, Active Directory, Java Script, VB Script, Client Certificates, Dynamic Data Exchange (DDE), IMAP, POP3, etc. All of these internal Magic xpa functions provide direct support for technologies that are otherwise quite difficult or impossible to support with C#.NET. 

The ability of a single programming environment to interface with so many different, unique and tedious environments at a high-level provides tremendous advantages, reduces risk and helps to future-proof your applications. For example, Magic xpa provides direct  Java support including support for Java classes and objects called in a Magic application and Magic applications exposed as Java classes and objects for use by Java programs. 

The idea that C# can handle a converted Magic application is ludicrous. Sometimes developers have no choice but to deal with older technologies like DDE. So even though you might be able to convert your code, without the Magic engine, there is no automatic way for raw C# to handle DDEs.

Let’s look at another simple example like SNMP. Magic xpa supports Simple Network Management Protocol (SNMP) functionality. This lets Magic xpa programs and the Magic xpa engine (the broker and the requester) send SNMP compliant messages to a monitor. It also gives the system administrator control over various Magic xpa modules via an SNMP monitor.

SNMP governs network management and monitors network devices and their functions. Magic xpa is SNMP enabled, so the Network Management Station (NMS), also referred to as an SNMP monitor, can query and manage the Magic xpa broker (including its registered enterprise servers) and the Magic xpa broker can report traps (alarms, failures, or other exceptional events).

Messaging is another great example of Magic’s superior interoperability compared to C#. In distributed applications, two different applications often need to communicate with one another to transfer information. One of the ways to accomplish this is message queuing, which ensures guaranteed delivery.

Message queuing lets applications send messages without waiting for a reply and to continue with other processes. Other applications can receive the messages at their leisure and continue processing according to the data received.

Message queuing is a method by which program instances can exchange data using an interface to a system-managed message queue, which is managed by the operating system. Application programs create message queues, and send and receive messages using an application program interface (API).

There are two main ways to send messages:

Send / Receive – This is used when there are one or more senders who want to send messages to one receiver. Each message is addressed to a specific queue, and the receiver extracts the message from the queue.

Publish / Subscribe – This is used when there are multiple senders (publishers) and many receivers (subscribers). The publisher sends messages to a central location, the topic, which sends the messages to anyone who has subscribed to this specific topic.

Both of these methods provide the user with guaranteed message delivery and are supported out-of-the-box with Magic xpa. Not so with C#.

Every access to the message queue is done using a set of functions, such as open, close, and send. Magic xpa provides a message queuing component with interfaces to three standard messaging queue systems: MSMQ (Microsoft), JMS, and WebSphere MQ (IBM). C# does a passable job only with MSMQ.

For additional information on how an upgrade to Magic xpa is superior to Magic 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 #5: Upgrading to Magic xpa reduces risk versus C#, ASP, or Java

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

Reason #5: Upgrading to Magic xpa reduces risk versus C#, ASP, or Java

As Magic customers rely on applications to support key business functions, it is important to ensure that the application resides in the latest fully supported versions of Magic technologies.  The choice for those running applications between Magic eDeveloper to .NET conversion and Magic eDeveloper to C#, ASP or Java conversion is an important decision fraught with risk.

IT risk identification, management and response is a key concern for all enterprise IT departments. Senior executives and management have a responsibility of “Assuring investors and shareholders that a ‘standard of due care’ around mitigating IT risks is being met by the organization.” (IT Governance Institute, COBIT 4.1 Framework, 2007). In an enterprise environment, there is considerable risk in working with unsupported architectures, and this risks non-compliance with federal legislation and SOX guidelines.  In fact, our Fortune 500 customers tell us that the upgrade to Magic xpa is essential to maintaining SOX compliance. We have to note that Magic’s platform is just one piece of the overall architecture of the business computing environment, and as other components of the architecture change, it is important to ensure that all components are compatible.  Hardware, Infrastructure, Operating Systems and Databases that come in touch with Magic Applications, are constantly changing by their respective vendors, and evolving irrespective of the computing technology in use.  Most of these vendors tend to have limited life spans on their deliverables and the needs of a complex computing environment require prudent upgrades of these components.

Reason #5: Upgrading to Magic xpa reduces risk versus C#, ASP, or Java

Infrastructure changes are driven by a number of factors: 1) Lack of available parts for older hardware may lead to BIOS, processor or other incompatibilities; 2) Operating System versions that are under cease-of-support and end-of-life conditions; 3)  Enterprise IT mandates and “green” initiatives; 4) Change-of-behavior or discontinued features in databases, middleware and other components. Indeed, upgraded operating systems and database versions often provide tremendous advantages in terms of performance, integrity and security.  Should an infrastructure component upgrade be unsupported by the older application platform technology, there is considerable risk that business operations could be disrupted:

a)    Because the unsupported component may cause the Magic technology to become unpredictable, or cease to work altogether.

b)    Because an older component may fail and it may be difficult to source an older compatible replacement.

c)    The older the version, the less the likelihood of available service-level agreements, warranties, support or the human resources knowledgeable about older technologies and problems, this can lead to delays that may take a long time to diagnose and/or resolve.

d)    Development work may increasingly involve complex workarounds and fixes;

e)    Production system down time can increase to unacceptable levels, up to and including complete system failure.

Magic applications are often part of a larger Corporate Enterprise Application Portfolio; it is important that your applications do not become an “island”, with no ability to interact with newer technologies.  The latest versions of Magic xpa 2.x are constantly being updated to take advantage of newer emerging technologies and standards to ensure interoperability with other industry standard technologies including .NET.

Both risk and cost savings are compelling reasons to ensure that all elements of your Magic applications will be utilizing the latest technologies from Magic Software. The IT Governance Institute suggests that the goal of risk response is to “Ensure that IT-related risk issues, opportunities and events are addressed in a cost-effective manner and in line with business priorities.” (IT Governance Institute, Enterprise Risk: Identify, Govern and Manage IT Risk, The Risk IT Framework Exposure Draft, 2009.) The problem with converting to C#.NET, ASP.NET or Java is that they all increase cost and risk. There is much more effort after the conversion to maintaining an application with large programming teams required to accomplish what could be accomplished by a single Magic developer before. Costs skyrocket with the code-centric approaches, risks mount as unending communication cycles are generated by those trying to figure out what the machine generated code does, and bugs spread across the code-base as developers unfamiliar with the language or the business logic introduce new issues and risks that are simply not present when upgrading.

But the time to upgrade is now (actually its way poast time, but not too late). Magic Software removed support for eDeveloper 9.4 in December 2009, while eDeveloper 10.2 was superseded by uniPaaS; and uniPaaS is now superseded by Magic xpa 2.x. 

The importance of moving from eDeveloper 9.4  to Magic xpa in a timely manner, and continuing to leverage the investment made in  Magic applications is only magnified when considering the risk your company is exposed to when not fully migrated to Magic xpa and .NET.

As many businesses continue to expand their vision of a fully integrated Service Oriented Architecture (SOA), Web Services, RIA, SaaS, Green IT, etc., the importance to the business of using the latest Technology Stack available demands high visibility.  The success of your IT team in the eyes of internal business customers depends on your reputation for deployment on Magic Software’s modern extensible platform, Magic xpa Application Platform, which can become an integral part of your enterprise’s world-class technology architecture.

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