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 #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 #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. 

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.