[SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Christofer Dutz
Hi all,

I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.

As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
and have the drivers in each supported language generated.

As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
How does the information provided by users get in  requests and out of responses?
So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
And can you imagine my surprise when I noticed Apache has something for this in its toolbox?

Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
would be interested in joining us and working on this.

I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.

Any opinions, suggestions, things I should consider?

Chris
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Woonsan Ko-3
Hi Chris,

On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz
<[hidden email]> wrote:

>
> Hi all,
>
> I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
> Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.
>
> As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
> and have the drivers in each supported language generated.
>
> As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
> messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
> How does the information provided by users get in  requests and out of responses?
> So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
> And can you imagine my surprise when I noticed Apache has something for this in its toolbox?
>
> Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
> goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
> would be interested in joining us and working on this.

Sounds cool! I'm not familiar with DFDL, but I'd like to help with
some of my experiences with SCXML and our current Commons SCXML
implementations.

>
> I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.
>
> Any opinions, suggestions, things I should consider?

One issue with the SCXML subproject is that it has been refactored a
lot since v2, but it has never been released for years. So, people
seem to feel hard to try it.
Another is that Ate and I have used it mostly for a specific use
case--document publication workflow in CMS--with M1 [1]; it kind of
lacks of diversity. In that sense, new faces from diverse backgrounds
will be more than welcome and more beneficial to the community.

Perhaps you can test some PoC or its scenarios in conceptual level
with M1 tag to see if everything is okay.

Another thing is that we should consider releasing it often (again
like 0.x's). Perhaps just because we bumped the version to 2.0.0
thanks to the expected whole refactoring, we might just have been
hesitant to cut a release of v2.x.x while we're not ready yet to
fulfill all the requirements of SCXML specification.

Regards,

Woonsan

[1] http://commons.apache.org/proper/commons-scxml/roadmap.html

>
> Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Christofer Dutz
Hi all,

So I just finished a first operational scxml based state machine, that connects to a remote host and exchanges messages described by dfdl by serializing xml templates which I define inside my CustomAction elements of my scxml document.

And the coolest thing is, that the remote Siemens PLC answered correctly :-)

Still needs a lot of work. Especially we would need at least working snapshots of commons-scxml (the ones on repo.apachr.org are hugely out of sync) ... You need help with that? Had to tweak some minor things to build locally, but should be easy to fix.

Would be cool, if someone could review what I'm doing (haven't committed it yet as it would break the build due to outdated snapshots) ... Don't wanna walk into the wrong direction and if we work together, I bet this could be for the benefit of Plc4x and commons-scxml :-)

Chris


Outlook für Android<https://aka.ms/ghei36> herunterladen

________________________________
From: Woonsan Ko <[hidden email]>
Sent: Tuesday, January 29, 2019 4:49:16 PM
To: Commons Developers List
Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Hi Chris,

On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz
<[hidden email]> wrote:

>
> Hi all,
>
> I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
> Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.
>
> As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
> and have the drivers in each supported language generated.
>
> As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
> messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
> How does the information provided by users get in  requests and out of responses?
> So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
> And can you imagine my surprise when I noticed Apache has something for this in its toolbox?
>
> Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
> goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
> would be interested in joining us and working on this.

Sounds cool! I'm not familiar with DFDL, but I'd like to help with
some of my experiences with SCXML and our current Commons SCXML
implementations.

>
> I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.
>
> Any opinions, suggestions, things I should consider?

One issue with the SCXML subproject is that it has been refactored a
lot since v2, but it has never been released for years. So, people
seem to feel hard to try it.
Another is that Ate and I have used it mostly for a specific use
case--document publication workflow in CMS--with M1 [1]; it kind of
lacks of diversity. In that sense, new faces from diverse backgrounds
will be more than welcome and more beneficial to the community.

Perhaps you can test some PoC or its scenarios in conceptual level
with M1 tag to see if everything is okay.

