Operation Name Uniqueness

Topics: Service Factory Modeling Edition Forum
Oct 23, 2009 at 6:44 PM

Can you please provide your guidance and your reasoning on whether Operation Names should be unique across Services?

For Example:

Service "Project" has an Operation called "Deactivate()"

Service "Customer" has an Operation called "Deactivate()"

Is this correct or should all Operation Names be unique across the entire Enterprise?

For Example:

Service "Project" has an Operation called "ProjectDeactivate()"

Service "Customer" has an Operation called "CustomerDeactivate()"

Developer
Oct 26, 2009 at 12:17 PM

You don;t need to have different operation names across services, just only within each service and according to the WSDL definition, you can even have the same name as long as you specify a different attribute value (name in Operation attr) like described in this paragraph of the WSDL definition.

"An operation element within a binding specifies binding information for the operation with the same name within the binding's portType. Since operation names are not required to be unique (for example, in the case of overloading of method names), the name attribute in the operation binding element might not be enough to uniquely identify an operation. In that case, the correct operation should be identified by providing the name attributes of the corresponding wsdl:input and wsdl:output elements"

Oct 26, 2009 at 2:59 PM

Thank You for the Reply!

The reason I asked this question has to do with the Guidance that is being presented on the "Managed Services Engine" Code Plex Discussion Board. Here is the link to the discussion which is pertinent to my question.

 Operations with the Same Name in Different Services    http://servicesengine.codeplex.com/Thread/View.aspx?ThreadId=30348

In particular the comments by williamo the "Coordinator"

Coordinator
Apr 9 at 11:59 AM<abbr></abbr>
<input id="ctl00_ctl00_MasterContent_Content_PostRepeater_ctl14_PostId" name="ctl00$ctl00$MasterContent$Content$PostRepeater$ctl14$PostId" type="hidden" />

What this issue exposes is the fact that many of the practices we have been using as an industry have possibly been inappropriate and masked by the limitations or behavior of “Web” services.  The tenets of service orientation include autonomous functions and explicit boundaries and in reality this applies at the operation layer, not the Web service.  An operation called “Add” is named with the assumption that it is grouped in a container that provides additional context related to its intent.  If you ever wanted to package this function with another “Add”, WSDL would not allow that, even though they are completely different capabilities.  This approach also proves problematic when discovering or monitoring multiple operations with the same name.  You are correct in perceiving this solution as a workaround and we are okay with that because we believe we are supporting an existing flawed approach that should eventually be phased out.  Long term, each operation should be named explicitly (AddCustomer, AddProduct, etc) so that they can be easily packaged, discovered, and monitored as discrete functions.  We welcome your input as we don’t consider any of this written in stone, just strong instincts based on years of experience. J

I do not think that Operation Names should be unique across all Services for the Enterprise. So is there a problem with how Service Virtualization was implemented in Managed Services Engine?

I noticed that Don Smith is a developer on the Managed Services Engine project and a Coordinator on the Web Service Software Factory project. Are you able to find out how he reconciles the different views of Operation Names between the two projects or just his comments on the issue in general?

I have many sevrices built using the WSSF-Modeling Edition and I am now trying to use MSE and this is one of the issues I need to resolve.

Thanks!