I'm currently learning about web services, and if I understood correctly as an example for an RPC, a stub is generated based on a WSDL and the stub converts methods, data etc. into a form that the remote process can use (the whole marshalling and demarshalling thing, I think I got the gist of it). I think a big part of why a stub is generated is also to make the whole thing function across different adress spaces and operating systems. Correct me if I'm wrong.

My main question: are there alternatives that don't generate stubs, and if so, how do they bridge the gap between the local system and remote system?

CodePudding user response：

You have two major ways to design communication - contract first or contract last.

In your example, you do contract first - you write WSDL and then code is generated out of it. The benefit for this approach is decoupling the development process - both sides (server and clients) can be developed based on the contract.

Contract last is when you define your apis in code and then framework generate WSDL from those methods. Arguably this is faster far smaller teams as they can change apis on the go before the first public release.

As for: alternatives that don't generate stubs, and if so, how do they bridge the gap between the local system and remote system - I would recommend to have a dedicated communication layer, which abstracts the actual on-wire communication.

For example, let's say a remote system has two api's - getNameById and getEmailById. Your business case requires both name and email, hence you would have a data access layer with an api - getNameAndEmailById. In that case you would stub this data access layer for testing purposes. But there is nothing inherently wrong with using stubs/mocks for the remote service.