Another thing is that we should consider releasing it often (again
like 0.x's). Perhaps just because we bumped the version to 2.0.0
thanks to the expected whole refactoring, we might just have been
hesitant to cut a release of v2.x.x while we're not ready yet to
fulfill all the requirements of SCXML specification.

Regards,

Woonsan

[1] http://commons.apache.org/proper/commons-scxml/roadmap.html

>
> Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Woonsan Ko-3
On Thu, Jan 31, 2019 at 11:21 AM Christofer Dutz
<[hidden email]> wrote:
>
> Hi all,
>
> So I just finished a first operational scxml based state machine, that connects to a remote host and exchanges messages described by dfdl by serializing xml templates which I define inside my CustomAction elements of my scxml document.
>
> And the coolest thing is, that the remote Siemens PLC answered correctly :-)
>
> Still needs a lot of work. Especially we would need at least working snapshots of commons-scxml (the ones on repo.apachr.org are hugely out of sync) ... You need help with that? Had to tweak some minor things to build locally, but should be easy to fix.

If it helps, we (Ate and I) have deployed M1 tag to our maven repo and
used it for years already in our products:
- http://maven.onehippo.com/maven2/org/apache/commons/commons-scxml2/2.0-M1/

If we can deploy it or a snapshot to an ASF repo, it will help the
community. Should we decide to cut a release or just deploy to a
snapshot repo?

>
> Would be cool, if someone could review what I'm doing (haven't committed it yet as it would break the build due to outdated snapshots) ... Don't wanna walk into the wrong direction and if we work together, I bet this could be for the benefit of Plc4x and commons-scxml :-)

Cool. Give us a link.
From my experiences, it seems better not to depend on too many
expressions or scripts. Keeping it to the most normal standard
elements, with some custom actions to be used still in a declarative
way, seems simpler and more maintainable to me.

Regards,

Woonsan

>
> Chris
>
>
> Outlook für Android<https://aka.ms/ghei36> herunterladen
>
> ________________________________
> From: Woonsan Ko <[hidden email]>
> Sent: Tuesday, January 29, 2019 4:49:16 PM
> To: Commons Developers List
> Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
>
> Hi Chris,
>
> On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz
> <[hidden email]> wrote:
> >
> > Hi all,
> >
> > I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
> > Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.
> >
> > As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
> > and have the drivers in each supported language generated.
> >
> > As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
> > messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
> > How does the information provided by users get in  requests and out of responses?
> > So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
> > And can you imagine my surprise when I noticed Apache has something for this in its toolbox?
> >
> > Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
> > goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
> > would be interested in joining us and working on this.
>
> Sounds cool! I'm not familiar with DFDL, but I'd like to help with
> some of my experiences with SCXML and our current Commons SCXML
> implementations.
>
> >
> > I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.
> >
> > Any opinions, suggestions, things I should consider?
>
> One issue with the SCXML subproject is that it has been refactored a
> lot since v2, but it has never been released for years. So, people
> seem to feel hard to try it.
> Another is that Ate and I have used it mostly for a specific use
> case--document publication workflow in CMS--with M1 [1]; it kind of
> lacks of diversity. In that sense, new faces from diverse backgrounds
> will be more than welcome and more beneficial to the community.
>
> Perhaps you can test some PoC or its scenarios in conceptual level
> with M1 tag to see if everything is okay.
>
> Another thing is that we should consider releasing it often (again
> like 0.x's). Perhaps just because we bumped the version to 2.0.0
> thanks to the expected whole refactoring, we might just have been
> hesitant to cut a release of v2.x.x while we're not ready yet to
> fulfill all the requirements of SCXML specification.
>
> Regards,
>
> Woonsan
>
> [1] http://commons.apache.org/proper/commons-scxml/roadmap.html
>
> >
> > Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Christofer Dutz
Hi,

I would opt for setting up Jenkins to auto deploy snapshots to the Apache repo. Done that for quite a lot of projects, so happy to help out.

Cutting a release would be required for us to use it in our drivers (or we can't Release them). I will definitely not use an "unofficial release" in an Apache project. So a formal one would be required. But I'm happy to help get it there. However I would need to know what's still missing.

Chris



Outlook für Android<https://aka.ms/ghei36> herunterladen

________________________________
From: Woonsan Ko <[hidden email]>
Sent: Friday, February 1, 2019 9:09:53 AM
To: Commons Developers List
Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

On Thu, Jan 31, 2019 at 11:21 AM Christofer Dutz
<[hidden email]> wrote:
>
> Hi all,
>
> So I just finished a first operational scxml based state machine, that connects to a remote host and exchanges messages described by dfdl by serializing xml templates which I define inside my CustomAction elements of my scxml document.
>
> And the coolest thing is, that the remote Siemens PLC answered correctly :-)
>
> Still needs a lot of work. Especially we would need at least working snapshots of commons-scxml (the ones on repo.apachr.org are hugely out of sync) ... You need help with that? Had to tweak some minor things to build locally, but should be easy to fix.

If it helps, we (Ate and I) have deployed M1 tag to our maven repo and
used it for years already in our products:
- http://maven.onehippo.com/maven2/org/apache/commons/commons-scxml2/2.0-M1/

If we can deploy it or a snapshot to an ASF repo, it will help the
community. Should we decide to cut a release or just deploy to a
snapshot repo?

>
> Would be cool, if someone could review what I'm doing (haven't committed it yet as it would break the build due to outdated snapshots) ... Don't wanna walk into the wrong direction and if we work together, I bet this could be for the benefit of Plc4x and commons-scxml :-)

