Re: Batch reads with JPA like annotation magic?

[Niclas Hedhman]

Polygene is highly opinionated, for better and worse. Minimally, Polygene
requires to start a runtime, and that everything needed is declared
explicitly upfront at boot time. The minimal start code is something like;


public static void main( String[] args )
throws Exception
{
app = new SingletonAssembler( module -> {
module.transients( Boiler.class, Ahu.class, Fan.class )
  .withMixins( Plc4xBackingPropertyMixin.class );

module.services( Plc4xPollService.class )
  .withMixins( Plc4xModbusDriver.class );
:
:
} );
}


If one wants to implement additional behavior in the Boiler class, then you
create Mixin classes. Let's say we want to capture the temperature once an
hour.

@Mixins(HistoryMixin.class)
interface Boiler
{
@Plc4x( url="s7://..", period=6 )
Property temperature();

List temperatureHistory();
}

public abstract class HistoryMixin
implements Boiler, Scheduled
{
int maxHours = 24;

LinkedBlockingDeque history = new LinkedBlockingDeque<>();

@Override
public void tick()
{
Double value = temperature().get();
history.addLast(value);
while( history.size() > maxHours )
{
history.removeFirst();
}
}

@Override
public List temperatureHistory()
{
return new ArrayList<>( history );
}
}


Above, let's say that "Scheduled" is a service to allow something to get a
tick() upon some period/interval. What I want to draw attention to is that
the HistoryMixin is implementing only the method(s) it need to, and that
the Boiler interface can declare such permanent functionality as an
annotation, instead of as a start-up declaration in the assembly. The fact
that the Mixin is abstract is handled by the runtime and it will compose
all these individual (so called) fragments into a single object (we call it
a Composite) when you instantiate it from the builder.

It is a whole new different way of writing software. Some people love it,
and others have a hard time understanding how it can possibly work. Just
scratching the surface, and please read
https://hedhman.wordpress.com/2017/05/10/introducing-apache-polygene/ for a
larger introduction to the subject.


If you don't want to write the entire project in Polygene "style", you need
to either use the Spring library bridge (possibly need upgrade that one a
bit), where each Service in Polygene will show up as a Spring bean, or
leverage various points of external hooks for Polygene, such
importedServices.


Don't want to bore you too much.


My actual main point was that your suggestion/idea can quickly become quite
a large undertaking and detract from the primary focus that (I think) PLC4X
should have. And bringing up Polygene was more to show that what you
suggest can be done very easily already in Polygene, and all that work
wouldn't be needed.


Cheers
Niclas


On Tue, Mar 6, 2018 at 4:35 AM, Christofer Dutz 
wrote:

