Skip to main content

Remote activation: different results depending on ....

Author: ulrichmerkel@web.de (ulrich-merkel)

I open this discussion because there seem to be some issues
one has to know before building an architecture of coherent services
about uniface behaviour executing self-contained services in local and different remote environments.

So I think it would be nice for all members which wants to use remote activations to see how different "userver" settings will influence the result.

Starting from Mike Taylors great article "Remote Activation; what should be expected"
and my observations "Denial of Service: activate MYSERVICE.DO_IT() ..." it is worth to investigate,
how different invocation environments influence the result of some relatively simple implementations.

Please remember: changing invocation is done in the ASN file (outside of the uniface coding one can control).

- Let's start with the implementation from Mike and run it in the remote environment he described.
  The result is: “Set in init”

- if we turn off remote execution so all services run locally.
   The result is: “Text From CLIENT_FRM”

As Mike mentioned:
"After the newinstance of remote_2 the vales $status and $procerror are 0 and if I were to change my asn file to have my services locally I would get "Text From CLIENT_FRM" returned.... But if I did change the code so that everything was local I would get a negative $status and $procerror returned from the newinstance of REMOTE_2 and I would have to decide whether this was acceptable or not."

Success, Uli

Remote activation: different results depending on ....

Author: ulrichmerkel@web.de (ulrich-merkel)

I open this discussion because there seem to be some issues
one has to know before building an architecture of coherent services
about uniface behaviour executing self-contained services in local and different remote environments.

So I think it would be nice for all members which wants to use remote activations to see how different "userver" settings will influence the result.

Starting from Mike Taylors great article "Remote Activation; what should be expected"
and my observations "Denial of Service: activate MYSERVICE.DO_IT() ..." it is worth to investigate,
how different invocation environments influence the result of some relatively simple implementations.

Please remember: changing invocation is done in the ASN file (outside of the uniface coding one can control).

- Let's start with the implementation from Mike and run it in the remote environment he described.
  The result is: “Set in init”

- if we turn off remote execution so all services run locally.
   The result is: “Text From CLIENT_FRM”

As Mike mentioned:
"After the newinstance of remote_2 the vales $status and $procerror are 0 and if I were to change my asn file to have my services locally I would get "Text From CLIENT_FRM" returned.... But if I did change the code so that everything was local I would get a negative $status and $procerror returned from the newinstance of REMOTE_2 and I would have to decide whether this was acceptable or not."

Success, Uli

My architecture "coherent and loosely coupled" components with all info and processing concentrated in a single service with all getters and setters and ...

So my aim is how to implement a real SINGLETON accessable it by name ( we maintain these names as precompiler constants in our framework).

When Uniface opens new instances, will do no good, because they do not hold the information I am after (as shown in Mikes example).

Success, Uli

 


Author: ulrich-merkel (ulrichmerkel@web.de)

Remote activation: different results depending on ....

Author: ulrichmerkel@web.de (ulrich-merkel)

I open this discussion because there seem to be some issues
one has to know before building an architecture of coherent services
about uniface behaviour executing self-contained services in local and different remote environments.

So I think it would be nice for all members which wants to use remote activations to see how different "userver" settings will influence the result.

Starting from Mike Taylors great article "Remote Activation; what should be expected"
and my observations "Denial of Service: activate MYSERVICE.DO_IT() ..." it is worth to investigate,
how different invocation environments influence the result of some relatively simple implementations.

Please remember: changing invocation is done in the ASN file (outside of the uniface coding one can control).

- Let's start with the implementation from Mike and run it in the remote environment he described.
  The result is: “Set in init”

- if we turn off remote execution so all services run locally.
   The result is: “Text From CLIENT_FRM”

As Mike mentioned:
"After the newinstance of remote_2 the vales $status and $procerror are 0 and if I were to change my asn file to have my services locally I would get "Text From CLIENT_FRM" returned.... But if I did change the code so that everything was local I would get a negative $status and $procerror returned from the newinstance of REMOTE_2 and I would have to decide whether this was acceptable or not."

Success, Uli

This approach would require the use of exclusive uservers on the application server.

Thus there would be (at least) one process on the server for every connected user, generally sitting idle, but using resources.

What is the perceived benefit in this approach?

Where we are using specific services as memory stores (for login info and the like) we simply run them on the client instead of the server, and the 'issues' mentioned above do not occur.

We have found that the best automatic load balancing is actually done by using the activate/stateless option to ENSURE that no service remains resident in memory on the server.