Cool. Give us a link.
From my experiences, it seems better not to depend on too many
expressions or scripts. Keeping it to the most normal standard
elements, with some custom actions to be used still in a declarative
way, seems simpler and more maintainable to me.

Regards,

Woonsan

>
> Chris
>
>
> Outlook für Android<https://aka.ms/ghei36> herunterladen
>
> ________________________________
> From: Woonsan Ko <[hidden email]>
> Sent: Tuesday, January 29, 2019 4:49:16 PM
> To: Commons Developers List
> Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
>
> Hi Chris,
>
> On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz
> <[hidden email]> wrote:
> >
> > Hi all,
> >
> > I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
> > Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.
> >
> > As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
> > and have the drivers in each supported language generated.
> >
> > As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
> > messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
> > How does the information provided by users get in  requests and out of responses?
> > So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
> > And can you imagine my surprise when I noticed Apache has something for this in its toolbox?
> >
> > Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
> > goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
> > would be interested in joining us and working on this.
>
> Sounds cool! I'm not familiar with DFDL, but I'd like to help with
> some of my experiences with SCXML and our current Commons SCXML
> implementations.
>
> >
> > I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.
> >
> > Any opinions, suggestions, things I should consider?
>
> One issue with the SCXML subproject is that it has been refactored a
> lot since v2, but it has never been released for years. So, people
> seem to feel hard to try it.
> Another is that Ate and I have used it mostly for a specific use
> case--document publication workflow in CMS--with M1 [1]; it kind of
> lacks of diversity. In that sense, new faces from diverse backgrounds
> will be more than welcome and more beneficial to the community.
>
> Perhaps you can test some PoC or its scenarios in conceptual level
> with M1 tag to see if everything is okay.
>
> Another thing is that we should consider releasing it often (again
> like 0.x's). Perhaps just because we bumped the version to 2.0.0
> thanks to the expected whole refactoring, we might just have been
> hesitant to cut a release of v2.x.x while we're not ready yet to
> fulfill all the requirements of SCXML specification.
>
> Regards,
>
> Woonsan
>
> [1] http://commons.apache.org/proper/commons-scxml/roadmap.html
>
> >
> > Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Woonsan Ko-3
On Fri, Feb 1, 2019 at 5:02 AM Christofer Dutz
<[hidden email]> wrote:
>
> Hi,
>
> I would opt for setting up Jenkins to auto deploy snapshots to the Apache repo. Done that for quite a lot of projects, so happy to help out.

Please help and direct us! :-)
I once tried it but got in stuck before:
- https://issues.apache.org/jira/browse/SCXML-236
- https://issues.apache.org/jira/browse/INFRA-10366