> Hi Niclas,
>
> after recovering from that nasty Flu, that is plaguing Germany at the
> moment, I am working on catching up on what I missed.
> I tried to follow, but some things I felt to worn out to work my head
> around.
>
> Could you elaborate a little on Ploygene? How would this allow extending
> our requests with additional magic? Does this work in a simple way: No need
> to configure plugins, code generation or learn some complex API? I would
> like to keep PLC4X as simple as possible, but as extendable as possible.
>
> So I'm always open for new ideas (
>
> Chris
>
>
>
> Am 20.02.18, 03:32 schrieb "hedh...@gmail.com im Auftrag von Niclas
> Hedhman" :
>
> Being the Overlord of Magic that can be done in Java, I have some
> comments
> to make on this idea.
>
> 1. In principle what you suggest can already be done quite easily in
> Apache
> Polygene, by creating a "generic mixin" that overrides the generic
> PropertyMixin. Polygene is probably way more powerful than anything you
> could dream up here. Although Polygene has a strong JSON serialization
> and
> persistence "story", both fully pluggable, it does not use the Glasgow
> spec, a.k.a JavaBeans, a.k.a "getter/setter naming convention", which
> has
> been plaguing the Java community for 2 decades now.
> If I created a Plc4xBackingPropertyMixin, which I think would only
> take a
> few hours, maybe a couple of days, depending on how advance we want
> it, you
> would end up with;
>
>
>
>
> *public interface Boiler{*
>
> *@Plc4x( url="s7://..", period=5000, priority=low )*
>
>
> *Property running();*
>
> *@Plc4x( url="s7://..", direction=out )*
>
>
> *Property onoff();*
>
> *@Plc4x( url="s7://..", period=500, priority=high )*
>
>
>
> *Property alarm();@Plc4x( url="s7://..",
> period=5000,
> priority=normal )*
>

Re: Batch reads with JPA like annotation magic?

[Christofer Dutz]

Hi Niclas,

after recovering from that nasty Flu, that is plaguing Germany at the moment, I 
am working on catching up on what I missed. 
I tried to follow, but some things I felt to worn out to work my head around. 

Could you elaborate a little on Ploygene? How would this allow extending our 
requests with additional magic? Does this work in a simple way: No need to 
configure plugins, code generation or learn some complex API? I would like to 
keep PLC4X as simple as possible, but as extendable as possible. 

So I'm always open for new ideas (

Chris



Am 20.02.18, 03:32 schrieb "hedh...@gmail.com im Auftrag von Niclas Hedhman" 
:

Being the Overlord of Magic that can be done in Java, I have some comments
to make on this idea.

1. In principle what you suggest can already be done quite easily in Apache
Polygene, by creating a "generic mixin" that overrides the generic
PropertyMixin. Polygene is probably way more powerful than anything you
could dream up here. Although Polygene has a strong JSON serialization and
persistence "story", both fully pluggable, it does not use the Glasgow
spec, a.k.a JavaBeans, a.k.a "getter/setter naming convention", which has
been plaguing the Java community for 2 decades now.
If I created a Plc4xBackingPropertyMixin, which I think would only take a
few hours, maybe a couple of days, depending on how advance we want it, you
would end up with;




*public interface Boiler{*

*@Plc4x( url="s7://..", period=5000, priority=low )*


*Property running();*

*@Plc4x( url="s7://..", direction=out )*


*Property onoff();*

*@Plc4x( url="s7://..", period=500, priority=high )*



*Property alarm();@Plc4x( url="s7://..", period=5000,
priority=normal )*

*Property temperature();*
*}*

and in the "assembly", we would need to override the default PropertyMixin,
by doing;

*module.transients( Boiler.class ).withMixins(
Plc4xBackingPropertyMixin.class );*

That said, Apache Polygene is quite overwhelming for new users, so although
the idea is very persuasive for myself, I am under no illusion that others
are as easily convinced. And it is quite likely that I will create this,
since you brought it up, and the effort is rather small.


2. I have been doing PLC Master apps in Java since 1997 (and other
languages since 1984), and experience tells me that the biggest challenge
for really large applications is how to handle "permanent" vs "temporary"
values. What do I mean? In really large systems, it is not feasible to scan
all variables at all times. The latency will not be acceptable. Instead, we
acknowledge that many values are only of interest when someone is looking
at them, be it a person or a datalogger. Not saying it is unsolvable, but
it adds a fair bit of complexity in a Java world with GC, and relying on
finalize() is not really a solution and the outside "javabeans-friendly"
frameworks are clueless about resource management.

GutFeeling(tm) says that this can and should probably be postponed until we
have more experience and made all compatibility-breaking changes that comes
along the way.



Cheers
Niclas


On Tue, Feb 20, 2018 at 5:32 AM, Christofer Dutz 
wrote:

> Hi Dale,
>
> The direction thing was inspired by the way the Beckhoff ADS protocol was
> designed.
>
> There they sometimes Send Data alongside read requests and sometimes have
> strange "return what's in there and then overwrite with this" type of
> requests.
> The Beckhoff support guy mentioned that they are used quite a lot.
>
> That was the main reasoning for me mentioning the direction thing. In
> general this could be set to a default of being bedirectional.
>
> Chris
>
>
> Am 19.02.18, 18:25 schrieb "Dale LaBossiere" :
>
> Doesn’t the user need access to the response code for each annotated
> item?
>
> I’m unclear on why a Direction is needed/desired.  Is it just for
> “documentation" of what is possible for an item at that address?  Maybe it
> would be checked when the annotated class is used in a Read vs Write
> request to verify the request makes sense for that item?  Or… ?
>
> Could you provide some small pseudo-code of how the app would use the
> API with such an annotated class.
>
> class MyAnnotatedClass { … };
> PlcConnection connection = PlcDriver(…);
>
> // make a read requests
> …?
>
> // access data in the responses
> …?
>
> — Dale
>
>
> > On Feb 

Re: Batch reads with JPA like annotation magic?

[Niclas Hedhman]

Being the Overlord of Magic that can be done in Java, I have some comments
to make on this idea.

1. In principle what you suggest can already be done quite easily in Apache
Polygene, by creating a "generic mixin" that overrides the generic
PropertyMixin. Polygene is probably way more powerful than anything you
could dream up here. Although Polygene has a strong JSON serialization and
persistence "story", both fully pluggable, it does not use the Glasgow
spec, a.k.a JavaBeans, a.k.a "getter/setter naming convention", which has
been plaguing the Java community for 2 decades now.
If I created a Plc4xBackingPropertyMixin, which I think would only take a
few hours, maybe a couple of days, depending on how advance we want it, you
would end up with;




*public interface Boiler{*

*@Plc4x( url="s7://..", period=5000, priority=low )*


*Property running();*

*@Plc4x( url="s7://..", direction=out )*


*Property onoff();*

*@Plc4x( url="s7://..", period=500, priority=high )*



*Property alarm();@Plc4x( url="s7://..", period=5000,
priority=normal )*

*Property temperature();*
*}*

and in the "assembly", we would need to override the default PropertyMixin,
by doing;

*module.transients( Boiler.class ).withMixins(
Plc4xBackingPropertyMixin.class );*

That said, Apache Polygene is quite overwhelming for new users, so although
the idea is very persuasive for myself, I am under no illusion that others
are as easily convinced. And it is quite likely that I will create this,
since you brought it up, and the effort is rather small.


2. I have been doing PLC Master apps in Java since 1997 (and other
languages since 1984), and experience tells me that the biggest challenge
for really large applications is how to handle "permanent" vs "temporary"
values. What do I mean? In really large systems, it is not feasible to scan
all variables at all times. The latency will not be acceptable. Instead, we
acknowledge that many values are only of interest when someone is looking
at them, be it a person or a datalogger. Not saying it is unsolvable, but
it adds a fair bit of complexity in a Java world with GC, and relying on
finalize() is not really a solution and the outside "javabeans-friendly"
frameworks are clueless about resource management.

GutFeeling(tm) says that this can and should probably be postponed until we
have more experience and made all compatibility-breaking changes that comes
along the way.



Cheers
Niclas


On Tue, Feb 20, 2018 at 5:32 AM, Christofer Dutz 
wrote:

> Hi Dale,
>
> The direction thing was inspired by the way the Beckhoff ADS protocol was
> designed.
>
> There they sometimes Send Data alongside read requests and sometimes have
> strange "return what's in there and then overwrite with this" type of
> requests.
> The Beckhoff support guy mentioned that they are used quite a lot.
>
> That was the main reasoning for me mentioning the direction thing. In
> general this could be set to a default of being bedirectional.
>
> Chris
>
>
> Am 19.02.18, 18:25 schrieb "Dale LaBossiere" :
>
> Doesn’t the user need access to the response code for each annotated
> item?
>
> I’m unclear on why a Direction is needed/desired.  Is it just for
> “documentation" of what is possible for an item at that address?  Maybe it
> would be checked when the annotated class is used in a Read vs Write
> request to verify the request makes sense for that item?  Or… ?
>
> Could you provide some small pseudo-code of how the app would use the
> API with such an annotated class.
>
> class MyAnnotatedClass { … };
> PlcConnection connection = PlcDriver(…);
>
> // make a read requests
> …?
>
> // access data in the responses
> …?
>
> — Dale
>
>
> > On Feb 19, 2018, at 6:16 AM, Christofer Dutz <
> christofer.d...@c-ware.de> wrote:
> >
> > Hi,
> >
> > in the past I have been thinking how we can make the batch reads as
> simple as possible.
> >
> > I would like to introduce an idea I had:
> >
> > What if we started supporting annotated POJO classes? (The following
> names are just ideas …)
> >
> > A POJO class could be annotated with some “@PlcEntity” annotation.
> > A property inside one of these classes could then be annotated with
> “@PlcProperty”
> > This PlcProperty could have the following attributes:
> >
> >  *   Direction (Read/Write/Read)
> >  *   Property (Name of a property that provides the address in the
> PLC)
> >  *   Address (Alternative to provide the address directly and give
> up on the flexibility to change the PLC-type / Protocol)
> >
> > Providing would definitely be the less preferred option, but I guess
> we would have to provide a way that is extremely simple for new developers
> to get started. I wouldn’t want to overwhelm them with too much magic in
> the start.
> >
> > The connection could be 

Re: Batch reads with JPA like annotation magic?

[Christofer Dutz]

Hi Dale,

The direction thing was inspired by the way the Beckhoff ADS protocol was 
designed.

There they sometimes Send Data alongside read requests and sometimes have 
strange "return what's in there and then overwrite with this" type of requests.
The Beckhoff support guy mentioned that they are used quite a lot. 

That was the main reasoning for me mentioning the direction thing. In general 
this could be set to a default of being bedirectional.

Chris


Am 19.02.18, 18:25 schrieb "Dale LaBossiere" :

Doesn’t the user need access to the response code for each annotated item?

I’m unclear on why a Direction is needed/desired.  Is it just for 
“documentation" of what is possible for an item at that address?  Maybe it 
would be checked when the annotated class is used in a Read vs Write request to 
verify the request makes sense for that item?  Or… ?

Could you provide some small pseudo-code of how the app would use the API 
with such an annotated class.

class MyAnnotatedClass { … };
PlcConnection connection = PlcDriver(…);

// make a read requests
…?

// access data in the responses
…?

— Dale


> On Feb 19, 2018, at 6:16 AM, Christofer Dutz  
wrote:
> 
> Hi,
> 
> in the past I have been thinking how we can make the batch reads as 
simple as possible.
> 
> I would like to introduce an idea I had:
> 
> What if we started supporting annotated POJO classes? (The following 
names are just ideas …)
> 
> A POJO class could be annotated with some “@PlcEntity” annotation.
> A property inside one of these classes could then be annotated with 
“@PlcProperty”
> This PlcProperty could have the following attributes:
> 
>  *   Direction (Read/Write/Read)
>  *   Property (Name of a property that provides the address in the PLC)
>  *   Address (Alternative to provide the address directly and give up on 
the flexibility to change the PLC-type / Protocol)
> 
> Providing would definitely be the less preferred option, but I guess we 
would have to provide a way that is extremely simple for new developers to get 
started. I wouldn’t want to overwhelm them with too much magic in the start.
> 
> The connection could be extended to look a (configurable) property file. 
A property property () would then use this property map in the connection to 
get the real address string for the given property - hereby keeping the full 
portability.
> 
> Maybe it would be better to have two separate property annotations: one 
for property-based and one for hard-coded address strings.
> 
> The benefit would be that we then could simplify the integrations to 
frameworks like Edgent as we could create sources and sinks based on the POJO 
type.
> 
> What do you think?
> 
> Chris

Re: Batch reads with JPA like annotation magic?

[Dale LaBossiere]

Doesn’t the user need access to the response code for each annotated item?

I’m unclear on why a Direction is needed/desired.  Is it just for 
“documentation" of what is possible for an item at that address?  Maybe it 
would be checked when the annotated class is used in a Read vs Write request to 
verify the request makes sense for that item?  Or… ?

Could you provide some small pseudo-code of how the app would use the API with 
such an annotated class.

class MyAnnotatedClass { … };
PlcConnection connection = PlcDriver(…);

// make a read requests
…?

// access data in the responses
…?

— Dale


> On Feb 19, 2018, at 6:16 AM, Christofer Dutz  
> wrote:
> 
> Hi,
> 
> in the past I have been thinking how we can make the batch reads as simple as 
> possible.
> 
> I would like to introduce an idea I had:
> 
> What if we started supporting annotated POJO classes? (The following names 
> are just ideas …)
> 
> A POJO class could be annotated with some “@PlcEntity” annotation.
> A property inside one of these classes could then be annotated with 
> “@PlcProperty”
> This PlcProperty could have the following attributes:
> 
>  *   Direction (Read/Write/Read)
>  *   Property (Name of a property that provides the address in the PLC)
>  *   Address (Alternative to provide the address directly and give up on the 
> flexibility to change the PLC-type / Protocol)
> 
> Providing would definitely be the less preferred option, but I guess we would 
> have to provide a way that is extremely simple for new developers to get 
> started. I wouldn’t want to overwhelm them with too much magic in the start.
> 
> The connection could be extended to look a (configurable) property file. A 
> property property () would then use this property map in the connection to 
> get the real address string for the given property - hereby keeping the full 
> portability.
> 
> Maybe it would be better to have two separate property annotations: one for 
> property-based and one for hard-coded address strings.
> 
> The benefit would be that we then could simplify the integrations to 
> frameworks like Edgent as we could create sources and sinks based on the POJO 
> type.
> 
> What do you think?
> 
> Chris