When it is crunch time: Migrating from Visual Basic 6 to Visual Basic .Net/2005
Abstract
As a Visual Basic 6.0 programmer, what is the roadmap forward for your applications? As Visual Basic 6.0 becomes ‘deprecated technology’ what will you do with your enterprise class applications written in Visual Basic 6.0. This article is the musings of a developer that has been looking at migrating existing enterprise-class Visual Basic 6.0 applications to Visual Basic 2005.
Introduction
If you have been a serious Visual Basic 6.0 programmer with very sizeable code investments in Visual Basic (we have 22 enterprise level applications), at least 18 of which are written with Microsoft Visual Basic, crunch time comes when you begin to think or when you decide to advance your applications to new versions. Crunch time comes when all of a sudden, your Visual Basic 6.0 projects don’t open properly anymore in the Visual Basic 6.0 IDE (especially when running on Windows Vista with Visual Studio 2005 installed). Crunch time comes most especially when it dawns on you that you are basically using ‘deprecated’ technology, that between Visual Studio 6.0 (which contained Visual Basic 6.0) and Visual Studio 2008 (the latest version of Microsoft’s Visual Studio development suite), they have been 4 (four) new versions of Visual Basic.
Crunch time is the realization that for your software business to live, you will have to do something about your existing Visual Basic 6.0 applications. Our purpose in writing this article is to share our experiences of what we found as we endeavored to start to upgrade our Visual Basic 6.0 applications, and to discuss some of the touch decisions and choices that will undoubtedly have to be made.
Appraising the current Visual Basic situation!
What made Visual Basic special was its power, elegance and simplicity! It largely retained the style and syntax of the Basic language as we knew it i.e. if you had been using GW Basic, QBasic, Microsoft Basic Professional Development System (we shall call of these ‘Microsoft’s Basic’), etc, you could look at Visual Basic code and read it and understand it. Changing over from those early flavors of Microsoft’s implementation of the Basic programming language to Visual Basic was thus not difficult. In fact, the skills you learnt from using those early implementations of Basic made it easy and possible to immediately start building Windows database applications on Microsoft Access 2 using then Access Basic as implemented on those versions of Microsoft Access even though you had to learn a few new keywords and perhaps had to deal with the situation that some language features you knew had been removed!
Further developments of the basic implementations of Microsoft ensured that the Basic language, as we knew it and get skills of Visual Basic programmers have to be further improved if the Microsoft Visual Basic
Now coming to Visual Basic 6, the most powerful and elegant release of these flavors (prior to the .NET flavors) of Microsoft’s Basic, the Microsoft Solutions Framework (MSF) emphasized a componentized systems design and development approach in which the meat of your application (data access code, data manipulation code and business rules) could all be built as COM (Component Object Model) components hosted on MTS/COM+. Your application front-end (Visual Basic Forms or ASP Web Pages) could then call these components to obtain any services required. The backend could be any database system that had an ODBC Driver or OLE DB provider. The front-end as already noted could of course be Visual Basic Forms (if you wanted your application to run as a Windows application) or ASP (if you wanted your application to run as a Web application).
Your data-aware classes could easily establish connections to the database and then create recordset objects in its Init event that could then be returned to a calling application by calling the GetDataMember method of such a class.
Even in terms of data access technology, if you did use DAO (Data Access Objects) and RDO (Remote Data Objects) in Visual Basic versions prior to version 6, the changeover was the use of ADO (ActiveX Data Objects) not very difficult, because both technologies had similar terminology and interface (for example, a DAO Recordset object is similar in concept to a Recordset object returned in ADO) and methods for processing the objects.
This then is a general and short summary of what Basic programmers using Microsoft’s implementation of that language have had to deal with until the arrival of Visual Basic .NET flavors of Basic.
What is all the Hullaballoo about?
Visual Basic programmers expected Microsoft to maintain the look and feel of Microsoft’s Basic that we had always known (especially in the language implementation). But behold! What did Microsoft choose to do?? They decided to fulfill the biblical prophecy recorded at Zephaniah 3:9 which states ‘For then I shall give the peoples a change to a pure language, in order for them to call upon the name of Jehovah, in order to serve him shoulder to shoulder’.
The attempt to fulfill this biblical prophecy resulted in Microsoft’s attempt to create the New Jerusalem (the .NET Framework) and of course as we now know it, the .NET Framework languages! The result has been a massive genetic modification of the Visual Basic language and an attempted premature extinction of ‘perceived dianosaurs’ (e.g. Visual FoxPro).
If you are a lover of ‘game meat’ and Visual Basic prior to .NET was a charming wild mountain goat (an Ibex on the Highlands of Ethiopia), and you were then given the ‘new ‘ Visual Basic (i.e. the .NET Flavors of Visual Basic), you would not want to eat the meat at all because the color of the animal has changed, its size has changed (it looks more bloated), its natural smell has changed (it smells not like Basic but like C/C++), even its meat tastes different (not the C/C++ like syntax for writing code)…the grand creator (Microsoft) says it is the same or better but we all (aspiring citizens of the New Jerusalem) can see it is not! You cannot even open a Visual Basic 6.0 project in Visual Basic 2005 and expect it to run…it is that bad!
Crunch Time!
The million dollar question then is ‘If you are a Visual Basic 6.0 Programmer with significant code investments, what would you do?’ Should you migrate to other implementations of the Basic Programming language such as REALbasic 2009 (from Real Software Inc) or Liberty Basic? Should you try Visual Basic 6 lookalikes that also offer multi-platform compatibility such as Jabaco 1.4 (by Manuel Siekmann) or should you just rewrite your code in Visual Basic 2005/.NET? What alternatives did we find and what choices will have to be made?
Jabaco: Jabaco is startlingly like Visual Basic 6.0. Even the startup forms, property windows, toolbox, project explorer are astonishingly like Visual Basic. What is more, even the code syntax you write is pure VB 6-like! We made a copy of our Fixed Assets Software system and then opened it in Jabaco (we are using Windows Vista Home Basic) and the conversion process was seamless. To run the code, we made some minor changes (e.g. Converting Currency to Double) or removing Windows Controls such as the toolbar control and that was that! The structure of the Jabaco code, its keywords, its syntax, the functions and procedures are Visual Basic 6 alike. Even the way you make your Exe’s after writing your program was simple and straight forward. If you are a Visual Basic 6.0 programmer, and you are looking for a secure non-Microsoft way forward for your projects, you will feel instantly at home with Jabaco 1.4 from the very minute you start the application…you can start writing tons of code immediately! When we tried to run our program (both on Windows XP SP2 and Windows Vista Home), we were pleased to see that it could run without hitches! Jabaco would compile your application to Java byte code. In addition, Jabaco is free! The big cat is certainly prowling – power, elegance, speed, simplicity, multi-platform capability by compiling to Java plus a pure preservation of the spirit of Visual Basic…this is Jabaco!
Liberty Basic: Liberty Basic appear to offer a nice RAD look and feel! The method for building your application is reverse to what you normally do with Visual Basic 6 where you would draw your form’s on a Canvas! Liberty Basic is indeed a free-spirit, a true implementation of the Basic Programming Language! We did not test drive this tool! You would definitely have to look at this one for yourself…we have not evaluated this tool closely!
True Basic: True Basic is another viable alternative to Visual Basic! This implementation of the Basic programming language is touted as the true descendant of the original Dartmouth Basic and is available in Silver, Bronze and Gold editions. Again, we could not test drive this tool but product descriptions sure make it look like a powerful alternative to Visual Basic!
REALbasic 2009 R3: What about REALBasic 2009! We had known of this tool for sometime, having come across a white paper that we downloaded on the Internet! We downloaded a 30-day evaluation of the REALbasic 2009 R3 from the product website (www.realsoftware.com)! As with Jabaco, installation was a breeze! If we can consider Visual Basic 6.0 to have been a charming wild mountain goat on the highlands of Ethiopia, you may consider REALbasic as beautiful and dainty wild goat variety such as those found on the forests of Cyprus -? a beautiful and tasty variety indeed! A powerful viable alternative to Visual Basic .NET/2005! A Visual Basic 6.0 programmer could look at REALbasic code and readily enough read it understandably despite some minor differences in code structure! Both languages (Visual Basic 6 and REALbasic 2009) share many keywords and reserved words in common even though! Even though the IDE is different, it is readily enough understandable! Unlike Jabaco, REALbasic will not allow automatic conversion of Visual Basic 6.0 projects (or perhaps we did not look deeply enough) but rewriting your Visual Basic 6.0 code in REALbasic should definitely not be as difficult as doing a rewrite in Microsoft’s own Visual Basic 2005! Another attraction to REALbasic was that it ships with its own Client/Server SQL Database so that you can be up, building database applications quickly! This would mean that if you are using REALbasic, you would be obtaining a complete applications development studio (everything you need in the package)! And then to boot, REALbasic is multi-platform capable, allowing you to compile directly to Machine code (for windows, MAC OS and several other OS’s) thus achieving significant performance gains similar to those of C/C++ flavors that also compile to machine code! We think that the differences between REALbasic and Visual Basic can be accounted for in the motivation behind the creation of the language…the fact that the creators of REALbasic are in this for real…they are offering a genuine, powerful, viable, non-Microsoft alternative to Visual Basic.
Microsoft Visual Basic 2005: And what about Microsoft’s Visual Basic 2005 (this is what we have installed to enable us start conversion of our programs)? We cannot pretend that we are happy with the fact that we are required to re-write major league enterprise applications almost bottom up! As very experienced Visual Basic developers, we had expected to get up and quickly using the new Visual Basic (but that was not to be)!
?Be that as it may, Microsoft’s pioneering efforts in programming language design and innovation cannot be just discounted! The new Visual Basic 2005 is not Visual Basic 6 but it does stand shoulder-to-shoulder with C# (Microsoft’s new toy), J# and Visual C++ in terms of syntax and programming constructs! The New Visual Basic 2005 also includes expanded project types and language capabilities! It also has enhanced language constructs and new data types that will easily put you at par with the C# or C++ programmer while providing tools to rapidly create Web applications and access the latest versions of Microsoft’s own SQL Server 2008 and Oracle 10g/11g.
If it is name recognition that you want (Microsoft is a known name world-wide and their marketing power is unmatched); if you want to be a developer building applications with tools from an ‘approved supplier’ then you will have to embrace the new Visual Basic 2005 (Visual Basic 2008 has already been released as at the time of writing)…learn to eat genetically modified meats with a slightly different taste and feel so that you do not starve to death!
I think it is worth mentioning if you must stick with Microsoft that C#, Microsoft’s new C-like language that Microsoft created specifically for .NET Framework programming can also be a powerful contender! We found that mastering C# was both exciting and fun, probably because I was aware that I was learning a completely new programming language and therefore had no preconceptions of what to expect! On the contrary, learning Visual Basic 2005 was not so much fun perhaps because I approached the language as a Visual Basic programming veteran! I expected the language and keywords to be familiar enough! I expected the program structure to be familiar! I expected programming constructs and abstractions to be familiar! If you are a Visual Basic 6.0 programmer hoping to mater Visual Basic 2005 quickly, be forewarned – simply disabuse your mind! Approach Visual Basic 2005 as if you knew nothing at all about Visual Basic, approach it as if you are learning a completely new language that you have never really used for large-scale commercial projects (like say C/C++)and you will master Visual Basic 2005 soon enough!
Conclusion
All the options I have examined will involve some amount of code re-write! They can be no avoiding that no matter how little and I guess that is the risk attendant to our trade is it not?? If you want to keep your VB6 code almost as pure as it is, Jabaco is it! Otherwise, REALbasic is the next best alternative! If you want to stick with Microsoft, you would have no choice but to go Visual Basic 2005 because alas! Microsoft’s massive marketing machine ensures that most companies requesting new software (especially for those of us in the bespoke) software market are all requesting their projects in Visual Studio .NET! Also, it is a reality that the next generation of programmers being trained are being trained in Microsoft’s Visual Studio .NET as exemplified by the new popularity of C#
And what about us? We are taking a serious look at Visual Basic 2005, learning to like and desire the new meat so to speak! But we plan to also be delivering cross-platform solutions in Jabaco! Our quest for a solution brought us in touch with great tools out there being built by little known companies…it is worth checking out!
Posted in: java training| Tags: Technology Programmer Microsoft Migrating time enterprise article visual studio crunchMigration Challenges in BizTalk Migration
Integration migration projects are humbling in their complexity and over-whelmingly communication-intensive. You are more likely to run into communication, management and operational challenges which can conspire to defeat your march than any serious technical challenges. An adaptive, agile approach where assumptions are questioned daily and where close anticipation and planning discipline is instilled has a greater chance of success.
Here are pointers and advice about the challenges of an EAI migration project – right from the trenches.
Project Management lessons
1. First, if the “Replicating Behavior” migration approach is chosen, a pilot implementation of an interface would be beneficial. This allows learning a lot about the application scope, get the “big picture”, peek into many technical details and eccentricities early, and foresee upcoming challenges – not to mention planning ahead for infrastructure and performance. This Proof Of Concept is not required to be fully functional and can contain only limited amount of artifacts but should a variety of processes, workflows, operations, adapters etc. allowing to sound out different eccentricities.
2. In all large scale migration projects, it is very important to recreate the environment early. Solution partitioning, project structure, build, server topology, packaging and deployment guidelines should not be left for the last – we cannot overemphasize this. A controlled environment where SeeBeyond and BizTalk application can be run in isolation on the control data set. This is critical as there’s no other means to validate migration quality in this approach except to compare output for the known input. It takes considerable amount of discipline to stick to this plan as features get discovered, complexity grows and the team is crushed under this load – but it is important that this stays in focus as an early deliverable, not late one.
3. Early and continuous integration of the processes along with testing mentioned in 3) above helps to discover problems early and take mitigation actions. This is a key assumption that bedevils many teams who assume so-called isolated systems will not impact each other when run together on the same application server. Make sure to get the latest version of the shared code to avoid unpleasant surprises.
4. Some BizTalk features must be evaluated carefully before applying in implementation. There might be critical limitations that would slow down or even halt migration. For example, the Oracle DB adapter for BizTalk cannot return results of the joins from multiple tables. So, if you require this kind of result set then it’s time to turn back to the more flexible ADO.NET and bid goodbye to a code-free approach. Native SQL schema can be used instead of adapter generated schemas to generalize data access out of orchestrations and make them cleaner and easier to understand and maintain. When creating data access intensive orchestrations it often makes sense to consider delegating Oracle adapter task to a .Net component to get rid of large amount of transient messages and reduce performance overhead.
5. Do a careful analysis of the current code base before committing any timelines or budget. Do not assume the solution you are inheriting is either perfect or well-architected. We have found messy implementations where the management is delegated to UNIX/WMI scripts instead of being controlled from the GUI/e-Ways/Collaboration rules, resulting in business logic being distributed over areas not conducive to maintenance or good practice. When these problems are compounded by lack of documentation, then you need to increase project times by a significant amount to accommodate the pain and increased efforts of first collating logic in the code base into a sensible picture before the analysis and design can even begin.
Posted in: Software Programming| Tags: Microsoft WCF Challenge B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkRoll Out Strategy in BizTalk Migration
Rollout in an EAI migration project is always tricky – the goal should always be to cause as little disruption and downtime as is necessary. In order to achieve this goal of minimal disruption, an incremental phase approach is recommended.
To further illustrate our phased deployment approach, consider the following scenario which is typical in most EAI implementations in large enterprises - The existing SeeBeyond implementation has a history of having been built incrementally; new programs or upgrades were placed in service individually. Now compound that complexity with migrating the actual EAI logic to a new tool (BizTalk). Deploying such a migrated solution which includes a large number of sub-systems in service all at the same time, even if they are well tested, is an incredibly risky step for any business. Do not be deceived if each subsystem individually has a low bug rate – a single problem can manifest itself in ways across other systems that may not have been tested or accounted for. What typically occurs is that the number of such problems quickly overwhelms and cross-pollutes other systems, crippling the ability of the organization to deal with them. In other words - High Conversion Risk.
Incremental migration strategies entail the decomposition of multi-system implementations in phases which can be independently and selectively addressed and replaced. This reduces the costs and risks of a migration program. The original SeeBeyond sub-systems are retained and used until the BizTalk functions achieve an acceptable level of reliability, then they are replaced. In the beginning the smaller interfaces are piloted as the learning curve is steeper and the number of unknowns greater, so we do not want to overload with a complex sub-system. As we gain greater expertise and vital insights, we attempt to bite of larger pieces and tackle them until we meet with complete success.
In an incremental rewrite methodology, the SeeBeyond system continues to run as the new system is built, tested, and deployed. You will want to try to build the new system in a way that seamlessly integrates with the old system. The side-by-side environment maintains redundancy as functionality moves from the old to the new system.
Posted in: C# and .NET| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkDiscovery and Development Strategy of BizTalk Migration
With any migration approach, discovery of SeeBeyond code and artifacts is necessary due to the invaluable wealth of information there which has survived due its robustness or been refined to its current state. Not to use it would be an enormous waste. Although a huge amount of it is redundant in BizTalk due to the pre-built infrastructure (ports, adapters, configuration) you can mine a lot of it outright – some of it a simple cut and paste – such as database queries. Hence knowledge of SeeBeyond is inescapable.
To delve into SeeBeyond or to have a meaningful exchange with the SeeBeyond analyst, it would benefit the BizTalk professional greatly if could gain a first look inside SeeBeyond with the concepts and mental models he is already familiar with. Getting sufficient time from the harried, expensive and stretched thin SeeBeyond analyst is likely not going to be easy to come by, so the problem gets worse.
We have painstaking compiled a reference section to help with this comprehension – you will find this in the Appendix A of this paper.
Once the migration is complete, it is necessary to ensure that the new destination data is semantically equivalent to the original destination data (that has been processed with the SeeBeyond implementation). For this to be so, the results of all operations on the new Biztalk solutions must be identical to those on the old SeeBeyond solutions. There is no better way to gain such assurance than to exhaustively perform the same operations on both solutions and to compare the results. We recommend a Cross-Talk approach for verification testing.
In the Cross-Talk QA approach, the data source is flipped from SeeBeyond to BizTalk receivers and the results compared. When verified with a credible set of test queries, a high degree of assurance can be obtained from this approach that the new data store is semantically equivalent to the old one.
Posted in: Software| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkReArchitecture in BizTalk Migration
This rearchitecture approach is ideal in circumstances where the original implementation is sub-optimal (has performance issues or has been overtaken by new developments) or was developed in multiple layers laid on top over time of one another without an inherent design.
Even systems with well-defined architectures are prone to structural erosion. The relentless onslaught of changing requirements that any successful system attracts can gradually undermine its structure. Systems that were once tidy become overgrown as piecemeal growth gradually allows elements of the system to sprawl in an uncontrolled feature-creep. If such sprawl continues unabated, the structure of the system can become so badly compromised that it must be abandoned. The only way to sustain this system is by patches, and over time layers develop, until no shred of any original architecture or pattern remains.
Such systems are usually very difficult to maintain, document and perform poorly, making them good candidates for complete re-writes. In this case rearchitecture in a new system (BizTalk) from the ground up makes most sense as looking under the hood will confuse and provide no net benefit. There will also be many subtle, and not so subtle, differences between the old and new platforms and these make manual translation very difficult. A developer can quickly get led astray by the many subtle differences and become unproductive due to the overhead of constantly switching back and forth between old and new tools and platforms.
The newly designed system will accommodate new features, use the latest standards, and follow best practices for component reuse. The lessons from the previous implementation and hindsight will always be available, making the second generation solution a robust and optimized implementation.
Here are some tips for a rearchitecture approach
· Make use of accepted standards like HL7, HIPAA, RosettaNet, cXML, GS1, etc where applicable
· Loose coupling enabling other applications to be plugged in later
· Common components should be separated out into frameworks for reusability
· Avoid using custom connectors as these are difficult to develop and maintain
· Insist on automation of testing process to check for regression
· Run a performance lab and overload tests to make sure the application scales
· Ask for load balancing and fail over strategies for deployment
Posted in: Software Software Programming| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkWhy migrate from SeeBeyond to BizTalk?
Migrating from a large EAI platform to another is always a tough decision and cannot be made in vacuum. Whatever EAI platform an enterprise has in place forms the backbone of their enterprise when it comes to their data communication needs. The EAI platform is what one would analogously consider the “plumbing” of a house. If the plumbing fails, the house is unlivable and alternate arrangements have to be made.
Given the business criticality of an EAI solution, it is essential for an enterprise to choose a tool that is scalable, robust, extensible and most importantly maintainable. Typically these are qualities one would look in any software tool, but nowhere are they more important then in an EAI tool.
Historically, the problem with EAI tools in the enterprise space has been their lack of ability to continue to evolve to the new standards and advancements in technology and also the ability to scale with the growing demands of business. The tools that did manage to provide patches to the tools for such advances were usually “kludgey” solutions that were not truly integrated with the tool. Given these challenges that are bound to occur with any EAI tool now or in the future, it is prudent to move with a tool that is supported by a financially stable company which will be there for the long haul and has the deep pockets to support the advancements in technology. The reasons discussed about inability to evolve and scale has plagued the EAI industry until now because typically all EAI vendors have been small companies with their own agendas dictated more by wall street than the needs of their customers and as a result virtually all the key players have either almost vanished (Vitria) or have been acquired by larger corporations to fill a niche in their overall solution portfolio (SeeBeyond being purchased by Sun is a prime example) when the focus of the company may not be EAI.
Biztalk is one of the few tools that has grown internally within Microsoft and has been nurtured over the past few years for it to mature and achieve enterprise status. It is supported by the most financially stable software corporation on the planet and has the deep pockets and resources to keep evolving BizTalk to the ever changing needs.
Regardless of what tool an enterprise may be utilizing currently, chances are the enterprise will hit a point where the tool is unable to evolve or scale as needed and the sooner an enterprise makes a decision to move with an industry leader, the safer its investment in time, resources and money will be.
Having discussed some benefits of moving to BizTalk as a tool for choice, here are some points to consider why it is beneficial to move away from other EAI tools such as SeeBeyond.
· Expensive to maintain and increases TCO (Total Cost of Ownership)
· Is no longer a market leader in EAI tools and will eventually phase out and disappear where components are cannibalized and utilized in the J2EE frameworks from Sun
· Product is not backwards compatible with older versions
· Lack of backward and forwards compatibility requires constant re-tooling of team
· Upgrade in SeeBeyond is resource intensive and time consuming
· Takes longer to make changes to functionality
Posted in: Software Software Programming| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication Framework