avilt,
As you already stated, those standards use DCOM to transport data and this can also be confirmed in the following link:
"Similar to the OPC Data Access specification, OPC Historical Data Access also uses Microsoft's DCOM to transport data"
Ref: https://en.wikipedia.org/wiki/OPC_Historical_Data_Access
Also I explained that DCOM uses MS-RPC to transfer data between hosts, so at the end what we care about is to allow MS-RPC traffic across the SRX. Here I attach a small explanation about MS-RPC
"MS-RPC is used by windows devices to communicate processes running on different devices; these remote processes are identified by UUIDs.
The device acting as the client will first establish a connection via port 135 and will ask for the dynamic port on which a specific service (UUID) is listening on the remote end. The device acting as the server will provide this information and the client will open a new session on that dynamic port (a high random port). Ideally we dont configure security-policies that permit traffic on all ports so when you reference the ms-rpc application on a security-policy it only permits port 135 and the SRX listens to the communications between the client the server in order to determine what is the high random port that will be used next, and the SRX allows communications from the client on that port only, blocking traffic on any other non-negotiated port. Thats pretty much the funtionality of the MS-RPC ALG. However is very common that from specific zones we dont need that much of security and sometimes we can have a security-policy allowing all the traffic from a specific zone to another zone."
Ref: https://forums.juniper.net/t5/SRX-Services-Gateway/RT-ALG-WRN-CFG-NEED/m-p/462471
In summary, the MS-RPC ALG will be listening to comunications on port 135 (known as EPM) and will be in charge of dynamically allow only the ports that were negotiated between the client and the server devices.