I have deployed a smart contract to a public network like binance smart chain network that is viewable on a blockchain explorer like bscscan.
The deployed smart contract was developed with Openzeppelin upgrades plugin to be upgradable.
Once deployed, how can I interact with the smart contract to call public methods on it without building a frontend web3 application?
Typically, all public methods on the contract are exposed on bscscan under the
Contract tab as shown in the attached image, however, since the Openzeppelin upgrades plugin uses a proxy contract to manage upgrades, it's only the public methods on the proxy (manager) contract that are visible on bscscan.
Are there any dApps that facilitate communicating with an upgradable contract deployed in this way, or are there some other methods can can be used to facilitate interacting with an upgradable contract?
Assuming the implementation contract is verified on the blockchain explorer, you can use the Read as Proxy and Write as Proxy tabs.
They allow you to interact with the proxy contract using the ABI of the implementation contract the same way as you can interact with a regular (non-proxy) contract using the Read Contract and Write Contract tabs.
You call a public method, of the logic contract, on the proxy contract, which has none of that method. The proxy has then to redirect the call to its fallback function, which, in turn, delegates/forward the call to the registered, current logic contract, which runs the code of that method against the state data stored in the proxy contract. (The proxy contract effectively borrows the code of the given method from the registered, current logic contract.)
When you upgrade the upgradeable contract, the proxy manager simply deploy the new contract and overridingly register the contract as the current logic contract, while keeping the state data stored in the proxy.
Two concepts that work here:
the fallback function, which is invoked if a non-existing function is called, on a contract,
and call delegation, which calls a public function of another, logic, contract so that the function works on the state data kept in the proxy not in the logic contract.
Related
I have been googling for quite some time now but cannot find a definite answer.
I want to consume a wcf service, whose address will be provided at runtime.
The user will enter the address of the wcf service at runtime.
During compilation I have no idea of the service contract or the data contract or the endpoints of the wcf service.
Could someone please let me know how to achieve this requirement ?
This was the original idea behind UDDI. Before making a call, the client would query some central repository and obtain the address, contracts, and bindings of the service endpoint. It would then use this information to assemble and call the channel.
Some ESBs work on this principal - the call to UDDI can also be logged centrally, so an audit is kept of all service calls made within the enterprise.
Microsoft implemented it's own UDDI server which can be integration into SCOM for this purpose.
I have a win32 application that uses client side plugins and uses a Win32 Service via TCP/IP. I would like to also dynamically load assemblies on the WCF service based on the addition of new plugins. Currently I have to add the the ServiceContract and OperationContract to the Services class and IService interface and then re-compile. Is there a way to dynamically load the WCF assemblies and not have to generate the class and interface references? Can these be moved out of the WCF Win32 service into external classes?
I was wondering about this as well, but came to the conclusion that this was not a question of whether or not its possible, but should you do it? Even if you could generate the contract definitions dynamically, you still need to notify the client of the change, they in turn would need to regenerate the proxy in order to interact with the new service definition, and then provide an implementation dynamically. A better approach is to redesign your service so it implements a particular strategy (read Strategy pattern). The contract remains static, but the implementation changes based on client input. That way your service can dynamically load modules without your client being aware of it.
HTH.
Steve
Hi all i am new to WCF i wanted to know if i use channel factory and if i make any changes in service contract whether the changes will be updated automatically in the client system or not???If the changes are updated automatically how????
No, the channel factory is not updated automatically - you have to update your service reference (if you added it using Visual Studio's Add Service Reference) or you need to re-create the client side proxy from the WSDL/XSD or service URL.
UPDATE: of course, if you're sharing the service and data contracts in an assembly between both the service and the client, then of course you have the client up to date as soon as you have the new service contract DLL in place...
If you want to enable this sharing of service and data contracts, use the following setup:
in your Contracts assembly, have all the service contracts (interfaces) and data contracts (data types)
in your implementation of the service, reference that Contracts assembly and implement the service contract(s)
in your client-side proxy, also reference that shared Contracts assembly, and use ChannelFactory<T> to create a channel factory for the service contract interface T.
With this setup, whenever you make a change to the shared contract assembly, both service implementation and client side proxy will "get" those changes, e.g. they're always up to date and using the same service and data contracts
I am developing a solution with multiple WCF services which all communicate among themselves, even though they are of different types. The services connect to one another through the ChannelFactory generic interface, and every service is hosted inside a ServiceHost.
My question is if it would be correct to use a callback contract among the servers to communicate with one another and if so how would such a solution look.
Currently I don't like the implementation because every service needs to host a couple of endpoints with different interfaces some for other services and some for other clients.
When I tried to implement the callback contract inside a service class that was hosted inside a ServiceHost it failed.
First of all, whenever you post a question saying, "it failed", you need to tell us in what way it failed. If there was an exception, then you need to post the entire exception, including all InnerException instances, by posting the result of ex.ToString().
To your problem, I'd implement a service contract that represents the part of each service that needs to talk to the other services. There would also be a callback contract associated with this service contract.
That way, it's as though each service operates a miniature service intended only for service-to-service communications. They can then each do their own thing with the information that is passed between the services.
I have an existing WCF service.
Is it possible to add operation contract to the service interface and have the implementation in a workflow?
Or I absolutly need a seperate service interface for my workflow?
When you publish a WCF service you are publishing the interface and telling it what implementation to use. You can specify only one implementation, otherwise how would WCF know where to route which request. So in short you need to use a separate interface for your workflow services. That said, if you don't want to change your public facing API there is no reason you can't create a minimal implementation that just passes request on to your worklflow service.