Port Workflow Foundation to .NET Core #14862
Comments
|
cc: @terrajobst, @joshfree, @weshaggard |
|
We need System.Xaml to be opened before a serious effort can be made at porting. |
|
I understand @JakeSays . The point is that WF can have its workflow definitions made in C# classes instead of XAML (for now) and many people don't even use the XAML representation of it. Later when System.Xaml is opened, we can integrated the visual designer and XAML definitions as well. Also, we have working on a Workflow engine that strictly follows WF usage/implementation but instead of use XAML as base storage for workflow definitions, we have it based on Json for the store, which open a lots of opportunities for new workflow designers on any platforms(not only VS or the hosted designer component for WPF/WForms) and have several benefits as faster reading/writing, simplicity of schema, faster loading/compilation and runtime operations. It can even be used to enpower client workflows, to guide application UI flows on Windows Phone/Store apps for example due to its lightweight runtime. I really think WF is a REALLY powerful component on .Net platform, but for today technologies, XAML still a "limiter" of it but, if for a strategy decision of MS we can keep it as it is and port to CoreCLR. Thanks |
|
@zhenlan can talk towards current thinking around WF |
|
@galvesribeiro many people may not use xaml, but many do, and it is indeed considered a core part of WF. We use xaml extensively, so I would see WF without xaml support hardly worth using. I would prefer we continue lobbying Microsoft to open System.Xaml. And using JSON as a replacement is just not appealing in the least. |
|
@galvesribeiro @JakeSays We really like to learn how much WF customers are interested in having .NET Core version of WF so it is great to hear feedback from the community. If there are enough demand, it will be helpful for us to move forward. We are at early stage of evaluating the feasibility, dependencies, feature priorities etc. So it will be very helpful for us to learn what scenarios are in your mind, why WF on .NET Core (vs. WF in full .NET) will be useful to you and what WF features you like to see first. |
|
@galvesribeiro In your scenario with building workflows in code and storing those definitions as JSON, what are you (planning on?) using for expressions? Are you using VB expressions, C# expressions, or do you have your own expressions activities based on CodeActivity to deal with expressions? Thanks for the input. |
|
@JakeSays its ok for me to use XAML. I only care about performance... @zhenlan We have a electronics payment switch that process billions of credit/debit card transactions a day for some banks here in Brazil, and some others abroad. We were full on-premises and we are updating the technology to be fully cloud, and offered as a service on Azure. We got an Enterprise Agreement in order to explore everything we need from Azure here as a multi-tenant payment processing platform for our customers. We are investigating the usage of NanoServer for and CoreCLR so we can reduce footprint, attack surface and maintenance spent to run our services and we noticed that coreCLR does not have (at least) System.Activities ported yet. In other words, no Workflow Foundation. Our core processing engine is a business engine built on top WF and it contains 40+ custom activities focused on our business. This engine process in real time the transaction process/rules in order to get the transaction approval. We need to scale it over demand, and does it with the current implementation of WF in cloud, let's say is not feasible. Porting it to .net core, instead of keep it on the .net full(server profile) will open the possibilities to run client workflows, that is something we really miss on our business. Those client workflows can make people develop client-business logic declarative, in a way small devices like smartphones, wearables, IoT, and our payment terminal devices can take some decisions without writing real repetitive code. Since we didn't found any efforts on WF for .net Core, and even it wasnt change for years and still depending on XAML, we decided to start our own Workflow Engine that behaves exactly same way as WF does. Same activities Model, same code style, etc, but a lot lighter and being based on Json as their definition store. This allow devices with small compute power, to process the workflows without the overhead of dealing with XAML/XML so most of our code made for WF is working without many changes on Json definitions instead of XAML-based workflows. Also, moving away from XAML, will open possibility for new workflow designers... Not stuck on Visual Studio and on WPF applications to re-host the VS designer. What I'm trying to suggest is one of those option:
I'm not asking you to build a team or to engage yourself into a new product. The community can do it as they are doing for ASP.Net and Entity Framework. Make it an external and auxiliary framework, not embedded on the core. Thanks |
|
@jimcarley The expressions would be compiled the same way they are today on XAML. In one of our workflows we have this(it can be a VBValue as well, just got a sample): The expressions on XAML today, are mostly returning a boolean, or assign some value to some variable, so this would be stored the same way as it is stored today on XAML, but in Json and it could be compiled following the same ideas it is today. If you look at Azure Resource Manager(ARM), they already did that! They have the resources deployment made as a Json Template, which has dependencies and a flow, and the variables can be called as expressions. Take a look at this: "variables": { Ok, they are using JavaScript functions but the principle is the same. They have an $schema variable on top of the template which guide the document structure, steps on the deployment process that we can make as activities. The design is pretty similar of the WF but this DSL focus on the resource group deployment. We can make it more general, and use activities the same way they do in current WF implementation. If you guys decides that it worth a shot, we can start drawing some documentation on another issue which will guide the architecture of the "new WF". If it sound so crazy and out of your plans let me know, we will still develop it at our end to support .net core, and release it later as a nuget for people. I'm just trying to make this wonderful framework up to date with the current(upcoming) technologies. This is really a business need for us. We depend a lot on WF, but if it doesn't get faster and supported on coreCLR, we will need to start preparing this new framework so when the NanoServer+coreCLR are RTM, we can move for it. Please let me know if your have any questions. Thanks PS: I'm on gitter channels every day if you need chat. |
|
@galvesribeiro So you are using the TextExpressionCompiler to compile the expressions after creating the Activity object from the workflow definition that is stored in the JSON. Right? |
|
@jimcarley we don't have yet the expression compiler working. We still designing it using the same principles of TextExpressionCompiler but yes, it looks like pretty same concept. Current implementations looks like is tied to System.XAML yet. Since its not open, I can't confirm if will work the same way (internally) as TextExpressionCompiler but yes, after the activity is loaded, we should evaluate/compile the expressions(if not already in a cache) and expose a Expression object on it to be evaluated by the consumers of the activity (if required). |
|
Last year I did some work on the expression side to enable C# expression support in self-hosted WF designers. It was based on bits of nrefactory and roslyn. I can dig it up if anyone is interested. @galvesribeiro after thinking more on your json approach, in the end I guess it really wouldn't matter for new development. If MS won't open xaml support then this might work. @zhenlan I agree with @galvesribeiro in that we're not necessarily looking for MS to form a team to port WF. This is definitely something the community could do with guidance from your team, etc. |
|
@JakeSays I agree with you that the storage actually doesn't matter if we are creating again WF for coreclr. The point is, why keep using XML instead of Json since we have many tests around the web comparing the (de)serialization performance of both and json is far away faster and consume less resources than it?(for example comparing Newtonsoft's Json.Net with regular XML serializer) If WF would run on a small footprint client device(any IoT), each memory byte matters. Also, with json, is a lot simpler to get new web based WF designers right away. The expression compilation and execution is not hard to implement. It is roughly a parser of the string to build the expression object. The hard part (imho), is to get intellisense on VS for the types used while designing the WF, but I'm pretty sure Roselyn and language services can help us with it and VS has infrastructure for it. |
|
@galvesribeiro you mention you've already built your own workflow engine with JSON-based workflow definition and serialization. If WF were ported to Core, would you actually use it? |
|
@dmetzgar we started developing and testing it as a proof-of-concept that we can achieve better result in a cleaner WF with almost no dependencies on the framework, which is good to get it working on coreclr. We don't have it ready. I would love to not have to build my own engine and keep using WF even if it is based on XAML but ported to coreclr and if it follows the same concept of coreclr versions of EntityFramework and ASP.Net for example(don't depend on server libraries and runs everywhere). The point is, if it will still depends on XAML and on Server profile, it will keep being slow(requiring too much resources), limited on designer choices, etc. My suggestion is to port it to coreclr using Json, and removing lots of dependencies that it have today leaving the user able to run it anywhere they want the same way you can run ASP.Net vNext on a IoT ARM device(soon as ARM support is done!) and don't worry about dependencies and high resource consumption. All our workflows today are created with current version with some of them wrote with pure code and some with XAML buth in both cases, we still have dependencies. IMHO, port it to coreclr as it is, does not bring so much benefits unless someone comes with super new lightweight engine for XAML/XML parsing/rendering for both runtime and design time. But if you guys decide to port as is, we will keep using it anyway, since it will make my XAML workflows works(I hope) from day 0, even if I know it will not bring any practical benefits... Again, I(probably @JakeSays and other WF users) can help on this port in both ways(XAML or JSON) regardless of you guys decide. I just want to make sure this port is not just copy&paste&fix to get it working, and instead, it brings really benefits for people who are using it the following the same idea of coreclr and it can run everywhere without painpoints. Thanks |
|
@galvesribeiro I agree that XAML is too tightly integrated into WF. Going back to Dharma's original book on workflow, he had a sample that built a workflow from Visio. At least with porting to core, we can carve it up so the runtime is separate from XAML. That allows us to proceed with or without the XAML team porting to core and we can always add XAML workflow support later as a separate GitHub project/NuGet package. I am definitely all for making it possible to define and persist workflows in any format. Thanks, this feedback is helpful. |
|
@dmetzgar I have no doubts that someday XAML will be ported to core... If .net core going to run on windows phone or any windows 10 mobile device, it will happens at some time and I completely agree with you that we can build a new core, and add the persistense of both definitions and state of the workflow later as well. So, what we need to do in order to start porting it? (we already signed the contributor agreement and have other NDAs as a company with MS, etc) Thanks |
|
@galvesribeiro I appreciate the enthusiasm! As tempting as it is to open a GitHub repo and start hacking there are a few steps involved. Also, it's not only System.Xaml that has to be carved out. There are other dependencies deeply ingrained in WF like System.Transactions and some shared components with WCF. We're looking into each of these. |
|
I understand. Well, I don`t want to push you guys, I'm just worried about time. We have a decision to make now to move forward building on our own, or to join the community here and port WF to coreCLR so it can meet our timeline for our product. |
|
@dmetzgar Have you considered publishing the parts that can be open sourced right now to https://github.com/Microsoft/referencesource? I think that could be significantly simpler than creating a full-fledged open source project that actually works. That way, you can take your time with the proper version, and others can create their own partial/custom versions in the meantime. |
|
@svick WF components in full .NET have already been published on github referencesource a while ago. For example, you can find https://github.com/Microsoft/referencesource/tree/master/System.Activities |
|
@zhenlan yes, the problem with it is that some dependencies are not "resolvable"... I can't see what is the behavior of some classes correctly, due to its dependency on System.Xaml that is not public... We can always figure out by our end, but it will mean that we don't know for sure if we are following the same way. @dmetzgar System.Transaction is something that is not open (yet?), but I think we can deal with it (for now). Regarding the WCF, the dependency tree only show me activities and the Workflow Services Host. Nothing on the core (IIRC) is dependent on WCF... |
|
@galvesribeiro The situation with System.Transactions is more complex than that. It's sprinkled throughout the WF runtime and is heavily depended on in durable instancing, which is where the base classes are for persistence. WCF and WF were merged into the same team around .Net 4.0 timeframe so we have things like System.ServiceModel.Internals used by both WCF and WF. .Net core has a lot of the big things ported, but there's plenty that's missing. Working around missing pieces may require design changes or rewrites of features. None of these problems are insurmountable, I just don't want to trivialize the effort. That goes for the code and everything around it like getting legal approval, build environments, testing infrastructure, etc. We definitely want the community to help and we're working towards that. Whether you should write your own port or wait for the "official" one depends on your timeframe. Running workflows on Nano server is one of our biggest scenarios and I'd love to get your help on it. |
|
@dmetzgar I understood, always had some delay when any question had to be forward to PR or Legal when I was on you side :) Well, if at least we have a notion of some timeframe, we can prepare ourselves and can wait for it. I hate the idea off implement something in "the wrong place" or when there is already some efforts being spent somewhere that we can join forces to do better. Please let me know if is there anything we can do, or if you have any news, or ping me if you need any suggestion regarding the design/port. Thanks |
|
As the timeframe gets clearer I'll make updates on this thread. I'd be happy to hear what other scenarios people are interested in. WF on Nano is the primary scenario right now, but it would be good to know what others are doing. |
|
Hi guys, besides XAML and JSON, there's a COOL way of composing activities : metaprogramming. Take a look at my experimental project: Metah.W: A Workflow Metaprogramming Language (https://github.com/knat/Metah). |
|
@JakeSays Can you provide some guidance about how to enable C# expression support in self-hosted WF. |
|
Please keep Xaml. :) JSON serialized objects would be interesting, too. But I would prefer to see providers that are configured somehow in the framework to choose the preferred format. |
|
@dmetzgar (and other MSFT folks) are there any news regarding this subject? |
|
We have been working on this and have made a lot of progress. XAML is currently not available in Core so we're focusing on the runtime. We're looking at opening up to other serializers. So instead of choosing sides between JSON or XAML, we'd prefer allowing you to bring your own serializer. There's still more compliance and legal things to get approved. Since not a lot of customers are pushing for this port it has been a lower priority. |
|
We have a Solution based on WF. We are creating a steps of activities using WF and this workflow will be delivered to all subscribers and they will process the actions based on WF. We love WF to much. supporting cross-platform is our company direction. We are very interested to have WF on .NET CORE. |
|
There is CoreWF which is the code of Workflow Foundation partially ported to .net core. You can use Workflow foundation cross platform now. You just cannot use XAML based workflows at this time. I have a branch where I've worked on adding support for Dynamic Activity on top of Net Standard 2.0. The XAML parsing process requires Microsoft to open System.XAML sufficiently for us to be able to make progress parsing the files correctly. You can track the progress on the issue here: https://github.com/dmetzgar/corewf/issues/6 and in my various attempts at bringing notice to this issue: The .Net compatibility pack has a "Maybe" on the System.XAML front. But no news has filtered about its inclusion. The issue Ship .Net Framework Compatibility Pack currently lists "no plans" for System.XAML. Maybe also the issue Customer Adoption Epic could be used to tell your story of how adding Workflow Foundation (and System.Xaml) would allow your company to ship a product. My company is also invested in WF: We have a product for Energy companies where our clients create workflows using Workflow Foundation. |
|
Thank you for your reply.
it was very useful appreciate it.
…On 2 Nov 2017 18:22, "Eric Winnington" ***@***.***> wrote:
There is CoreWF <https://github.com/dmetzgar/corewf> which is the code of
Workflow Foundation partially ported to .net core. You can use Workflow
foundation cross platform *now*. You just cannot use XAML based workflows
at this time.
I have a branch where I've worked on adding support for Dynamic Activity
on top of Net Standard 2.0 <https://github.com/ewinnington/corewf>.
The XAML parsing process requires Microsoft to open System.XAML
sufficiently for us to be able to make progress parsing the files correctly.
You can track the progress on the issue here: dmetzgar/corewf#6
<https://github.com/dmetzgar/corewf/issues/6> and in my various attempts
at bringing notice to this issue:
On CoreFX
<https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209>
On ReferenceSource
<microsoft/referencesource#39>
The .Net compatibility pack
<https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md>
has a "Maybe" on the System.XAML front. But no news has filtered about its
inclusion. The issue Ship .Net Framework Compatibility Pack
<https://github.com/dotnet/corefx/issues/24909> currently lists "no
plans" for System.XAML.
Maybe also the issue Customer Adoption Epic
<https://github.com/dotnet/corefx/issues/24751> could be used to tell
your story of how adding Workflow Foundation (and System.Xaml) would allow
your company to ship a product.
My company is also invested in WF: We have a product for Energy companies
where our clients create workflows using Workflow Foundation.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY>
.
|
|
Hi, |
|
Thought I would post here for the sake of awareness. I was reading over the following documentation and it made me think of this thread: Looks like Dynamics365 and PowerApps are doing a mind meld and are using Windows Workflow in some capacity for its workflow handling now. This of course is all Windows-only, but in the new era of cross-platform, etc... how long will this last? |
|
I don't know what I am supposed to be using. I wish MSFT would do this. Bring clarity Microsoft. |
|
@VenkateshSrini, you should also look into Cadence: https://github.com/uber/cadence |
|
Looking for a. Net core version |
|
Not going to happen.
From: VenkateshSrini <notifications@github.com>
Sent: Wednesday, September 26, 2018 12:30 AM
To: dotnet/corefx <corefx@noreply.github.com>
Cc: Jeffrey Michelson <JMichelson@unitec-corp.com>; Mention <mention@noreply.github.com>
Subject: Re: [dotnet/corefx] Port Workflow Foundation to .NET Core (#2394)
Looking for a. Net core version
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY>.
|
|
Too bad |
|
So what is Microsoft offering for ifttt or workflow in non Azure ecosystem. When they want to enable things like ml out of Azure why not workflows |
|
Check out Dan Gerlag’s work.
https://github.com/danielgerlag/workflow-core
From: VenkateshSrini <notifications@github.com>
Sent: Wednesday, September 26, 2018 8:34 AM
To: dotnet/corefx <corefx@noreply.github.com>
Cc: Jeffrey Michelson <JMichelson@unitec-corp.com>; Mention <mention@noreply.github.com>
Subject: Re: [dotnet/corefx] Port Workflow Foundation to .NET Core (#2394)
So what is Microsoft offering for ifttt or workflow in non Azure ecosystem. When they want to enable things like ml out of Azure why not workflows
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH-Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY>.
|
|
There is CoreWF which is a port of Workflow foundation to .net core. This port is progressing. We are looking for people to help. The next major stepping stone is to compile loaded workflows with Roslyn so that we can use code in the workflow parameters, this is needed for the XAML defined workflows. If you define workflows in Imperative core, you can use CoreWF now. |
|
Thanks for your work @ewinnington and @dmetzgar ! The XAML support through Portable.XAML in CoreWF is a huge deal for that effort. @dmetzgar Do you plan on publishing a new version to NuGet soon? |
|
Hi all, Is this all production ready. We are lolling the work flow definition to be done from external Ui. But the engine should be able to load the definition and work from their on. More of an iffft kind |
|
@VenkateshSrini, I don't think it is necessary for Microsoft to provide a cross-platform workflow framework. In the .NET Framework days Microsoft provided everything, which was to the detriment of the overall community. I'd like to see more .NET open source libraries adopted by organizations and made "production ready". @watertree, I'm waiting on a new release of Portable.Xaml. There's a critical fix needed for CoreWF XAML support. |
|
What's the alternative for long running workflows for now (with persistance)? Only paid ones? |
|
FYI: https://github.com/danielgerlag/workflow-core We use it in our company with very good results. |
|
For those still following, the CoreWf project has just advanced a significant milestone with the integration of Roslyn to allow the execution of dynamically loaded XAML workflows. If you still need Workflow Foundation on dotnet core, check it out. |
|
Hi , |
The instance store has not been ported yet, the designer is not on core and the WCF Service is not available due to WCF server not being on core yet. Please make an issue on the CoreWf repo and list the requirements you have. We can continue the conversation there. The current nuget for corewf is out of date and does not include the Roslyn based runtime Xaml execution which has just been merged. We are still looking for feedback to see what works and what doesn’t. |
|
Does this mean that it is never going to happen? |
|
It's not going to happen. It was never going to happen - - no offense to those who put in their best efforts. Check out Dan Gerlag's project (https://github.com/danielgerlag/workflow-core) or bite-the-bullet and jump on-board the Azure LogicApps train. |
|
Hello, this is october 2020 calling. Any news/updates/releases on Workflow Foundation on .NET Core? or should we all move to Elsa? https://elsa-workflows.github.io/elsa-core/ |
|
@wstaelens I think the MS answer was pretty clear: WF will not be officially ported to .Net Core. The suggested alternative is CoreWF. |
ghost
locked as resolved and limited conversation to collaborators
and others
Hello,
I don't see in the plans neither here and coreCLR for porting Workflow Foundation for CoreCLR...
We want know how can we start porting it and add PRs for it here.
Thanks
The text was updated successfully, but these errors were encountered: