Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What is the benefit of using Windows Workflow foundation (WF) versus rolling your own workflow framework?
From what I can tell, WF only provides a pretty bare-bones runtime engine, a bunch of classes, and a schema (XAML-based) for defining workflows. All the hard stuff such as persistence, providing a host process for the runtime, and implementing distributed workflows (across processes) is left up to you.
Plus there is a learning curve to using WF... if we created our own workflow framework we would simply leverage skills that all developers already have (C#, XML, SQL, etc).
I saw this blog from an MS evangelist which tries to explain why we should use WF:
Why Workflow?...
IMO it doesn't do a good job of convincing because it just states that it helps "developer productivity", while admitting that developers could roll their own.
Can any of the smart folks here come up with a better reason?
SUMMARY FROM ANSWERS GIVEN BELOW:
I think the most convincing reason is that using a standardized workflow platform such as WF (versus rolling your own) will allow you to leverage current and future tooling such as the Visual Designer, provided by MS and third parties.
Also because it is part of the MS stack of .NET based technologies, it will likely have better integration/migration path with future MS technologies (such as Azure).
Finally, the number of developers with WF experience will increase (as it will benefit them career-wise), turning it into a basic commodity skill such as SQL or HTML, meaning it will become easier to find people who can start working with it with minimal ramp up time.
The choice to use WF takes some evaluation and I'm going to try and provide a fairly comprehensive list here on what the pros and cons are. Keep in mind that if you're going to use WF don't use anything other than WF4+ because it was rewritten and is significantly vetted past its predecessors.
Pros
Cost
Flexibility
Durability
Distributability
Future
Cost
The cost of WF is important to note when comparing it against other paths. Those paths may include BizTalk, an open source code based framework like Objectflow, or even rolling your own. Bear in mind that unless you need something significantly simplistic, rolling your own would be the most expensive approach every time. So, if you need a sizable piece of functionality but also need control over the source code I would recommend an open source framework.
Flexibility
WF is a very flexible framework in contrast with a framework like BizTalk. In WF you can write your own custom activities and do what you need to do outside of the framework - this really gives you the power you need.
Durability
WF includes a very powerful durability framework. It's durable in the sense that the state of a workflow can be persisted, the workflow can be set idle (to preserve resources), and then recalled later. But, that durability goes a lot further because it's already setup for durability across a host farm. In other words a workflow can be started on one host, persisted, and then recalled on another host.
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
Distributability
WF is already setup to be distributed across a host farm.
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
Future
WF is the replacement orchestration engine for BizTalk and is in fact developed by the same people that built BizTalk. Therefore WF has a bright future in the Microsoft stack. In fact, right now Microsoft is working on building individual components to replace every feature of BizTalk with components. For example, Windows Server AppFabric (and more specifically the plug-in to IIS) is the replacement for the monitoring services that exist within BizTalk today.
Why is Microsoft doing this? Because BizTalk isn't really well suited for the cloud because it's one massive install, whereas the components they are building could be deployed to a cloud solution.
Cons
Flexibility
Monitoring
Flexibility
WF's flexibility can also be its pitfall because sometimes you don't need the flexibility that it provides and thus spend more time building stuff that you would otherwise want to just be included. Sometimes you need a framework that makes a lot of assumptions and maybe works off of convention instead (e.g. MVC). However, generally speaking I have found that this isn't true when coupling the WF4 framework with the open source extensions provided by Ron Jacobs.
Monitoring
The monitoring for WF is still very young and this is its biggest pitfall. However, this will advance very quickly over time and in the meantime you can build your own monitoring tools with custom tracking mechanisms.
Resources
Your best resource is Ron Jacobs. I have never met somebody that is so willing to help the community of developers that have to use Microsoft's frameworks than him. Believe me, he's provided a vast amount of information surrounding WF via numerous channels, just get on Google and check it out.
The main reasons I can think of to lean towards using WF over another workflow framework are:
Microsoft is supporting it as a core part of the framework, so it can/will be easier to integrate into their other technologies like Sharepoint and Azure "cloud applications"
The tooling is likely to improve and be really slick in another few versions, which should improve developer productivity
I have had to create Workflow activities at my job, and I can't even tell you the answer.
One not very valid reason is that invalid values/inputs can be determined and refused at design time for workflow diagrams, and so compile-time errors basically don't exist (assuming all that boilerplate code you wrote has no compile-time errors).
Short answer: it's free and it gets the job done. If you can roll a better framework for managing workflow and want to spend your time on it, by all means do. But consider that your time is worth money, so how much money are you willing to commit to building a better framework for managing workflow? I could see that getting expensive.
Also, I'm pretty sure that persistence (to disk or SQL) is handled out of the box.
There is some reasonably nice designer support in Visual Studio that I'd rather not have to roll for myself, and it's a framework supported by someone else rather than me, meaning someone fixes the architecture bugs and does the main testing, leaving me to test just my workflow. I mean, I could roll my own versions of GDI+ calls, but I'd rather not. Same goes for my own serialization framework, XML parser, or some other element of the .NET framework.
When it comes down to it, these things are provided as a toolkit. Whether you choose to use a tool or not depends entirely on the problem you're solving, the suitability of the tool, and the time and resources you have available to achieve the goal.
Its a new technology Or you can say its latest with a promise of constantly updating features.
It respects the previous working environment and uses it and add those features which are very helpful with regards to the development of the long running programs(large projects).
It produces all that features directly into the hands of the developer which were previously running at the back lacking the interaction between the inner core concepts and the programmer.
Yeah its a little complex but also it provides more power in the hands of the programmer.
You can expect better frameworks and features in the coming future.
Its the future of the programming so better we start learning it today.
Related
I'm at a customer where I successfully developed and deployed a WCF service layer (compiled against .NET 4.5). It works perfectly and everything is dandy.
However, we just got an additional requirement - I'm supposed to rebuild (or at least redesign) the layer to incorporate WSSF. There's no old functionality that we'd need to integrate with and all operations in the services are based on executing SPs in a DB.
Should I do that or is it wiser to argue against it? I'm not certain because I've never worked using WSSF and I got virtually no explanation as to why we should at this particular workplace (which could be that they don't want us to know as well as that simply don't know themselves).
My worries are based on, but not limited to, the following.
The latest release is from August 2010.
There's nothing listed in documentation section.
The license seems to be in conflict with commercial activities.
WSSF isn't widely used as technology today (or is it?!).
The purpose of WSSF is to WCF-fy old service layer (or isn't it?!) only.
Especially #4 and #5 are not the strongest statements in my arsenal at the moment so I'll gladly stand corrected, should anybody have a few wise words to contribute with on the subject.
Short story is that it doesn't look good. From MSDN: Web Service Software Factory 2010:
The Web Service Software Factory is now maintained by the community
and can be found on the Service Factory site. This content is outdated
and is no longer being maintained. It is provided as a courtesy for
individuals who are still using these technologies. This page may
contain URLs that were valid when originally published, but now link
to sites or pages that no longer exist. Retired: November 2011
1) So, it looks like it's totally being run by the community. However, looking at the discussion forum there aren't many postings and quite a few have no responses.
2) I find it's fairly common for the documentation tab to be empty at codeplex but there is frequently documentation but not on the documentation tab.
3) In terms of licensing Ms-PL is quite permissive so I wouldn't imagine there would be any issues.
4) Not to belittle it but I don't think it was/is very popular. Definitely not a standard.
5) The intent of the service factory was to provide guidance -- both written and code based. See Web Service Software Factory for a discussion.
WSSF was a tool that incorporated best-practices for building WCF services. It's been years since I've used it, but basically I recall a wizard that asked several (actually lots of) questions about the service (contract), data (model), etc. What it would produce is a nicely organized solution with several projects with proper naming conventions, verbose declarations like adding IsOneWay=true/false to [OperationBehavior]'s or IsRequired=true/false, Order=n, etc. to [DataContract]. In other words, it generated very verbose code that most of us blow off until we need it.
It did more though, such as structuring your solution so that service contracts were in one project, data contracts in another, and implementation in yet another. It created test projects (I believe). so, very granular layout of the solution. I remember the simplest of services would result in about 6-7 projects in the solution. It was a little intimidating at first until you poked through the code it generated.
Another cool feature it had (at the time many were asking for) was a way to do contract first development. Given an existing web service metadata, you could constuct a new service solution.
Anyway, once it was completed, you just had to do essentially provide implementation for the methods. Personally, I never really embraced it for services development. But, at the time, I appreciated it and often referred customers to it who were new to services development because I knew it would get them off to a proper start.
To comment on your worries though...
That's correct, and it is not getting any resources to update it.
Actually, there is quite a bit of documentation. Just move over to the Home tab and you will see links to it.
Not sure about this. The code it generates is yours. You still have to compile it and it's yours to maintain going forward. No different than any other code-generation tool (as far as I know).
Nope, it is not. Also, consider the time when this was developed, .NET Framework 2 - 3.x. There's been a lot added to WCF since then. There's also been some new guidance on service development. If you're using some of the newer features added in .NET Framework 3.5SP and beyond (which you probably are), then this definitely is not something I would recommend using.
Again, that was one of the nice features (contract first development). But, that really wasn't the main idea. It was a tool to build out the framework for new services too. In fact, new service development was the original motivation of the tool as I recall. Once you took the time to go through the dialogs, you had a really nice solution to start building on.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Based upon your experience
If you was given the opportunity to set up the development processes for a small development team.
Please detail
The things you would implement, tools, documents, methodology.
And how you would implement these?
I wish to implement the following:
Source Control
Bug tracking database
Formal Spec templates
Code Reviews
Coffee cup meeting (simple quick informal meetings over coffee :) )
Strict Coding convention
Please keep in mind this would be for a C# .NET focused environment.
If you plan on purchasing, or already have purchased, MSDN subscriptions, there is a major change in licensing that plays out in your favor for Team Foundation Server 2010. Server licensing is now included with MSDN, and you are provided with one CAL per subscription. More licensing details are available here.
Team Foundation Server will cover almost all of your needs in one package. I am very preferential to using as few tools to complete a job as possible, which is one of the reasons I recommend that you look into using Team Foundation Server, as well.
Some notes into your specific requirements:
Source Control - One of the primary functions of Team Foundation Server. It works well and easily integrates with AD Groups. We have security groups set up by roles per project and also for roles across projects. A company developer will be a part of the "Developer" SG and the specific SGs that he/she are involved in. This allows us to give them full access to the projects that they are working on and read access to all projects. The system has the benefit of contractors not belonging to a generalist development group - effectively bucketing them into projects.
Bug Tracking Database - Integration with source control is a definite advantage. By using one package, you have an built in relationship between work items and changesets (which you can further enforce by requiring changesets are only created in the context of work items). Work item relationships are very nice - and vary, depending on your template choice. Both Microsoft's SCRUM and Agile templates are well thought out, and have served our needs quite well, to date.
Formal Specification Templates - There are a couple of ways to approach this. You could create a specific work item type for each template and prepopulate some of the content, or if you wanted a more traditional approach, you could store document templates within the project's Document tree (which is, effectively, a document library on the Team Project Portal site).
Code Reviews - Basic functionality like Annotate (or Blame, if you prefer) are built in. Diff Tools are provided, as well - plus you can switch out the diff tools for others if you do not like what ships with it. (Personally, I use DevArt's CodeCompare .) As for the actual review process, I am a fan of TeamReview.
Strict Coding Conventions - StyleCop is a must, in my opinion. As such, I also believe that ReSharper is a must, as well. Providing conventions is one thing, but being able to visibly put them in front of the user is another. Using something like StyleCop for ReSharper will provide real-time feedback on violations of policies. Anything that you want to add that isn't a part of StyeCop can be created via custom rules, and you can actually put the ReSharper configuration for SCFR in TFS, so that it is shared by the team.
Bonus items that you get that you did not explicitly mention:
Build Management - The build tools in Team Foundation Server 2010 are completely overhauled. Now, builds are defined as workflows using Workflow Foundation, but still can be manually manipulated for more complex build scenarios Gated check-ins, often referred to as "buddy builds" help keep bad code out of the trunk.
Test Management - Testers can benefit from the streamlined testing tools in Visual Studio 2010. Automation of CodedUI tests, and the Test Lab Management tools are major strides in the evolution of Visual Studio. Having a tester be able to capture the state of the machine and automatically insert it into a work item is brilliant, and long overdue. Plus, if you end up using the Test Lab tools, actually being able to capture a snapshot of the VM at the moment of the crash is just pure gravy.
Collaboration - Even if you don't plan on using it at first, the Team Project Portals that are created for each Team Project are ripe with opportunity for collaboration. Just for document management and project wikis alone, it is worth its weight in gold.
Reporting - The reports vary with the templates that you use, but most templates have the type of reports that management care about ready to go. Adding new reports is fairly simple, due to the way that the TFS team has presented data in the cube, as well. A little SSRS knowledge will have you creating detailed custom reports in no time, at all.
Planning - You do not mention what type of methodology you are using - but the Agile template has some really nice sprint planning tools built in. You literally launch a sprint planning worksheet from Visual Studio, which opens in Excel, and any changes you make are reflected in TFS. Really works great for a group planning session.
Support - This is one of the most important factors to me. Having all of the above in a single package also means that I only need to go to one vendor for support. It is invaluable to me to be able to have one phone number to call in the rare occasion that something does go wrong, and know that I have the support incidents to cover it already paid for, thanks to my MSDN subscription.
All that being said, TFS does have a bit of a learning curve. Installation and setup are actually quite simple, assuming that you follow the documentation. The learning curve comes from the fact that there is so much to do with TFS. You might not use all of the features, so the amount of time you actually need to spend learning might vary. The native integration with Visual Studio (and Office) do provide a seamless feel, though, that should translate well to the developers using the system.
Source Control: For a .NET environment, Team Server is good stuff. If you want a free solution, I like Mercurial.
Bug Tracking: FogBugz (of course :)
Spec Templates: I think defining these should be a collaborative process between the development team and business units. Start with a very light framework and let them evolve, don't prescribe a massive document that includes information no one ever uses.
Code Reviews: Peer programming time offers this in abundance. Call out good practices to the team- don't use it as a way to humiliate developers in public.
Meetings: I'm an Agile kind of guy, so meetings (standups) should be brief, to the point, and happen every day at the same time.
Coding Conventions: Again, if you have capable developers you shouldn't have to prescribe strict conventions. Agree as a team on basic conventions and address friction points as necessary.
If your team can foot the bill for Team Foundation Server, you'll have most of what you want in one convenient package.
Source Control: Changeset-based configuration control system with full branching support.
Bug tracking database: Work items - configurable, including bug tracking and reports.
Formal Spec templates: Work items - configurable, including requirements (CMMI), scenarios (Agile), custom types, etc.
Code reviews: Work items - track your reviews just like any other TFS piece of work. A review work item ships with the CMMI process template.
Strict coding convention - I've heard of people integrating StyleCop with their check-in policy.
As for coffee cup meetings, you won't need a tool for that. :)
Migation of a VB6 application to .NET platform is almost like a rewrite, no matter it is VB.NET or C#. Do you think it will require more effort to do it in Java platform, when compared to .NET platform, since it is a rewrite anyway? Please share your thoughts!
No offence, but you are wrong. Porting to .Net is usually far easier than a rewrite.
Here's the official advice from Microsoft UK:
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
From a blog post by a Microsoft guy who consulted on rewrites:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
I recommend the following two steps in this order.
Write down the reasons for migration or rewriting. What benefits will it bring? The benefits might be just to keep the development team happy - that might even be a good enough reason, I don't know. Make sure you know, and your managers/users agree.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. It may be rewriting, but go into it with your eyes open.
In answer to your actual question: would a complete rewrite be easier in .Net or Java? That mainly depends on which one your team knows best. It also depends a little on whether the application interacts with COM, just like SLaks says.
The effort of rewriting a VB6 app is more than just a question of which language you're targetting. VB apps often rely on COM objects and certain VB-specific library methods which may not have equivalents in Java - but may have some portability in .NET.
Unless you are willing to abandon all of the dependences of the project, you may find .NET an easier target to re-write for, especially if you need to preserve some of the behavior of the existing application which derives from libraries or other dependencies.
Another consideration will be which platform your team is most familiar with - if you have a lot of Java expertise but little or no .NET expertise, then perhaps Java is a good choice for you.
There are tools available that will migrate from VB6 to VB .Net, including the one built into Visual Studio. This tool migrates VB6 to C#. Whatever tool you use, you will still need to do a lot of manual work on the code that the tool outputs, however this is likely to be less work than a complete java rewrite.
Depending on your existing application's architecture, and how well the code is structured, you may decide it is better to completely re-design and rewrite it anyway, in which case there may not be much to choose between .Net and java.
It is important to reduce not just the total effort during migration but also the cost of maintenance after migration. Many factors drive TCO, but all things being equal I think the .NET tools, community, framework, and C# language meet or beat Java in terms of developer productivity, operational managability, and performance -- assuming your are targeting windows OS.
I do not think ease of keeping COM should be the deciding factor either. In fact, I think migrating VB6 to .NET but keeping COM when you do not have to defeats a critical purpose of doing a VB6 migration in the first place: to reduce development costs and risks by moving to a well-supported and viable platform. I will tell you why:
Most of the popular COM libraries and
controls that were used with VB6 have
not evolved in many years; many of
the smaller vendors have disappeared
or if they are still supporting their
wares, they now also offer new and
improved .NET versions.
Living with old COM after migration
means living with additional
complexity in terms of debugging,
builds, and deployment. Also beware that COM
components do not really "speak" .NET
(i.e they do not use .NET types and
conventions) so their use with .NET usually
results in added complexity in the
coding and design.
There still are a few
hold-outs and exceptions to this rule
and a .NET replacement is not the
always best choice, but in general,
migration teams will be able to find
at least one .NET replacement option
for almost every COM component they use.
Taking the time to thoughtfully
evaluate, select and upgrade to one
of those options will pay off after
the migration.
You will not want to interop anything
that is VB6 you plan to migrate. Interoping your own code will lead to a longer,
complex transition and typically
requires back-tracking and
reworking/retesting already migrated
codes. Clearly this is not the most
efficient and understandable upgrade
path.
One more point about having to do "a lot of manual work on the output". The Great Migrations product is a new, programmable migration tool. It is designed to help migration teams incrementally improve the quality of generated code and thus reduce the manual work required to complete the migration project. This includes making the translations more correct, dealing with complex multi-VBP migrations, and also automating the restructuring of VB6/COM code to use .NET components. These features are particularly helpful if the VB6 codebase is very large, changing frequently, and being significantly re-engineered and cleaned up during the migration. This is an agile migration methodology we call the tool-assisted rewrite.
Disclaimer: I work for Great Migrations.
If the application uses COM, it will be far easier to rewrite it in .Net than in Java. Otherwise, it will probably be somewhat easier to port to .Net.
For a more specific answer, please provide more details about your application.
You could also use Jabaco it is a Java Bytecode compiler and it has it's own IDE and syntax very similar to VB6 (nearly the same).
You can find more information at:
http://www.jabaco.org/
http://www.jabaco.org/board/
use a migration tool, like ArtInSoft to just migrate it to .NET.
You can migrate the VB 6 application using the in built VS migration to VB.Net. Try to see if that helps you. If you are looking at migrating VB 6 to C# then I would also recommend what ScaleOvenStove user has recommended.
I'm investigating technologies with which to develop a medium-scale (up to 100 or 200 simultaneous users) database-driven web application, and someone suggested Morfik. However, outside of the Morfik company I can find practically zero community support - no active blogs, no tutorials, no videos, no books - and this is of some concern (especially when compared to C# / ASP.NET / nHibernate etc support). Deciding between Morfik (untried and not used widely AFAIK) and the other technologies I mentioned (tried, tested, used widely) is becoming a critical issue for my company.
Has anyone had success using Morfik in these kind of circumstances? What kind of performance did you achieve?
Being a Morfik user for the last 2-3 months, trying to do a quite large project. I totally understand your concern.
The community is small, Morfik developers though try to help you and answer almost all your questions. It was one of my concerns before purchasing it, but it's not a big deal actually.
However, it lacks documentation and tutorials. Yes, there is a chm help file, but outdated and lacks in many ways. Not enough examples, you should figure a lot of stuff on your own. But they say, it's Morfik team's one of the first priorities in the upcoming release to enhance the documentation.
We chose not to use Firebird as the db (Morfik supports it natively) and going with Postgresql over ODBC. There are issues to overcome there too. We had to dive in and modify (override) our own security wrapper for postgre etc. But overall, Morfik integrates with it quite fine. You should be prepared to small annoyances though.
We chose to go with Pascal version, as it is the major language the developers use. But, oh I hate Pascal so much :) It had been 10+ years last time I used Pascal and it can be really annoying with the quirky code editor of Morfik.. I miss VisualStudio, or even Notepad++ as editor!
Since we started our app, I see new components and examples released quite frequently. Morfik team invested on a separate team that develop addons for Morfik, which is a good thing.
So, in terms of support (not community but staff) you should not worry. It's still far from being a mature product but it does the job. Our relationship with Morfik is a love and hate one. I am quite sure our big project will be successfully completed with Morfik, and I can do small enterprise solutions with Morfik very (I mean very) fast. But I would also really think again to use Morfik if we do a big project like we are doing now.
I hope I make sense :)
You might try looking at www.morfikwatch.com which a blog dedicated to Morfik. There you will find links to a couple of Morfik user communities. You can then ask around.
We use Morfik for a variety of purposes, all intranet based. We are looking at the migration of all in-house corporate applications being refactored into morfik applications.
Morfik is a new product, and as such, the community is still growing. Although Morfik 1 has been around for awhile, Morfik 2 is the first version that makes it easy to develop plugins and other third party tools. Now there are small websites starting to appear that create plugins and support Morfik. (http://www.pannonrex.com/ for example).
Morfik is in it's infancy yet offers a solution to be found nowhere else. I would recommend it highly. Just give it time and the developer community will appear just as it did for Delphi and the rest.
best regards
Dalton Calford
Distributel Communications
I'm sorry, when I saw 100-200 simultaneous connections, I immediately thought you meant intranet. We average 300-450 concurrent users on our apps, so we do not consider it a internet based app until you look at a possible 5,000+ users.
The design criteria for such a system is very different than a system with under 1000 users.
When you approach such a system, you are looking at a cloud configuration. As our company is a telecommunications company, and we are required by law to meet 5-9's service for our customers, we use firebird in all our back end processes. Although we have used DB2, Oracle and other products in the past, Firebird has either been more reliable or outperformed the others.
With the about to be released Firebird 2.5 (now in rc 2 if you wish to play with it), you can use firebird as it's own middle tier, with one database connecting to multiple other databases to perform both DML and DDL actions. You can have one Firebird database that has no tables whatsoever, just stored procedures, views etc. That database can then surface the data from multiple sources without the client application knowing. As the connection can be dynamically built within the stored procedures, you can have the backend databases change as needed without changing any front end code. This allows you to load balance, have multiple web servers share a single cluster of databases etc.
So, I since Morfik supports Firebird intrinsically, I would say that yes, Morfik can scale well to a larger environment without trouble. As for Firebird support, it has one of the most active user communities on the web.
From the point of view of Morfik, morfik is a great way to generate a web based UI while leveraging your existing developer base without having to learn a series of new languages. But, it currently lets the developer use the tools for n-tier development without getting in the way. I like that. I do not want a tool that tries to be everything and in turn, does nothing well.
best regards
Dalton Calford
Distributel Communications
Something that I am very concerned about is 3rd party components. GWT has a fairly large collection of components. We make extensive use of data grids that need to be data aware and very rich, meaning it needs to be able to do grouping and sub groupings and master detail relationships.
You must also be able to create new groupings on the fly.
We also make use of pivot grids a lot, so we need them as well, and a quick google search doesn't show any components that can compare to what is already available in GWT.
It is a pity though, since the Morfik development environment seems very integrated. The GWT environment is a bit funny to me, since I am used to the Visual Studio and Delphi environments, so the way Eclipse work is a bit foreign to me, especially when adding new components to the different designers and editors in eclipse.
Morfik is quite limited web development environment for a very basic web development. Even if it gives some benefits in the very beginning in long term it will tie you up.
I worked with Morfik for two years, you can undoubtedly make applications fairly quickly for the management that has design and maintenance is literally 3 clicks, but when you want to add a little more robust functionality can become a pain of head, without counting the inconvenience that is to adjust the reports, has little documentation and the components are the majority of paid.
If you want an app in a short time and not very robust Morfik is indicated, if you want something more I do not recommend it.
Does anyone have any advice for migrating a PowerBuilder 10 business application to .NET?
My company is considering migrating a legacy PB application to .NET (C#) and I am just wondering if anyone has any experience - good or bad - that you would like to share.
The application is rather large with 10 PBL libraries, some PFC as well as custom frameworks. There are a large number of DLL calls being made as well. Finally, it uses a Microsoft SQL Server database.
We have discussed porting the "core" application code to .NET and then porting more advanced functionality across as-needed.
When I saw the title, I was just going to lurk, being a renowned PB bigot. Oh well. Thanks for the vote of confidence, Bernard.
My first suggestion would be to ditch the language of self-deception. If I eat half of a "lite" cheesecake, I'm still going to lose sight of my belt. A migration can take as little as 10 minutes. What you'll be doing is a rewrite. The time needs to be measured as a rewrite. The risk needs to be measured as a rewrite. And the design effort should be measured as a rewrite.
Yes, I said design effort. "Migrate" conjures up images of pumping code through some black box with a translation mirroring the original coming out the other side. Do you want to replicate the same design mistakes that were made back in 1994 that you've been living with for years? Even with excellent quality code, I'd guess that excellent design choices in PowerBuilder may be awful design choices in C#. Does a straight conversion neglect the power and strengths of the platform? Will you be living with the consequences of neglecting a good C# design for the next 15 years?
That rant aside, since you don't mention your motivation for moving "to .NET," it's hard to suggest what options you might have to mitigate the risk of a rewrite. If your management has simply decided that PowerBuilder developers smell bad and need to be expunged from the office, then good luck on the rewrite.
If you simply want to deploy Windows Forms, Web Forms, Assemblies or .NET web services, or to leverage the .NET libraries, then as Paul mentioned, moving to 11.0 or 11.5 could get you there, with an effort closer to a migration. (I'd suggest again reviewing and making sure you've got a good design for the new platform, particularly with Web Forms, but that effort should be significantly smaller than a rewrite.) If you want to deploy a WPF application, I know a year is quite a while to wait, but looking into PowerBuilder 12 might be worth the effort. Pulled off correctly, the WPF capability may put PowerBuilder into a unique and powerful position.
If a rewrite is guaranteed to be in your future (showers seem cheaper), you might want to phase the conversion. DataWindow.NET makes it possible to to take your DataWindows with you. (My pet theory of the week is that PowerBuilder developers take the DataWindow for granted until they have to reproduce all the functionality that comes built in.) Being able to drop in pre-existing, pre-tested, multi-row, scrollable, minimal resource consuming, printable, data-bound dynamic UI, generating minimal SQL with built-in logical record locking and database error conversion to events, into a new application is a big leg up.
You can also phase the transition by converting your PowerBuilder code to something that is consumable by a .NET application. As mentioned, you can produce COM objects with the PB 10 you've got, but will have to move to 11.0 or 11.5 to produce assemblies. The value of this may depend on how well partitioned your application is. If your business logic snakes through GUI events and functions instead of being partitioned out to non-visual objects (aka custom classes), the value of this may be questionable. Still, this is a design faux pas that should probably be fixed before a full conversion to C#; this is something that can be done while still maintaining the PowerBuilder application as a preliminary step to a phased and then a full conversion.
No doubt I'd rather see you stay with PowerBuilder. Failing that, I'd like to see you succeed. Just remember, once you take that first bite, you'll have to finish it.
Good luck finding that belt,
Terry.
I see you've mentioned moving "core components" to .NET to start. As you might guess by now, I think a staged approach is a wise decision. Now the definition of "core" may be debatable, but how about a contrary point of view. Food for thought? (Obviously, this was the wrong week to start a diet.) Based on where PB is right now, it would be hard to divide your application between PB and C# along application functionality (e.g. Accounts Receivable in PB, Accounts Payable in C#). A division that may work is GUI vs business logic. As mentioned before, pumping business logic out of PB into executables C# can consume is already possible. How about building the GUI in C#, with the DataWindows copied from PB and the business logic pumped out as COM objects or assemblies? Going the other way, to consume .NET assemblies in PB, you'll either have to move up to 11.x and migrate to Windows Forms, or put them in a COM callable wrapper.
Or, just train your C# developers in PowerBuilder. This just may be a rumour, but I hear the new PowerBuilder marketing tag line will be "So simple, even a C# developer can use it." ;-)
I think gbjbaanb gave you a good answer above.
Some other questions worth considering:
Is this PB10 app a new, well-written PB10 app, or was it one made in 1998 in PB4, then gradually converted to PB10 over the years? A well-written app should have some decent segregation between the business logic and the GUI, and you should be able to systematically port your code to .Net. At least, it should be a lot easier than if this is a legacy PB app, in which case it would be likely that you'd have tons of logic buried in buttons, datawindows, menus, and who knows what else. Not impossible, but more difficult to rework.
How well is the app running? If it's OK and stable, and doesn't need a lot of new features, then maybe it doesn't need rewriting. Or, as gbjbaanb said, you can put .Net wrappers around some pieces and then expose the functionality you need without a full rewrite. If, on the other hand, your app is cantankerous, nasty, not really satisfying business needs, and is making your users inefficient, then you might have a case for rewriting, or perhaps some serious refactoring and then some enhancements. There are PB guys serving sentences, er, I mean, making a living with the second scenario.
I'm not against rewrites if the software is exceedingly poor and is negatively affecting the company's business, but even then gradual adjustments and improvements are a less risky way to achieve system evolution.
Also, don't bail on this thread until after Terry Voth posts. He's on StackOverflow and is one of the top PB guys.
If its rather large, you might have better results writing a front-end for it in .net (or a web-based GUI) and using that to interact with your PB code, assuming you can expose the functionality it as an API.
If you're using PB 9 or greater, you can generate COM or .NET dlls, that you can then consume by a C# GUI. I'd recommend this over a rewrite in any new language.
Remember, rewrites are never a silver bullet, they always end up more time-consuming, difficult, and buggy than you first expect.
You might want to spend some time investigating PowerBuilder 11.5 (recently released) which adds some significant .NET integration.
Migrating to PowerBuilder 11.5 in order to make use of new .NET code will certainly be a lot easier than completely rewriting the entire app in C#.
I don't know if it's good or not but check this (commercial) product : PB.Net
My pet theory of the week is that PowerBuilder developers take the DataWindow for granted until they have to reproduce all the functionality that comes built in.
I'd back that theory. I went though an attempted conversion from PB8 to Java on a project several years ago that failed miserably, even using the first-gen HTML DataWindow. My current employer is hell-bent on moving to C#, not using Datawindow.NET despite > 2K DWOs in our current product. I'm not looking forward to the day when the realization sets in. (the entire product consist of several user applications, more than a dozen services, and use about 70 PBDs)
OP - unless your application is unusually well-structured (originally written for EA Server maybe?), this will not be a port. Things work too differently in the PB & .NET environments for a plain port to work satisfactorily. I cannot stress this enough - if you're really using the PB event model, a "port" will likely be a failure.
You need to look at logic flow (intertwined UI & process), control flow (who owns the process or data right now), data access (UI, data layer, ??) and the parts of the DW event model you're using from code. If you're thinking about ASP.NET (as we are), your whole user interaction experience will have to change, and that will feed back into the other considerations.
Not directly related to code, build automation will change (we use PowerGen for consistent PB builds; MSBuild is very different) as will your installation & setup.
I think anyone considering this for a large app would be pretty crazy not to very seriously consider using the DataWindow.NET, so as not to lose their investment in the DWs.
PHB's at major corporations think that Powerbuilder is a toy language and migrating to a new language like C# is trivial and can be done at a low cost. In fact, migrating a PB application to any other language will cost at least as much as developing an entirely new application on the new language. The resulting app will generally lose functionality compared to the original and will result in user dissatisfaction. I have seen a number of attempts - all have failed because of the difficulty and the user issues.
If it ain't broke, don't fix it.
Yes, it`s doable now without rewriting service components period.
PB 12.5>
And target GUI and service component migrations and integrations to c#.
Migration/Integration strategy may vary depending your project scope, scalability, resources and timeline.
You can use these target and project types in PowerBuilder .NET.
Refer this link Sybase_PB .Net
WPF Window Application WPF Window Application, WCF Client Proxy, or REST Client Proxy
PB Assembly WCF Client Proxy, REST Client Proxy, or PB Assembly
.NET Assembly WCF Client Proxy, REST Client Proxy, or .NET Assembly
WCF Service WCF Client Proxy, REST Client Proxy, or WCF Service