Wednesday, February 22, 2012

Nothing but .NET




Okay, so I just like the headline.
The uniPaaS 2.0 deployment engine supports genuine native .NET deployment of uniPaaS 2.0-based applications as native .NET applications. The new uniPaaS 2 engine uses the Windows Forms .NET library as the GUI front-end for applications, resulting in a richer user experience. This fundamental new basis for the client side container provides full integration with the Microsoft .NET framework to significantly enhance application design, functionality, interoperability, and overall user experience regardless of the underlying server operating system (Windows, Linux, UNIX, or IBM i). uniPaaS 2 provides the Magic, .NET, and Java composite application functionality all from a single highly productive and easy-to-maintain platform. Both the Magic uniPaaS Application Platform desktop deployment client and the Magic uniPaaS Application Platform RIA deployment client are fully native .NET based applications. For .NET applications, the uniPaaS 2 deployment engine is a native .NET client, and all uniPaaS applications that are deployed using it qualify as standard .NET applications.
This means that with the release of uniPaaS 2.0 as a genuine native .NET-based product, a whole new and exciting world of .NET controls and services has opened up to developers. The enhancement of .NET integration capabilities provides more functionality and improved productivity. Among the .NET integration features are:
·         Variable Binding: Enables the binding of a uniPaaS variable to a .NET control.
·         Dataview Binding: Directly connects complex data-bound controls such as grid controls to the dataview definition of a uniPaaS program.
·         .NET in Table: Enables placing of .NET controls as automatically repeated controls inside a uniPaaS table control.
·         Colors and Fonts Assignment: Enables direct assignment of the uniPaaS colors and fonts setting to a .NET control.
·         Container Controls: Enable placing of uniPaaS controls inside third-party .NET container controls.
As we begin to see all of these capabilities rolling out into your applications, you have none of the hassle of traditional 3GL or 4GL development and all of the benefits of the .NET architecture. Perhaps the headline is right, you don’t have line-by-line tedious programming, you have nothing but .NET.

Tuesday, February 21, 2012

Elastic Scaling: Don’t Snap the Rubber Band if You Want Software Load Balancing




In today’s over-hyped cloud computing market one hears terms such as “elastic scaling” being applied to capabilities for software load balancing. Load balancing is a term applied generically to any of a variety of computing methodologies in a distributed network whereby workload can be distributed across multiple computers or servers for the purpose of achieving optimized throughput, response times and resource utilization. Additional benefits in the form of greater reliability through redundancy and “failover” techniques are often closely associated with software load balancing.

Here in the Magic of uniPaaS blog we talk frequently about the differences between standard 3GL and 4GL approaches to software development and deployment versus the benefits of an application platform such as Magic Software’s uniPaaS application platform. Load balancing is a subject with rather significant implications because of the relative complexity of accomplishing load balancing without an application platform.

If you look at a cloud computing platform such as Amazon Elastic Compute Cloud (Amazon EC2), you see that significant additional effort is required to achieve load balancing through the use of approaches such as Round Robin DNS or add-on software such as HA Proxy. In fact, Amazon says specifically that “Applications that require a persistent connection to a specific database or backend server are generally incompatible by default.”

 

But what if you had an application platform with built-in load balancing capabilities? That’s where the Magic uniPaaS Application Platform performs exceptionally well and can help you achieve the real potential of cloud computing.


For simple load balancing you should have at least two uniPaaS Enterprise Servers connected to the same Broker with the same application. The Broker will balance the load between the uniPaaS servers automatically.

A new option was added to the Magic Request Broker’s load balancing mechanism that will distribute the load evenly between runtime engines according to the percentage of executing threads out of the maximum number of threads allowed for an engine.

You can implement more complex load balancing by starting several different uniPaaS servers on several different machines. In addition, you can give each server a different priority level by setting the Options->Settings->Environment->Server->Load Balancing Priority.
uniPaaS provides a middleware agent known as the Magic Request Broker. The Magic Request Broker, also referred to as the broker, maintains the pool of available uniPaaS Runtime engines.
When a Runtime engine loads, it registers itself with the broker. Each subsequent engine also registers itself with that broker.
When the broker loads it starts listening on its defined port. The broker handles a list of all the available uniPaaS Runtime engines and directs each request from the uniPaaS Internet requester to the available Runtime engine for execution.
Each Runtime engine can handle more than one request simultaneously, each in its own thread.
The request broker provides load balancing and recovery capabilities to handle any fail over.
The main functions of the Magic Request Broker are:
·         Queuing client requests
·         Allocating available runtime engines for requests
·         Logging all operations
·         Maintaining and distributing the status of all submitted requests
·         Activating programs in asynchronous (No Wait) mode
Usually, when you install uniPaaS, you don't have to know how the distributed application architecture is set up. However, sometimes when working with a Rich Client or Browser project, it can be helpful to understand what is happening behind the scenes, so that you can tweak some of the settings. The Magic uniPaaS Application Platform has this built-in ability to control the way the application platform implements load balancing. So if you seek true elastic scaling, consider the Magic uniPaaS Application Platform as your foundation for cloud computing applications that are truly scalable with software load balancing across n-tiered architectures and distributed computing networks. 