>
> Cutting a release would be required for us to use it in our drivers (or we can't Release them). I will definitely not use an "unofficial release" in an Apache project. So a formal one would be required. But I'm happy to help get it there. However I would need to know what's still missing.

Me, too!

@Ate, could you chime in here to give insights on the current status
and what we can do together to be able to cut a release (soon)?

Cheers,

Woonsan

>
> Chris
>
>
>
> Outlook für Android<https://aka.ms/ghei36> herunterladen
>
> ________________________________
> From: Woonsan Ko <[hidden email]>
> Sent: Friday, February 1, 2019 9:09:53 AM
> To: Commons Developers List
> Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
>
> On Thu, Jan 31, 2019 at 11:21 AM Christofer Dutz
> <[hidden email]> wrote:
> >
> > Hi all,
> >
> > So I just finished a first operational scxml based state machine, that connects to a remote host and exchanges messages described by dfdl by serializing xml templates which I define inside my CustomAction elements of my scxml document.
> >
> > And the coolest thing is, that the remote Siemens PLC answered correctly :-)
> >
> > Still needs a lot of work. Especially we would need at least working snapshots of commons-scxml (the ones on repo.apachr.org are hugely out of sync) ... You need help with that? Had to tweak some minor things to build locally, but should be easy to fix.
>
> If it helps, we (Ate and I) have deployed M1 tag to our maven repo and
> used it for years already in our products:
> - http://maven.onehippo.com/maven2/org/apache/commons/commons-scxml2/2.0-M1/
>
> If we can deploy it or a snapshot to an ASF repo, it will help the
> community. Should we decide to cut a release or just deploy to a
> snapshot repo?
>
> >
> > Would be cool, if someone could review what I'm doing (haven't committed it yet as it would break the build due to outdated snapshots) ... Don't wanna walk into the wrong direction and if we work together, I bet this could be for the benefit of Plc4x and commons-scxml :-)
>
> Cool. Give us a link.
> From my experiences, it seems better not to depend on too many
> expressions or scripts. Keeping it to the most normal standard
> elements, with some custom actions to be used still in a declarative
> way, seems simpler and more maintainable to me.
>
> Regards,
>
> Woonsan
>
> >
> > Chris
> >
> >
> > Outlook für Android<https://aka.ms/ghei36> herunterladen
> >
> > ________________________________
> > From: Woonsan Ko <[hidden email]>
> > Sent: Tuesday, January 29, 2019 4:49:16 PM
> > To: Commons Developers List
> > Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
> >
> > Hi Chris,
> >
> > On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz
> > <[hidden email]> wrote:
> > >
> > > Hi all,
> > >
> > > I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
> > > Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.
> > >
> > > As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
> > > and have the drivers in each supported language generated.
> > >
> > > As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
> > > messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
> > > How does the information provided by users get in  requests and out of responses?
> > > So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
> > > And can you imagine my surprise when I noticed Apache has something for this in its toolbox?
> > >
> > > Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
> > > goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
> > > would be interested in joining us and working on this.
> >
> > Sounds cool! I'm not familiar with DFDL, but I'd like to help with
> > some of my experiences with SCXML and our current Commons SCXML
> > implementations.
> >
> > >
> > > I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.
> > >
> > > Any opinions, suggestions, things I should consider?
> >
> > One issue with the SCXML subproject is that it has been refactored a
> > lot since v2, but it has never been released for years. So, people
> > seem to feel hard to try it.
> > Another is that Ate and I have used it mostly for a specific use
> > case--document publication workflow in CMS--with M1 [1]; it kind of
> > lacks of diversity. In that sense, new faces from diverse backgrounds
> > will be more than welcome and more beneficial to the community.
> >
> > Perhaps you can test some PoC or its scenarios in conceptual level
> > with M1 tag to see if everything is okay.
> >
> > Another thing is that we should consider releasing it often (again
> > like 0.x's). Perhaps just because we bumped the version to 2.0.0
> > thanks to the expected whole refactoring, we might just have been
> > hesitant to cut a release of v2.x.x while we're not ready yet to
> > fulfill all the requirements of SCXML specification.
> >
> > Regards,
> >
> > Woonsan
> >
> > [1] http://commons.apache.org/proper/commons-scxml/roadmap.html
> >
> > >
> > > Chris
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

sebb-2-2
On Fri, 1 Feb 2019 at 14:12, Woonsan Ko <[hidden email]> wrote:

>
> On Fri, Feb 1, 2019 at 5:02 AM Christofer Dutz
> <[hidden email]> wrote:
> >
> > Hi,
> >
> > I would opt for setting up Jenkins to auto deploy snapshots to the Apache repo. Done that for quite a lot of projects, so happy to help out.
>
> Please help and direct us! :-)
> I once tried it but got in stuck before:
> - https://issues.apache.org/jira/browse/SCXML-236

