This project is read-only.

Operations with the Same Name in Different Services

Topics: Usage Scenarios, Technical Questions
Jun 26, 2008 at 8:51 PM
Edited Jun 26, 2008 at 8:53 PM
I am evaluating MSE for my organization. The company implements SOA infrastructure, there are a number of existing ASMX webservices and WCF services within the company. So we are going to expose these services as individual endpoints within MSE. There are services implementing operations with same name, e.g. Client service has DEACTIVATE operation, as well as Project service has the same DEACTIVATE operation, they have diffenent contract and fulfil different functions.

In MSE, all operations need to have unique name. So what is the recommend approach for my problem?

We tried to prefix operations with their service names, and use an EndpointBehavior via MSE policy redirecting to different actions based on which endpoint they came in, and can't figure out how to make that work. Not sure, whether it is the right approach.

Thanks
Kan
Jun 26, 2008 at 10:02 PM
You should be able to change the name of the virtual operation. You can do it when you are importing the service. Please note that teh Grid column on one of those screens that has name and version like AddIntegersers:1.0.0.0 is editable. You can chnage the name of the virtual operation there. MSE will take care of the rest. You do not need to have an EndPoint behavior or Policy.
So let's say that you have a you imported Deactivate operation of Client service as DeactivateClient in MSE and Deactivate operation of Project service as DeactivateProject. Now when you call these operation through an MSE hosted Endpoint, MSE will take care of calling the correct implementation. You do not need a behavior or policy for that. Please let us know if it is clear or not.    
Jun 26, 2008 at 10:36 PM

Yes, this will be our Plan B.

I forgot to emphasize one thing here. There are a number of existing client applications (web and desktop) consuming these services. Changing the operation name means huge workload to modify all existing clients. And maintaining a unique operation name across dozens of services will be daunting task by itself.

In reality, we only want to virtualize at endpoint/service level, not necessary at operation level. While MSE provides the ability to virtualize operations, of course, they will have to have unique names.

 

Any suggestions? Thanks

Jul 7, 2008 at 6:44 PM
Here is my solution, seems resolve my problem at this time:

a: Prefix all operation names with their service name, to unique identify all operations within MSE. Client applications still use original operation name.
b. Use MSE provided versioning method to version operations, or append version number as part of service name, which is prefixed on the operation name.
c. For client applications, reference a custom built WCF extension (IClientMessageInspector) assembly, and use a ClientEsbId (GUID within message header) to identify the application, the GUID is stored in the configure file.
d. Apply another custom built WCF extension (IDispatchOperationSelector) as MSE policy on the server, to retrieve service name, and version number by the ClientEsbId. And then dispatch the message to appropriate operations within MSE.
Apr 2, 2009 at 3:20 PM
Hi there,

At my company we are exactly in the same situation,two operations with the same name in different web services. Something likeProposal.AddComent and Contract.AddComment.

We definitely don’t want to change the name of theoperations due the amount of clients that are already using them. We also thingthat only having operations with different names could limit our options in thefuture and make us create unnecessary logic.

So we would like to know if, in the near future, thissituation is going to be considered as an issue to be solved.

Thank you in advanced,

JCR<o:p></o:p>

Apr 2, 2009 at 10:30 PM
Why don't you try this. Import operation "AddComment" from Proposal.AddComent first as version 1.0 then import Contract.AddComment as version 2.0. Publish Addcomment 1.0 using endpoint #1 and AddComment 2.0 using enpoint #2. This way client side can continue to use existing operation name. Only thing client need to do is to point to the right endpoint. Hope this helps.
Apr 9, 2009 at 3:17 PM
Hi, thank you for the advice.

I believe this will work and, for the clients, it will be a transparent solution. 
Still I can´t help to think that this solution sounds like a workaround. Internally we will have two completely different operations differentiated in MSE only by their version number.

JCR

Apr 9, 2009 at 4:59 PM

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

Apr 9, 2009 at 5:17 PM

Iunderstand and respect your opinion. Thank you :) <o:p></o:p>

Apr 9, 2009 at 5:18 PM
I understand and respect your opinion. Thank you :) 

JCR