Wednesday, February 8, 2012

Encore! Encore! Is it Time for a Little Sequel in Your Magic Applications?




 Migrating a flat file or Btrieve type application to the Magic uniPaaS Application Platform using a SQL database can deliver an organization numerous benefits.  Structured Query Language (SQL) databases provide an enterprise class data platform for use in business applications. Most developers would agree that SQL databases are preferred for enterprise-class business applications developed on the Magic uniPaaS Application Platform. Why?

SQL provides: a more robust data functionality to support business requirements such as OLTP and data warehousing; higher levels of security for mission-critical applications; the ability to apply business rules from within the database; and support for increased levels of transaction activity.

Because SQL is a popular concept used in databases such as MS-SQL, DB2 and Oracle databases, it is widely supported by a variety of data management, business applications, reporting and business intelligence tools. Not only are connections to other systems simplified, applications built on SQL are more future-proof than other applications. Standardization on SQL makes it easier for an organization to manage its data regardless of its use context.

SQL databases provided an advanced environment for data security that can be achieved through high level tools.In addition, identity management and control over information access is simplified through SQL across multiple applications.

In general, SQL is better suited to very large database sizes and maintains a higher degree of transactional integrity and operational reliability. In other words, it is less likely to crash. Data integrity can be maintained on the database level and metadata is more easily tracked for purposes such as audit logs.

While there are costs associated with most SQL databases, there are also express or light versions of SQL databases available for more cost-sensitive applications.

Most Magic uniPaaS Application Platform installations rely upon SQL as their primary database, in part because SQL can deliver database level functionality not inherent to other approaches:
·         Sequence and identity mechanisms are included in SQL databases for better multi-user application functionality.
·         SQL statements provide functionality for better application maintenance such as version updates, updated field definitions, table structure conversions, and added fields and indexes.
·         The Where clause is a powerful feature of SQL databases that allows for advanced filtering.

Because SQL can incorporate logical transactions at the database level, use of stored procedures, and an object-oriented methodology, it is often viewed as a superior choice for all sizes and types of applications.





Monday, February 6, 2012

Mobile-to-Mobile Integration in the Cloud



The Super Bowl is over so it’s time to kickoff a super idea: “mobile-to-mobile integration in the cloud.” We’re all thinking about it but we’re just not saying it: the current end game is to have millions of mobile apps on billions of mobile smartphones all integrated via the cloud. The IT department will consist of one person, the CIO, who outsources all IT functions to a team in India/ China/Brazil /Ukraine/Tanzania (you choose), who implements the CIOs ideas based on a series of virtual use case interviews on a bunch of transparent virtual machines up in the cloud. Every pertinent interaction and piece of data created and consumed on one user’s smartphone is instantly and securely available as needed by all other players in the business process. Far fetched? Do you disagree that this is where we are heading?

When you think about it, Magic Software’s applicationplatform, mobile offering and integration platform combined with its planned cloud offering have all the components needed to make this happen, except of course for the cool as a cucumber CIO that it would take to have the guts to implement a strategy like this. The coming metadata world is so highly virtualized that it’s possible to use the world’s best infrastructure without owning anything other than smartphones.

That being the case, the future of software development is in mobile app development and cloud applications. As we move into the present capabilities more fully we will see a future where Mobile Enterprise Application Platforms (MEAP), Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) are so ubiquitous that mobile-to-mobile integration in the cloud is not only expected, it will be demanded by business users.

Holding all of this back is simple adhesion to existing systems. But here again, if one can find a nearly transparent way to integrate existing systems with mobile-to-mobile integration in the cloud then organizational resistance is futile. Business leaders will drive the process of mobile-to-mobile cloud integration forward as the cost of dynamically creating integrated applications and apps becomes less than the cost to maintain the current state of data center possessing IT departments which are typically weighed down by excessive Java overheads and heavy, overlapping middleware solutions. 

The pressure from smaller fiercely competitive organizations using agile concepts and metadata driven solutions will force Big IT to break ties with old ideas and embrace the mobile-to-mobile cloud integration future. In the meantime, billions of the rest of us will happily type on big keyboards safe inside the protection of our client server applications behind the firewall as colleagues foist loads of data over the firewall via Web applications. Either way, the technology sounds like Magic to me.



