Sometimes I hear the question “Why not decouple the service from the caller by using generic interfaces?”<\/p>\n
To better understand this question let’s have a look at the following pseudo code example: The Web Service BookingService has two methods, which can be called by the clients and is described in an BookingService.wsdl file. Why not using a generic interface like one of the following:<\/p>\n Generic parameter approach: This approach uses only generic parameters but no generic service operations.<\/p>\n Generic service approach: This approcach uses the common command pattern. It means the client sends a command id toghether with the required parameters to the service. At first glance this approach looks promising. But at what price? <\/p>\n A common misunderstanding is that the Web Service Signature described in the WSDL file forms the service contract. This is only one option. What really happens when using generic interfaces is that the contract is shifted from a standarized to a custom layer. I think the drawbacks of generic interfaces outweight the benefits. Sometimes I hear the question “Why not decouple the service from the caller by using generic interfaces?” To better understand this question let’s have a look at the following pseudo code example: BookingService { Flight[] getAvailableFlights(date flightDate, string destination); bool bookFlight(int flightId); } The Web Service BookingService has two methods, which can be called by … Continue reading Generic Web Service Interfaces – The Right Choice?<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,1],"tags":[],"class_list":["post-42","post","type-post","status-publish","format-standard","hentry","category-soa","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/42","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=42"}],"version-history":[{"count":2,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/42\/revisions"}],"predecessor-version":[{"id":339,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/42\/revisions\/339"}],"wp:attachment":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=42"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=42"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=42"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n
\nBookingService
\n{
\n Flight[] getAvailableFlights(date flightDate, string destination);
\n bool bookFlight(int flightId);
\n}
\n<\/font><\/p>\n
\nIf we would like to add a new method for instance cancelFlight(int flightId) we have to change the caller of the service. In most cases this means rebuilding the client side proxy.<\/p>\n
\n
\nBookingService
\n{
\n Map getAvailableFlights(Map params);
\n Map bookFlight(Map params);
\n}
\n<\/font><\/p>\n
\n
\nGenericService
\n{
\n Map execute(int commandId,Map params);
\n}
\n<\/font><\/p>\n
\nDependent of the command id the service dispatches the call to the service implementation.
\nIn order to add the service method cancelFlight we simply have to add a new command. The contract remains unchanged and the proxy hasn’t to be rebuild.
\nAnd even better the parameters can be processed in a generic way. That’s cool, isn’t it?<\/p>\n
\nMore precisely said the name of the service operation (or command id) in conjunction with the required in and out parameters form the contract.
\nIt doesn’t matter where this information is stored.<\/p>\n
\nThat means the contract is not described in the BookingService.wsdl file anymore. Now the service and the caller need a proprietary way to describe and exchange the contract.
\nMoreover the type safety is lost because only generic types are used.
\nThe command dispatching must be implemented. This is usually handled by the Web Service infrastructure for instance by using the SoapAction in the HTTP-Header.
\nGeneric parameter processing is not a reason to use generic interfaces. If necessary reflection can be used to process typed parameters in a generic way, but without loosing type safety.<\/p>\n
\nWhat do you think?<\/p>\n","protected":false},"excerpt":{"rendered":"