You are right,  The example defines 
Class WSCI.CRE Extends (%RegisteredObject, %Net.WebSocket.ICredentials)
but doesn't use it,
According to the class definition of %Net.WebSocket.Client you pass it as a parameter
in the %New() method.

 so you code (extending my example may look like this:

 	set cre=##class(WSCI.CRE).%New()
#; feed whatever your credentials need 	
#; init connection 	
 	set ws=##class(%Net.WebSocket.Client).%New(url,cre,evl)

It might be worth checking what class %Net.WebSocket.Client does with your credentials

The article https://community.intersystems.com/post/websocket-client-iris-internal
has a link to OEX https://openexchange.intersystems.com/package/IRIS-internal-WebSocket-Client
which points to code on Github that includes a Client and an Echo Server for testing

the code runs on any IRIS. Docker is just a helping platform

Dmitry, you are just great.
And you impressed me over and over again.
Thank you for sharing your knowledge and your passion 

Point 2. of the previous reply is definitely WRONG!

Point 4. takes that back in some way but leaves it ambiguous.

Using extended Global References (also in Class Storage Definitions)
allows access to any mounted DB if you have access rights.

A personal example:

USER>for i=1:1:5 set ^|"^^C:\InterSystems\IRIS242\mgr\nonspace"|rcc(i)=i
 
USER>zwrite ^|"^^C:\InterSystems\IRIS242\mgr\nonspace"|rcc
^|"^^C:\InterSystems\IRIS242\mgr\nonspace"|rcc(1)=1
^|"^^C:\InterSystems\IRIS242\mgr\nonspace"|rcc(2)=2
^|"^^C:\InterSystems\IRIS242\mgr\nonspace"|rcc(3)=3
^|"^^C:\InterSystems\IRIS242\mgr\nonspace"|rcc(4)=4
^|"^^C:\InterSystems\IRIS242\mgr\nonspace"|rcc(5)=5
USER>

I learned this traditional technique  47 years ago. 
And it still works fine.
 

straight ObjectScript 

USER>if $d(^|"%SYS"|CONFIG("Namespaces"," ")) ;; position $ZR in CONFIG
 
USER>for  set ns=$o(@$ZR) quit:ns=""  zwrite ns  ; list it
ns="%SYS"
ns="SAMPLES"
ns="USER"
 
USER>

BINGO !

What about "InterSystems ObjectScript" ?
>>> short ISOS ??  😉

Fully agree with your suggestion of an Abstract Class.
It's in fact the modern equivalent of the old .INC approach

much more simple with 2 identic .INT routines a1 and a2​​

ROUTINE a1 [Type=INC]  
load ;
  read !,"loops=",loop,! 
  do t1 hang 0.5 do t2 quit
next 
  set t1=$zh quit 
t1 
  set t0=$zh
  for i=1:1:loop do next
  write t1-t0,!
  quit 
t2 
  set t0=$zh
  for i=1:1:loop do next^a2
  write t1-t0,!
  quit

SAMPLES>d ^a1
loops=1000000
.081626
.136785
SAMPLES>

I just mean you can't do less:
the difference is even worse 40.3%

My approach was rather simple.

• in runtime any class has its .INT wich has its .OBJ
• the OBJ is in the partition.
  • if I stay inside the .OBJ  it's fine
  • if I have to load another .OBJ and then reload the original .OBJ it consumes processor cycles
  • both .OBJ can be assumed to be cached, so it's a pure memory exercise
• the difference of both variants is sub microscopic
  • so looping for 100 M is kind of zoom-in to get something visible
  • The 100 M are common to both scenarios and
  • the Global has only (800 Mb) >>> 8 bytes / record counted by 
• I decided for SQL Shell for its nice runtime display.

SUMMARY: There is a difference.
But I wouldn't bend a little finger to attack it. (not even on PDP-11)
This is nothing where performance comes from.  

OK - in UDL

IRIS for Windows (x86-64) 2024.3 (Build 217U) Thu Nov 14 2024 17:59:58 EST

ROUTINE anna [Type=INC] 
anna(name) 
 quit ""

A.HUGE.cls

Include anna 
Class A.HUGE Extends (%Persistent, %Populate)
{ 
 Property calc As %Integer [ Calculated, SqlComputeCode = { set {*}={%%ID}},    SqlComputed ]; 

ClassMethod fill(size) As %String [ SqlProc ]
{
 for i=1:1:size set ^A.HUGED(i)=""
 set ^A.HUGED=i
 quit $ZR_"="_@$ZR
} 

ClassMethod test1(val) As %String [ SqlProc ]
{
 quit ##class(A.PERSON).Anna(val)
} 
ClassMethod test2(val) As %String [ SqlProc ]
{
 quit $$anna(val)
} 
Storage Default
{
 <Data name="HUGEDefaultData">
 <Value name="1">
 <Value>%%CLASSNAME</Value>
 </Value>
 </Data>
 <DataLocation>^A.HUGED</DataLocation>
 <DefaultData>HUGEDefaultData</DefaultData>
 <IdLocation>^A.HUGED</IdLocation>
 <IndexLocation>^A.HUGEI</IndexLocation>
 <StreamLocation>^A.HUGES</StreamLocation>
 <Type>%Storage.Persistent</Type>
} 
}

A.PERSON.cls

Include anna 
Class A.PERSON Extends %Persistent
{ 
 Property calc As %Integer [ Calculated, SqlComputeCode = { set {*}={%%ID}},  SqlComputed ];

ClassMethod fill(size) As %String [ SqlProc ]
{
 for i=1:1:size set ^A.PERSOND(i)=""
 set ^A.PERSOND=i
 quit $ZR_"="_@$ZR
} 

ClassMethod test1(val) As %String [ SqlProc ]
{
 quit ##class(A.PERSON).Anna(val)
} 

ClassMethod Anna(name As %String) As %String
{
 quit $$anna(name)
} 

Storage Default
{
 <Data name="PERSONDefaultData">
 <Value name="1">
 <Value>%%CLASSNAME</Value>
 </Value>
 </Data>
 <DataLocation>^A.PERSOND</DataLocation>
 <DefaultData>PERSONDefaultData</DefaultData>
 <IdLocation>^A.PERSOND</IdLocation>
 <IndexLocation>^A.PERSONI</IndexLocation>
 <StreamLocation>^A.PERSONS</StreamLocation>
 <Type>%Storage.Persistent</Type>
} }

The generated .INT proves it

Exactly.!
..#PARAMETER inserts a STRING
But >>>   $NAME() looks for a variable  also by indirection
 

USER>w $name("^rcc(1)")
 
W $NAME("^rcc(1)")
^
<SYNTAX>

USER>w $name(^rcc(1))
^rcc(1)
USER>s x="^rcc(1)"
USER>w $name(x)
x
USER>w $name(@x)
^rcc(1)
USER>

OOOOOPS 😮

confirm. It works and is independent of IRIS version 

That's a typical case,
where I write my personal ZZanyname  function  into %ZLANGF00.mac
to hide the details

which version ?

I tried and failed.
CLASS DOES NOT EXIST>%FromOref+8^%Library.DynamicObject.1 *%Library.EntityProjectionUtil
SAMPLES>w $zv
IRIS for Windows (x86-64) 2024.3 (Build 217U) Thu Nov 14 2024 17:59:58 EST