Friday, February 3, 2012

Dealing With Effectiveness Roadblocks in Software Change Management



In our previous review of major concerns in the practice of software change management, we focused on communication issues and analysis and identification problems. Other problems areas identified in both academic research and the literature of practitioners include effectiveness roadblocks, decision-making challenges, traceability issues and problems with tools. We have already established that third-generation languages (3GL) such as Java, RPG, COBOL and the various C-languages (C, C#, C++) all have characteristics that contribute negatively to the ability of an organization to achieve best results in the practice of software change management.

At this time, I would like to engage in a high-level overview of effectiveness roadblocksin software development and software change management. Software development managers should consider how inadequate testing, poor tool support, hardware and infrastructure inconsistencies and the inherent constraints of direct source code maintenance contribute to developer sluggishness and overall software development ineffectiveness.

Concurrent or parallel development rears its head again as a source of development challenges. It should be cear that no one is suggesting that parallel or concurrent development approaches must be avoided in order for software to be effective. Although, many developers utilizing more advanced tools will suggest that a one person development teamcan accomplish more than teams working in parallel.
Obviously, concurrent development necessitates greater and more frequent communication between developers, business analysts, stakeholders and users. Communication is, of course, a vital and necessary aspect of any development project as previously discussed. Nevertheless, communication is a source of errors, or more to the point mistakes in communication lead to errors. But effectiveness issues also contribute to the problematic nature of parallel efforts. 

Application platforms help deal with effectiveness issues in software change management and software development. A metadata-driven application platform provides software “applistructure” that helps avoid many concurrent development issues. By virtualizing the hardware environment, these platforms leverage metadata to reduce the programming effort. 

Higher level approaches that avoid line-by-line coding are not prone to experience the problems introduced by code optimization. And even if an optimizer is used, readability is unaffected. The pre-compiled and tested capabilities of a platform are essentially pre-optimized.

Expectations for high availability rather than inducing high costs and practical limitations that prevent responsive software change management are better met with an application platform approach which introduces a higher potential for stability, scalability and robustness in finished applications. Application platforms are “maintenance friendly” because software changes introduce less risk. Ironically, change avoidance can ultimately put previously stable software at risk as changes in application environments introduce new unknowns as changes in operating systems, database and other systems inevitably creep in. Those concerned with software change management must pay careful attention to the future-proof nature of application platforms versus 3GLs. A metadata-driven application platform with a repository-based approach will go a long way towards providing the assurance that whatever underlying changes are introduced, the platform vendor will be able to provide a way forward that protects your investment in your applications and allows you to maintain your applications with a minimum of effort..

In parallel efforts, integration architecture is necessarily incomplete in the early phases of a project. Testing errors occur because it is impossible or difficult to in a 3GL to anticipate testing oversights. A more advanced application development platform may be a solution in particular because of the repository based aspects of some application platforms. Also, underlying architecture is part of the platform and not the development effort and so de rigueur testing has already been accomplished by the platform provider.
Other aspects of the project architecture, up to and including hardware  requirements aremore likely  incomplete at the beginning of a 3GL project, which leads to requirement changes on software created by subsequent architectural changes not anticipated in the beginning stages of the lower level efforts.

Source code optimization also relates to effectiveness problems impacting software change management and software development overall. For one thing, optimized source code is difficult to understand. Changes are more difficult because it takes extra time to figure out what is going on with the optimized code. It’s also difficult to pinpoint issues in testing to separate problems in the optimized code. 

Application platforms help deal with effectiveness issues in software change management and software development. A metadata-driven application platform provides software “applistructure” that helps avoid many concurrent development issues. By virtualizing the hardware environment, these platforms leverage metadata to reduce the programming effort.

Higher level approaches that avoid line-by-line coding are not prone to experience the problems introduced by code optimization. And even if an optimizer is used, readability is unaffected. The pre-compiled and tested capabilities of a platform are essentially pre-optimized..

Expectations for high availability rather than inducing high costs and practical limitations that prevent responsive software change management are better met with an application platform approach which introduces a higher potential for stability, scalability and robustness in finished applications. Application platforms are “maintenance friendly” because software changes introduce less risk. Ironically, change avoidance can ultimately put previously stable software at risk as changes in application environments introduce new unknowns as changes in operating systems, database and other systems inevitably creep in. Those concerned with software change management must pay careful attention to the future-proof nature of application platforms versus 3GLs. A metadata-driven application platform with a repository-based approach will go a long way towards providing the assurance that whatever underlying changes are introduced, the platform vendor will be able to provide a way forward that protects your investment in your applications and allows you to maintain your applications with a minimum of effort..