Just completed.

> - https://issues.apache.org/jira/browse/INFRA-10366
>
> >
> > Cutting a release would be required for us to use it in our drivers (or we can't Release them). I will definitely not use an "unofficial release" in an Apache project. So a formal one would be required. But I'm happy to help get it there. However I would need to know what's still missing.
>
> Me, too!
>
> @Ate, could you chime in here to give insights on the current status
> and what we can do together to be able to cut a release (soon)?
>
> Cheers,
>
> Woonsan
>
> >
> > Chris
> >
> >
> >
> > Outlook für Android<https://aka.ms/ghei36> herunterladen
> >
> > ________________________________
> > From: Woonsan Ko <[hidden email]>
> > Sent: Friday, February 1, 2019 9:09:53 AM
> > To: Commons Developers List
> > Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
> >
> > On Thu, Jan 31, 2019 at 11:21 AM Christofer Dutz
> > <[hidden email]> wrote:
> > >
> > > Hi all,
> > >
> > > So I just finished a first operational scxml based state machine, that connects to a remote host and exchanges messages described by dfdl by serializing xml templates which I define inside my CustomAction elements of my scxml document.
> > >
> > > And the coolest thing is, that the remote Siemens PLC answered correctly :-)
> > >
> > > Still needs a lot of work. Especially we would need at least working snapshots of commons-scxml (the ones on repo.apachr.org are hugely out of sync) ... You need help with that? Had to tweak some minor things to build locally, but should be easy to fix.
> >
> > If it helps, we (Ate and I) have deployed M1 tag to our maven repo and
> > used it for years already in our products:
> > - http://maven.onehippo.com/maven2/org/apache/commons/commons-scxml2/2.0-M1/
> >
> > If we can deploy it or a snapshot to an ASF repo, it will help the
> > community. Should we decide to cut a release or just deploy to a
> > snapshot repo?
> >
> > >
> > > Would be cool, if someone could review what I'm doing (haven't committed it yet as it would break the build due to outdated snapshots) ... Don't wanna walk into the wrong direction and if we work together, I bet this could be for the benefit of Plc4x and commons-scxml :-)
> >
> > Cool. Give us a link.
> > From my experiences, it seems better not to depend on too many
> > expressions or scripts. Keeping it to the most normal standard
> > elements, with some custom actions to be used still in a declarative
> > way, seems simpler and more maintainable to me.
> >
> > Regards,
> >
> > Woonsan
> >
> > >
> > > Chris
> > >
> > >
> > > Outlook für Android<https://aka.ms/ghei36> herunterladen
> > >
> > > ________________________________
> > > From: Woonsan Ko <[hidden email]>
> > > Sent: Tuesday, January 29, 2019 4:49:16 PM
> > > To: Commons Developers List
> > > Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
> > >
> > > Hi Chris,
> > >
> > > On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz
> > > <[hidden email]> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
> > > > Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.
> > > >
> > > > As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
> > > > and have the drivers in each supported language generated.
> > > >
> > > > As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
> > > > messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
> > > > How does the information provided by users get in  requests and out of responses?
> > > > So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
> > > > And can you imagine my surprise when I noticed Apache has something for this in its toolbox?
> > > >
> > > > Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
> > > > goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
> > > > would be interested in joining us and working on this.
> > >
> > > Sounds cool! I'm not familiar with DFDL, but I'd like to help with
> > > some of my experiences with SCXML and our current Commons SCXML
> > > implementations.
> > >
> > > >
> > > > I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.
> > > >
> > > > Any opinions, suggestions, things I should consider?
> > >
> > > One issue with the SCXML subproject is that it has been refactored a
> > > lot since v2, but it has never been released for years. So, people
> > > seem to feel hard to try it.
> > > Another is that Ate and I have used it mostly for a specific use
> > > case--document publication workflow in CMS--with M1 [1]; it kind of
> > > lacks of diversity. In that sense, new faces from diverse backgrounds
> > > will be more than welcome and more beneficial to the community.
> > >
> > > Perhaps you can test some PoC or its scenarios in conceptual level
> > > with M1 tag to see if everything is okay.
> > >
> > > Another thing is that we should consider releasing it often (again
> > > like 0.x's). Perhaps just because we bumped the version to 2.0.0
> > > thanks to the expected whole refactoring, we might just have been
> > > hesitant to cut a release of v2.x.x while we're not ready yet to
> > > fulfill all the requirements of SCXML specification.
> > >
> > > Regards,
> > >
> > > Woonsan
> > >
> > > [1] http://commons.apache.org/proper/commons-scxml/roadmap.html
> > >
> > > >
> > > > Chris
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?

Woonsan Ko-3
On Fri, Feb 1, 2019 at 9:59 AM sebb <[hidden email]> wrote:

>
> On Fri, 1 Feb 2019 at 14:12, Woonsan Ko <[hidden email]> wrote:
> >
> > On Fri, Feb 1, 2019 at 5:02 AM Christofer Dutz
> > <[hidden email]> wrote:
> > >
> > > Hi,
> > >
> > > I would opt for setting up Jenkins to auto deploy snapshots to the Apache repo. Done that for quite a lot of projects, so happy to help out.
> >
> > Please help and direct us! :-)
> > I once tried it but got in stuck before:
> > - https://issues.apache.org/jira/browse/SCXML-236
>
> Just completed.