What would the function you are trying to do be used for? (I'm thinking maybe pagination, so the 'hitlist' is preserved. )

Iain


Author: Iain Sharp (i.sharp@pcisystems.co.uk)

Remote activation: different results depending on ....

Author: ulrichmerkel@web.de (ulrich-merkel)

I open this discussion because there seem to be some issues
one has to know before building an architecture of coherent services
about uniface behaviour executing self-contained services in local and different remote environments.

So I think it would be nice for all members which wants to use remote activations to see how different "userver" settings will influence the result.

Starting from Mike Taylors great article "Remote Activation; what should be expected"
and my observations "Denial of Service: activate MYSERVICE.DO_IT() ..." it is worth to investigate,
how different invocation environments influence the result of some relatively simple implementations.

Please remember: changing invocation is done in the ASN file (outside of the uniface coding one can control).

- Let's start with the implementation from Mike and run it in the remote environment he described.
  The result is: “Set in init”

- if we turn off remote execution so all services run locally.
   The result is: “Text From CLIENT_FRM”

As Mike mentioned:
"After the newinstance of remote_2 the vales $status and $procerror are 0 and if I were to change my asn file to have my services locally I would get "Text From CLIENT_FRM" returned.... But if I did change the code so that everything was local I would get a negative $status and $procerror returned from the newinstance of REMOTE_2 and I would have to decide whether this was acceptable or not."

Success, Uli

Hi Iain,

in the good old days using the following lines was sufficient to have a singleton:

newinstance ("MY_COMPONENT","MY_COMPONENT_SINGLETON")
activate "MY_COMPONENT_SINGLETON". .....

Mike Taylors article implies that his is not the way to have real singletons
when using uservers (not even with exclusive uservers).

So the challenge is: how to implement a real singleton under remote (/ex) execution with uniface (8.4.03)

Very good if a man of your experience joins to find a way to make it work inide the constraints of "old uniface".

Success, Uli



Author: ulrich-merkel (ulrichmerkel@web.de)

Remote activation: different results depending on ....

Author: ulrichmerkel@web.de (ulrich-merkel)

I open this discussion because there seem to be some issues
one has to know before building an architecture of coherent services
about uniface behaviour executing self-contained services in local and different remote environments.

So I think it would be nice for all members which wants to use remote activations to see how different "userver" settings will influence the result.

Starting from Mike Taylors great article "Remote Activation; what should be expected"
and my observations "Denial of Service: activate MYSERVICE.DO_IT() ..." it is worth to investigate,
how different invocation environments influence the result of some relatively simple implementations.

Please remember: changing invocation is done in the ASN file (outside of the uniface coding one can control).

- Let's start with the implementation from Mike and run it in the remote environment he described.
  The result is: “Set in init”

- if we turn off remote execution so all services run locally.
   The result is: “Text From CLIENT_FRM”

As Mike mentioned:
"After the newinstance of remote_2 the vales $status and $procerror are 0 and if I were to change my asn file to have my services locally I would get "Text From CLIENT_FRM" returned.... But if I did change the code so that everything was local I would get a negative $status and $procerror returned from the newinstance of REMOTE_2 and I would have to decide whether this was acceptable or not."

Success, Uli

Hi

You can't make a real singleton with Uniface, because of distributed components. Uniface manages a pool of instances for each session (client/server). So there's no singleton possible, without some coding. I guess this can be possible, with dedicated UST, and one indirection (go through one service to activate the interesting one). No sure for the solution, but this's how I would start my ingvestigations. But, such a work isn't too much for that ?

Kind regards,
Richard


Author: richard.gill (richard.gill@agfa.com)

Remote activation: different results depending on ....

Author: ulrichmerkel@web.de (ulrich-merkel)

I open this discussion because there seem to be some issues
one has to know before building an architecture of coherent services
about uniface behaviour executing self-contained services in local and different remote environments.

So I think it would be nice for all members which wants to use remote activations to see how different "userver" settings will influence the result.

Starting from Mike Taylors great article "Remote Activation; what should be expected"
and my observations "Denial of Service: activate MYSERVICE.DO_IT() ..." it is worth to investigate,
how different invocation environments influence the result of some relatively simple implementations.

Please remember: changing invocation is done in the ASN file (outside of the uniface coding one can control).

- Let's start with the implementation from Mike and run it in the remote environment he described.
  The result is: “Set in init”

- if we turn off remote execution so all services run locally.
   The result is: “Text From CLIENT_FRM”

As Mike mentioned:
"After the newinstance of remote_2 the vales $status and $procerror are 0 and if I were to change my asn file to have my services locally I would get "Text From CLIENT_FRM" returned.... But if I did change the code so that everything was local I would get a negative $status and $procerror returned from the newinstance of REMOTE_2 and I would have to decide whether this was acceptable or not."

Success, Uli

Hi Richard,

what is a "session" in your terms, can you just explain a bit more?

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)
Terms & ConditionsAccessibility statement