My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.
Related
So I'm new to node.js, javascript frameworks, and meteor.com. I'm trying to learn how to build social networks, and I'm naive/struggling to understand why Meteor.js (meteor.com) wouldn't be able to do all the great things you see now that twitter, facebook, instagram are doing?
There's the comet technology between client/server, authentication configs, asynchronous coding for scaling and performance, and built on top of node.js.
I'm trying to learn more about long polling, comet, gridFS or how files are stored, and in general things like replication sets, and sharding to help with performance (esp since Redhat has this openshift platform that we can build our own private clouds with).
I have some computer science background, but it seems like magic, so what am I missing? If you all could think of a few buzz words that make a social network tick that Meteor.js doesn't support, what would it be?
I hear things about parallel and concurrency (webworkers fixes that in part, no?), websockets, that high level languages like python or java are better off supporting. There's only one to learn my answers, and thats by doing, but thought someone could sway me one way or the other via this thread. Thanks!
This question encompasses a really broad idea and just focusing on using meteor alone would solve this issue. Here are a few points to consider:
I don't think this framework would be a good starting point to learn long-polling, gridFS, etc etc. Meteor aims to be a framework that tends to be more of an ecosystem of packages e.g. you can certainly roll your own aformentioned strategies -- however for dynamic updates, Meteor uses its own Data Delivery Protocol (DDP) supported/implemented by (surprise) a good bunch of core packages such as Spark.
Parallel processing and concurrency can be better off done using other languages, but why not with? Since Meteor is largely based on node.js, and node.js is really good with the aforementioned stuff plus it can play very well with other languages so you could integrate smoothly. Meteor doesn't really require you purely rely on it, as other languages would say the same thing. It's all in the general engineering / planning for your project. There are already lots of really good stuff out there that rely on Meteor, join in! don't be afraid. It all boils down to planning (and the courage/perseverance to pull it off, of course).
Right now, we cannot tell if Meteor would be incapable of the usual great stuff by gigantic websites. Sure, we can do live updates, (its own kind of) publish/subscribe patterns, and powerful stuff to boost development (look at the seven core concepts of meteor to best understand this). It is not impossible to replicate what is already out there, really. We can only say it with uncertainty at the moment mainly because.. (see next point)
The framework is so young! it's still at 0.6.x at the time of writing. Please take time to look at the Meteor Roadmap to see how things are going in terms of broader support for persistence/databases, performance considerations, and the official DDP specification.
I hope I have answered your enquiry (and more, I hope). I'm really excited for meteor myself as it could easily be the next big thing. We have a couple of (for-)production projects using Meteor as well, so you're getting direct insight from a person who has done quite a bit of hacking (and tons of research and first-hand experience) in Meteor. Not that i'm saying i'm an expert or so, it's just so much fun to work with Meteor and i'm totally not kidding you.
Hope this helps!
P.S.: Fair warning though, resources and documentation is really sparse at this point. I try to contribute to the community as much as I can about it (one of my starting points is here, on SO).
I work in a shop that is mostly .NET based, and we're trying to pick out a content management system to use. This means we mostly likely won't be able to use any of the common open source CMS projects (Plone, phpNuke, anthing not based on .NET, etc.).
Since I'm a huge usability nerd (just finished reading The Design of Everyday Things by Norman), I've been looking at them from that point of view. Frankly, I haven't been too impressed. This quote sums it up:
Most open source content management software is useless. The only thing worse is every commercial CMS I’ve used. - Jeffrey Veen
Here's a short list of our requirements:
Has to be .NET based
Prefer open source or on the inexpensive side
Limited feature set (we don't need too many features and they make things harder to use)
Does need Active Directory integration and robust permissions
Should be focused on web standards and usability
I know it's probably an impossible feature list, but are there any content management systems that kinda sorta look like they might not suck more than a Dyson?
Edit:
Here's the current situation:
I'm going to push for N2. I've got Active Directory integration working well (I even wrote a custom role provider). The only thing missing is workflow functionality. Hopefully I can get something going with that since it's the last sticking point. The N2Contrib project might provide a starting point if I can figure it out.
I would still love to check out Stencil CMS if/when it gets off the ground.
One of my co-workers was trying to get Umbraco going but wasn't having much luck.
Thanks for the help!
Self-plug is lame, but what you're describing is pretty much exactly what I am getting ready to release for $79 a pop. If you're still looking in a few weeks, take a peek. If you'd like, shoot me an email (rex#stencilcms.com).
I've heard both positive and negative feedback about Umbraco. A lot of people like Graffiti, but it's more blog-oriented than a full-blown CMS.
Check out N2 (http://n2cms.com/). I think that it covers most, if not all, of your requirements (I don't think it has Active Directory capability at this time). We are using N2 and I have really enjoyed how flexible it has been.
My company just completed a review of several commercial .NET-based CMS/portal platforms and, while I can't reveal who was in them (thanks, NDAs!), I can tell you that IMO they all sucked very, very badly.
Good luck on your search. I'll keep an eye on this thread in the hopes that there's something we missed.
We had a similar set of requirements and chose Telerik Sitefinity. It's got it's faults but overall I've been happy with it so far.
Unfortunately Jeffery speaks the truth. Which is probably why I build a new custom cms from the ground up every few years. Basically, the motivation for "boxed" CMS packages is to have every feature on earth and be everything to everyone and therefore do nothing particularly well for anyone. With the feature bloat comes the usability nightmares. Unless you start customizing and then you usually end up forking the project and losing the advantage of community updates.
Kentico CMS according your list:
Has to be .NET based
It's .net based, .NET Framework 2.0 or later
Prefer open source or on the inexpensive side
Free edition which can be used for commercial purposes is available, paid license starts at $750, source code is an option
Limited feature set (we don't need too many features and they make things harder to use)
Many built-in modules/features, anyway they can be easily disabled to keep the UI simple to use
Does need Active Directory integration and robust permissions
AD, Forms and Live Id! Integration
Should be focused on web standards and usability
UTF-8 Support including RTL languages, WAI Compliant, XHTML Compliant, XML, XHTML, HTML, XSLT, CSS.
Instant on-line demo or download available at:
http://www.kentico.com/Download.aspx
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
One thing that I keep hearing in reference to ASP.NET and MSFT technologies is that they cost money to use. Often when they are being compared to open source languages someone will mention that one factor in favor of open source is that it's free (to an extent). My question is, when does ASP.NET actually cost money to use in terms of using the proprietary technology?
Understandably there are the hosting fees, but I'm curious about the fees outside of these hosting fees. I'm especially curious about this as it relates one-person smaller-site development (non-team/large enterprise). Any help is appreciated.
(edits)
Some excellent answers. Much appreciated
The projects that I'm looking to use the technologies for would be personal sites and very small business sites (1 or 2). The intent would of course be that these projects get much bigger. It seems that for commercial production, fees will apply. What about just basic dynamic "shared hosting" sites that provide information?
You have to measure many things when you determine cost. We recently went through an evaluation of platform choice by an outside vendor, and the recommendation is that we stay with a Microsoft.NET platform. Why? For us, the reason is that once you get to an enterprise-level product suite, the difference is not as big as people would like you to believe.
Purchasing Microsoft products is a sound choice. The initial cost might seem high, but keep in mind if you get Software Assurance on your purchase (Visual Studio, for example) you are entitled to free upgrades as long as you keep you SA current - and it is at a fraction of the cost of a repurchase. Many people think you need to buy the full retail version every time, and that is just not true. Work with a larger vendor, like CDW, to help with licensing questions. They got someone from Microsoft's Licensing Division on the phone with us and helped us choose what was right. Not high-pressured at all. They actually talked us down on some of the things we thought we needed.
MSDN subscriptions are great. I have one through my employer, but also used to maintain one personally. If you are a contractor/self-employed, it is an operational expense. Like buying full products, renewing a MSDN subscription is very inexpensive compared to a purchase, and especially considering what you get. The licensing within MSDN is rather generous, and since you are a one-person shop, if I read that correctly, one MSDN is more than enough for your non-production needs. Plus, the bundled Support Incidents are a nice plus, as well.
There are many versions of Visual Studio, from the Express Editions all the way up to the Team Editions. For example, we are rolling out Team Foundation Server right now, so our costs are obviously higher. For a startup or small shop, there are TFS hosting partners and you can get Team Explorer for free. Or you can mix and match, using Visual Studio for development and something like VSS, SVN, or countless other version control products out there.
Just because someone "goes open source", that does not mean that it is free. Yes, the platform choice might be free, and the tools might be free, but there is a definite chance that you will need a commercial library or component some day. Plus, nothing prevents you from going with Open Source products with Microsoft, either. There are many open source projects written in .NET that can be leveraged with your solutions, and Microsoft is becoming a lot more transparent. We are working on a very large, enterprise solution right now and we are using only one "commercial" product, outside of our development tooling. There is a lot of Open Source usage, and a lot of implementations cobbled from community musings and examples.
The one thing that often goes unmentioned is the human cost that goes into these decisions. Microsoft is hated by many and their solutions might not be the fastest or most robust (although I will take IIS7 on W2K8 over any other web server configuration any day) they are focusing on making people more productive at what they can do. You aren't just buying products with them, you are actually buying productivity. As someone who has worked in a few Open Source shops, I am very appreciative of all the things that they have gotten right and understand that free does not always mean better.
I have a "one-person" side business and I really recommend looking into an MSDN subscription. It will give you access to tools and technologies that you would not otherwise be able to get your hands on without going a la carte in a retail route. Talk with someone, like a CDW, to help you figure out your licensing needs. If it works out, definitely try that route. You can cover all your in-house needs in a one person shop with an MSDN subscription, most likely (for example, a lot of the products are available to install to you (as a user) up to ten times as long as the machines that they are installed on are "yours" and non-production. There are exceptions to that, but not many.)
If that does not work, try the free route. You can definitely use Mono for .NET Development, as well as the Express Editions. I know a few C# developers who swear by Mono and could not be happier.
Best of luck to you!
Often when they are being compared to open source languages someone will mention that one factor in favor of open source is that it's free (to an extent). My question is, when does ASP.NET actually cost money to use in terms of using the proprietary technology?
Usually when people refer to "cost" in the way you described, they're implicitly referring to TCO, or total cost of ownership. The cost is not an explicit cost in that you've paid for something directly, but rather the long-term price of using something over its lifetime.
For example, even if a particular proprietary technology is free, it may be more difficult to hire and find people who know about it to work on your project. Consequently, if it is less popular than some open-source equivalent, you may wind up paying more for the same amount of labor because appropriately talented staff will be harder to find and in higher demand.
Conversely, if an open-source product is free but has low mindshare or performs poorly, it may well be worth it to pay for an expensive, closed-source proprietary solution rather than having to learn the idiosyncracies of the open-source version.
Naturally, there is some controversy surrounding just how to measure TCO, with both camps having some valid points.
.NET is free
C# compilers are free
Certain versions of Visual Studio are free, and you don't actually need it to write for .NET anyway (though it really, really helps!)
There are many free online resources for learning .NET, such as http://asp.net
In short, there's no real cost to using ASP.NET other than the hosting fee of the website or options you might buy to make things easier (better versions of Visual Studio.)
There's more of an ideological divide, with open source guys on one side being pretty anti-microsoft and so claiming it's high cost to use. I wouldn't worry about them. ;)
There are a couple of good answers already, but I'd like to add "it depends".
joseph.ferris obviously works in a large organization, where the cost of switching platforms is going to be very, very expensive, so the cost of paying the licensing costs is much less that the cost of switching. Take a look at Jonathan Schwartz's blog entry for Mar. 11, especially the section titled "When Free is too Expensive" for another reason to go with fully-supported infrastructure.
But consider a couple of other scenarios.
First, there's the hobbyist, which is what you seem to be addressing - you want to play around with the technology, and maybe put up a website or three. There aren't any issues with privacy or scalability, so you can deploy your application on an inexpensive shared hosting solution. In this case, costs are pretty much irrelevant - whatever platform you pick, you can get free tools to get you started. Remember kids, the first hit is always free.
For a startup, things are a bit different. If the goal is to build a large website, the potential licensing costs can be daunting - it's probably going to a lot cheaper to go with open source. In addition to the production environment, you need to pay for development environments, testing, etc. Even for a small company, licenses may be more than they have in the budget - a single Windows 2003 server Enterprise license lists for $4k. If you're trying to break into a competitive environment and compete on price, this alone may make you uncompetitive. I have seen situations where a Windows-based solution (server, database, and custom development coupled with a content management system) is two or three times the price of an open source solution.
I know that it has been answered, but I will put my 2 cents. Why are you wondering about the cost of ASP.net? In my opinion, the choice of technology in your case (1-2 ppl development freelancer team) should be governed by technology familiarity. If you are an ASP.net expert, the expense of buying the products and MSDN subscription is well-worth it, because it's your primary language of choice that you know well, hence the projects that you implement, will be done better and faster, so it makes sense to stay with it.
However, if you happen to know another technology just as well and you are comfortable that you can deliver a robust product on-time with it, it may be worth it to go low cost. As a contractor, the main objective is to not lose time/money hence you pick a technology that balances your expenses and time spent learning it. In other words, if you are a Java expert, there is no point of paying for asp.net. If you know asp,net well already, then sure, stay with it.
The clients rarely care whether you used Ruby, PHP, Python, Java or ASP.net. They care about time lines, their cost and quality.
I find that it does not cost much money to use. It does infact cost a pretty penny to get windows based hosting. Visual studio is also expensive. After those, though, not many expenses are encountered.
If you want to use the more professional versions of Visual Studio to develop your applications: you will need to pay for that.
Also, there are a lot of commercial components available on the market. These will save you time or improve your product, but at a cost.
For open source, there are also a lot of components, but in this scene most is free/open.
I am the .Net specialist in a consultancy with many difference flavors of developers using many different languages and frameworks. Because everyone is pretty much trying to push their own agendas with our different clients in terms of what technology to propose, I'm constantly finding myself in the classic arguments with them all about "why" .Net may be a better technology solution for a given clients requirements.
Often time here, the debate comes down to the issue of performance. Usually the areas that are argued about here consist of costs, maintainability, and performance. I have a hard time arguing about cost because in general open-source technologies are usually cheaper, and although and can usual put a good word in for .Net in terms of total cost of ownership (It seems to be pretty easy to convince people that .Net applications have relative low costs for maintainability if the application architecture has been thoughtfully designed), we will really only push .Net here if the client understands and is indifferent about the costs associated with Microsoft licensing. In terms of maintainability, like I mentioned before, the other developers here realize how much a difference it can make when an application is thoughtfully designed. I have had around 8 years of experience programming .Net solutions and I'm pretty confident in my ability to present to a client all the features and tool sets that .Net provides to give an application a long, and easy to maintain life span.
So again, what it usually boils down to is an argument over performance. Up until now, I have worked for companies that already used Microsoft development technologies to developer their applications so while I have discussed performance with others in the past I have never been a position where I have had to convince performance. My other co-workers are always boasting about these different website that they go to that show improved performance for open-source web applications. This all being said, what I would like to know from everybody here is where do you usually go to get your information about how may some .Net web applications have out performed other technologies?
Thanks in advance for the advice,
-Matt
I appreciate the detail, though I must say I forgot your question at the end. =)
Anyhow, this is something that has certainly been on my mind in the past. There is always a conflict on what technology is the best. We all know on each side you will find zealots, so it's quite difficult weeding out the facts. Professionally, I've seen successes/disasters on both sides of the fence.
For you, since you have a vested interest in .NET. I would showcase success stories, such as ... (insert whatever big name site you want) Facebook, SO, etc. I'd also find stories where things went wrong on the .NET side and pinpoint the reason. Like you said, it is often poor implementation. I don't know how many DailyWTF stories I've seen with ASP.NET sites behaving poorly but it gets traced back to 1) Poor design 2) Implementation 3) Coding.
Once you have a solid show case to justify the technology you can then of course talk about your own past experiences. You need to qualify yourself as being able to avoid the same pitfalls that your stories exposed.
.NET loses in performance against C/C++. In general, it will win over Python, Ruby, and PHP in baseline performance. The static typing tends translates into faster native code. (There are exceptions, such as Python's hand-tweaked set() performance being faster than HashSets in .NET)
The difference might come down to things like apache vs IIS (and their respective caching configurations), database architecture, etc. Features than can be misused or misunderstood (ViewStates and large GridViews, or using large numbers of hidden WebControls, for example)
Depending on what type of application you are building I've found that performance is rarely an issue. All the technologies out there can perform well enough.
When debating .net versus java/ruby/python etc I usually try to point out other benefits of .net.
There was this one time my boss asked me why .net instead of others? He wanted to know because he could get a PHP programmer for cheap. As part of the report we wrote a simple web application in 4 different languages and the .net app ran the fastest by far. After that we solidified behind .net. This was when .net was new so none of us really knew it well. We came from ASP, PHP, Coldfusion and Java backgrounds.
If you are looking for .Net performance stories you can listen to this dot net rocks show
I am evaluating WF for use in line of business applications on the web, and I would love to hear some recent first-hand accounts of this technology.
My main interest here is in improving the maintainability of projects and maybe in increasing developer productivity when working on complex processes that change frequently.
I really like the idea of WF, however it seems to be relatively unknown and many older comments I've come across mention that it's overwhelmingly complex once you get into it.
If it's overdesigned to the point that it's unusable (or a bad tradeoff) for a small to medium-sized project, that's something that I need to know.
Of course, it has been out since late 2006, so perhaps it has matured. If that's the case, that's another piece of information that would be very helpful!
Thanks in advance!
Windows Workflow Foundation is a very capable product but still very much in its 1st version :-(
The main reasons for use include:
Visually modeling business requirements.
Separating your business logic from the business rules and externalizing rules as XML files.
Separating your business flow from your application by externalizing your workflows as XML files.
Creating long running processes with the automatic ability to react if nothing has happened for some extended period of time. For example an invoice not being paid.
Automatic persistence of long running workflows to keep resource usage down and allow a process and/or machine to restart.
Automatic tracking of workflows helping with business requirements.
WF comes as a library/framework so most of the time you need to write the host that instantiates the WF runtime. That said, using WCF hosted in IIS is a viable solution and saves a lot of work. However the WCF/WF coupling is less than perfect and needs some serious work. See here http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx for more details. Expect quite a few changes/enhancements in the next version.
WF (and WCF) are pretty central to a lot of the new stuff coming out of Microsoft. You can expect some interesting announcements during the PDC.
BTW keeping multiple versions of a workflow running takes a bit of work but that is mostly standard .NET. I just did a series of blog posts on the subject starting here: http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx
About visually modeling business requirements.
In theory, this works quite well with a separation of intent and implementation. However, in practice, you will drop quite a few extra activities on a workflow purely for technical reasons, and that sort of defeats the purpose as You have to tell a business analyst to ignore half the shapes and lines.
Related question: When to use Windows Workflow Foundation? My answer there:
You may need WF only if any of the
following is true:
You have a long-running process.
You have a process that changes frequently.
You want a visual model of the process.
For more details, see Paul Andrew's
post: What to use Windows Workflow Foundation for?
Please do not confuse or relate WF
with visual programming of any kind.
It is wrong and can lead to very bad
architecture/design decisions.
So, if you have such requirements, then WF is a good candidate. Of course it is relatively complex, but mention that the problems that is trying to solve is also complex (and sometimes very complex). IMHO, it is very complex for example to dehydrate/rehydrate objects that have event handlers attached (with events that can be triggered when the object is not in memory).
I can not judge what you mean by "small to medium-sized project", but in general I would say that if your project has at least two requirements from the above list, then you can consider WF as a solution.
We've used WF in a large-ish SharePoint application and I can say it's OK. It has lots of power and flexibility. and, as Kevin mentions, once you grok the underlying concepts of workflows, you can do pretty much anything you want with it.
On the other hand, it has some really serious issues, like lack of versioning, which can really hurt your application in the future. We've been forced to deploy up to 3 parallel versions of the same workflow named xxx-v1, xxx-v2 and xxx-v3 to keep older instances running and have new instances use the updated versions. A real pain in the ass. Oh, and there are also some really non-intuitive concepts in there (correlation tokens, wtf??)
We had a project at work that I was involved in using Workflows.
The idea (from management), was that us programmers would write the Workflow Activities along with the "engine" and framework. Then non-programmers would take care of all the rest by compiling their own Workflows into dlls which the engine would automatically load.
Management was sold on this idea of non-programmers using Workflow to help develop software, and it was pretty much a complete waste of time. The problem we were trying to solve with this project was relatively complex and we knew from the very beginning that the software would have to be modified almost constantly (its calculations were dependent on other companies and governements).
The end result was that we were unable to make the Workflow modules generic enough for anyone else to use. So the programmers were the ones who were forced to work with the Workflows, and all the Workflows did was get in our way.
I've been using Workflow 4.0 for the last few months and although mostly impressed, I've found it extremely hard to learn.
For the most recent version (that comes with .NET 4.0 RC), there is next-to-no documentation on the web, in any books or no training courses available. I've only found articles relating to the now defunct 3.0 version. Even the MSDN documenation is light on the ground.
The workflow designer is not as intuitive as it should be by any means so learning is very hard. I've had to rely on answers from a single person on StackOverflow (thanks by the way Maurice!) - and I would be stuffed without his help.
So in summary, I think it has potential but you would be quite mad to learn it yet - wait for more training, documentation and books otherwise you will be going into it blind!
Last year we completed a working application with WF, now used as the backbone of an unbelievably huge system which is used by a very big bank for its mortgage process. The pe process has many steps starting from customer application to approval of credit.
Although it was a success, there were so many problems and crisis all along the way. And it wont worth the trouble for any smaller size projects.
I consider MS WF as a low-level workflow library rather than a fully fledged enterprise workflow product such as K2. It will enable you to build a workflow enabled application, but is not in itself a workflow application. My experiance of it in this capacity has been positive, although we have had to build a lot of our own infrastructure around it (a pub/sub framework, a worlkflow lifetime manager etc). A lot of the documentation out there is fairly simplistic and does not cover building up an enterprise workflow application based on MS WF.
Hard to learn. Quite flexible. Not to be confused with a visual tool for end users, only for programmers. Not sure if I like the dependancy property approach.
It really depends on what you want to do with it. I've only used it a little, but compared to more mature products like MetaStorm (I know technically it's a BPM, but there is still a workflow component), Process Choriographer and IBM MQ workflow, there's no comparison. It's just not mature enough. On the other hand it's free where the others are not and can probably get the job done. I don't know if I would place a multi-million dollar operation on it, but with smaller ones, I'd give it another shot. The real hurdle you are going to face is the change in thought process it requires. If you don't have developers that have worked with state systems before that can be a real hurdle.
Brian, I can't reply to your comment, but anyway, by versioning i mean making changes to the underlying code of the workflow without breaking already running instances, and gracefully applying updates to existing workflows. I'm not sure about 'stock' WF, but at least in SharePoint environment there's no concept of workflow versions so new versions have to be deployed as completely different workflows which becomes a maintenance nightmare.
This has nothing to do with 'rehydration', rehydration is the process by which you bring a 'dormant' workflow back to activity after some event or change in state. That is handled transparently by the workflow runtime.
WF ist integrated into SharePoint (WSS 3.0), and i have created quite a few workflows for various SharePoint-Websites, so i can tell about my experience of WF in SharePoint. Compared with other workflow-frameworks WF scores well. It's stable (i haven't experienced any mysterious errors), workflows are fairly easy to design (thank to the workflow-designer in Visual Studio) and you can use not only sequential but also state-machine workflows.
It's not perfect, of course, and a developer will definitly need some time to understand the concept (of i.e. the Activity Model); but it's definitely useable - even for "small tasks".
Never tried WFF, but I remember reading this article about WFF by Leon Bambrick where he basically says the whole genre of software development tools is nonsense. Might help you decide one way or the other.