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 #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 #3: Checking and Debugging

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

Reason #3: Checking and Debugging

What vendors offering Magic  Software Migration based on conversion misconstrue is the benefits of the debugger and checker in Magic xpa. When you upgrade to the latest version of Magic xpa you get an enhanced checker and debugger that leverage the increasingly platform-based nature of Magic development in the last ten years.

Reason #3: Checking and Debugging

Application maintainability is greatly enhanced through superior checking, debugging and error logging. Remember, in C# there is no official cross-platform runtime so any notion of being able to debug a cross-platform application within a single IDE is out-the-windows, forgive the pun. But even worse, and even if you just plan to deploy in windows only environments, you basically find yourself having to write a ton of code in order to debug your code.

Contrast that nightmare with Magic xpa where when you are in Debug mode, you can run a program in Runtime mode and the Debugger will park on the Studio read-only screen at the exact location of where you are in the program when a breakpoint is reached.  

In the Magic xpa Debugger you can:

·         View breakpoints and variable values within the task flow view. Breakpoints enable you to halt execution of the program at a specific location in the Studio screen.

·         View the Magic xpa flow within the Studio using the Activity Monitor.

·         Set conditions for the breakpoints.

·         Create a Watch list that includes selected variables to be watched during runtime.

·         Update variable values during deployment. When you update a value in the Debugger, you are prompted to confirm recomputation.

·         View the flow from within the Studio.

·         View the call stack.

·         Switch between different contexts for debugging.

·         Dynamically handle logs using the Logging function.

·         Execute the Debugger remotely.

Magic xpa also has a good syntax checker, which will tell you if an object has any problems. The errors, if any, will be displayed in the Checker Result pane. You can control how these messages are displayed.

Checking and debugging requires extensive manual programming in C# and Java and misses out on the quality assurance features built into platform based computing approaches. 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.