Thank you so much!
Now javadocs were fixed and it was deployed onto snapshot repo:
- https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-scxml2/2.0-SNAPSHOT/

Cheers,

Woonsan

>
> > - https://issues.apache.org/jira/browse/INFRA-10366
> >
> > >
> > > Cutting a release would be required for us to use it in our drivers (or we can't Release them). I will definitely not use an "unofficial release" in an Apache project. So a formal one would be required. But I'm happy to help get it there. However I would need to know what's still missing.
> >
> > Me, too!
> >
> > @Ate, could you chime in here to give insights on the current status
> > and what we can do together to be able to cut a release (soon)?
> >
> > Cheers,
> >
> > Woonsan
> >
> > >
> > > Chris
> > >
> > >
> > >
> > > Outlook für Android<https://aka.ms/ghei36> herunterladen
> > >
> > > ________________________________
> > > From: Woonsan Ko <[hidden email]>
> > > Sent: Friday, February 1, 2019 9:09:53 AM
> > > To: Commons Developers List
> > > Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
> > >
> > > On Thu, Jan 31, 2019 at 11:21 AM Christofer Dutz
> > > <[hidden email]> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > So I just finished a first operational scxml based state machine, that connects to a remote host and exchanges messages described by dfdl by serializing xml templates which I define inside my CustomAction elements of my scxml document.
> > > >
> > > > And the coolest thing is, that the remote Siemens PLC answered correctly :-)
> > > >
> > > > Still needs a lot of work. Especially we would need at least working snapshots of commons-scxml (the ones on repo.apachr.org are hugely out of sync) ... You need help with that? Had to tweak some minor things to build locally, but should be easy to fix.
> > >
> > > If it helps, we (Ate and I) have deployed M1 tag to our maven repo and
> > > used it for years already in our products:
> > > - http://maven.onehippo.com/maven2/org/apache/commons/commons-scxml2/2.0-M1/
> > >
> > > If we can deploy it or a snapshot to an ASF repo, it will help the
> > > community. Should we decide to cut a release or just deploy to a
> > > snapshot repo?
> > >
> > > >
> > > > Would be cool, if someone could review what I'm doing (haven't committed it yet as it would break the build due to outdated snapshots) ... Don't wanna walk into the wrong direction and if we work together, I bet this could be for the benefit of Plc4x and commons-scxml :-)
> > >
> > > Cool. Give us a link.
> > > From my experiences, it seems better not to depend on too many
> > > expressions or scripts. Keeping it to the most normal standard
> > > elements, with some custom actions to be used still in a declarative
> > > way, seems simpler and more maintainable to me.
> > >
> > > Regards,
> > >
> > > Woonsan
> > >
> > > >
> > > > Chris
> > > >
> > > >
> > > > Outlook für Android<https://aka.ms/ghei36> herunterladen
> > > >
> > > > ________________________________
> > > > From: Woonsan Ko <[hidden email]>
> > > > Sent: Tuesday, January 29, 2019 4:49:16 PM
> > > > To: Commons Developers List
> > > > Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify (industrial) protocols?
> > > >
> > > > Hi Chris,
> > > >
> > > > On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz
> > > > <[hidden email]> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I am a member of the Apache PLC4X podling. There we are implementing drivers for communicating with industrial hardware.
> > > > > Now we had started with manually implemented Java drivers, but it has always been our goal to ship drivers in multiple languages.
> > > > >
> > > > > As we are currently starting work on the C++ versions, it was time to work on some way to universally define these protocols
> > > > > and have the drivers in each supported language generated.
> > > > >
> > > > > As a first step I wrote DFDL schemas and tests using Apache Daffodil and this worked perfectly for defining the format of the
> > > > > messages being exchanged. Now I still had to model the protocol itself: Which message with what content is sent at which time?
> > > > > How does the information provided by users get in  requests and out of responses?
> > > > > So I was looking for some way to specify a State machine in XML … I stumbled over SCXML
> > > > > And can you imagine my surprise when I noticed Apache has something for this in its toolbox?
> > > > >
> > > > > Right now I’m working on writing such a SCXML schema mixing together SCXML + DFDL + Custom extensions to achieve the
> > > > > goal of fully specifying these protocols. So far it’s looking good, but I would like to ask, if someone here (ideally with SCXML experience)
> > > > > would be interested in joining us and working on this.
> > > >
> > > > Sounds cool! I'm not familiar with DFDL, but I'd like to help with
> > > > some of my experiences with SCXML and our current Commons SCXML
> > > > implementations.
> > > >
> > > > >
> > > > > I know that the activity on the SCXML project seems to have been … well minimal. But still I think it’s a good option.
> > > > >
> > > > > Any opinions, suggestions, things I should consider?
> > > >
> > > > One issue with the SCXML subproject is that it has been refactored a
> > > > lot since v2, but it has never been released for years. So, people
> > > > seem to feel hard to try it.
> > > > Another is that Ate and I have used it mostly for a specific use
> > > > case--document publication workflow in CMS--with M1 [1]; it kind of
> > > > lacks of diversity. In that sense, new faces from diverse backgrounds
> > > > will be more than welcome and more beneficial to the community.
> > > >
> > > > Perhaps you can test some PoC or its scenarios in conceptual level
> > > > with M1 tag to see if everything is okay.
> > > >
> > > > Another thing is that we should consider releasing it often (again
> > > > like 0.x's). Perhaps just because we bumped the version to 2.0.0
> > > > thanks to the expected whole refactoring, we might just have been
> > > > hesitant to cut a release of v2.x.x while we're not ready yet to
> > > > fulfill all the requirements of SCXML specification.
> > > >
> > > > Regards,
> > > >
> > > > Woonsan
> > > >
> > > > [1] http://commons.apache.org/proper/commons-scxml/roadmap.html
> > > >
> > > > >
> > > > > Chris
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]