Failed to discover operations from the Uri due to error [Failed to load Service Metadata due to error [Metadata contains a reference that cannot be resolved: 'http://172.27.5.200:8095/AdvancedCalci?WSDL'.]]. Did you forget to put '?WSDL' or 'mex' at the e

Topics: Usage Scenarios, Technical Questions
Feb 12, 2009 at 12:27 PM
Hi ,
I am new to MSE and trying to use it for service virtualization.
I am facing some issues.
  1. I have successfully registered the service "http://172.27.5.200:9310/CalculatorWCF/AdvancedCalculator?WSDL" in the MSE and am able to create Endpoints which is mapped to a newly created runtimeserver. This is also synchronized with UDDI.
    But when I am trying to Discover the endpoint in the MSE Universal Tester as "http://172.27.5.200:8095/AdvancedCal?WSDL" (which is the uri specified for the endpoint)  I am getting the below mentioned error.
    "Failed to discover operations from the Uri due to error [Failed to load Service Metadata due to error [Metadata contains a reference that cannot be resolved: 'http://172.27.5.200:8095/AdvancedCalci?WSDL'.]]. Did you forget to put '?WSDL' or 'mex' at the end of the URL? If it is a secure Url, then go to security tab and try providing UserId and Password. Please see Windows Event Log for more details"
  2. Some WCF services are getting imported into the MSE by the wizard, but for some WCF services it is failing.

Could anyone help me, as I unable to move any further.
Bhaskar

Feb 12, 2009 at 5:28 PM
Did you add the endpoint to the Runtime Server (folder in managment console)?

!  Note that you have to click Add to add the endpoint to the list and then click the Apply button to save the new Runtime Server state.
!! Also note that if you dont have a notification url specified in the Runtime Server you have to manually restart the Host (its an NT service) everytime the configuration changes.

These were my first mistakes ;-)
Developer
Feb 13, 2009 at 1:39 AM

And to add one more thing to check...  from your post it looks like the url you are putting into the service tester isn't the same as what you defined. 

http://172.27.5.200:8095/AdvancedCal?WSDL

http://172.27.5.200:8095/AdvancedCalci?WSDL

note the "ci" in the second url.

if this still doesn't work and you've restarted the runtime service as obiwanjacobi stated, check out the MSE Runtime Server event log for more information/errors on whether it was able to stand up the endpoint in question.

Feb 13, 2009 at 4:46 AM
I have added the endpoint to the runtime server

Also, as botto suggests I have used the second url.

I just found something logged in the event viewer under MSE Runtime Server

No Endpoints assigned to MSE Runtime [hsg-srv024] in Catalog net.pipe://localhost/ServiceCatalog/Pipe - No Endpoints will be configured - Warning

 

Notification Uri for MSE Runtime [hsg-srv024] is undefined.This MSE Runtime won't be able to receive catalog notifications

Does this have anything to do with the endpoint hosted on the runtime server

Thanks,
Bhaskar

Feb 13, 2009 at 7:40 AM
Edited Feb 13, 2009 at 9:20 AM
I have the exact same problem. I also have these two event entries in the MSE Runtime event log.

I have reconfigured the endpoint again from scratch, restarted both catalog and runtime NT services even took a peek into the database tables -and the data was there- but nothing worked. The Catalog Event log contains only informational entries. So the catalog service seems to be working okay.

Oh, btw: I run on a VPC with Win2008.
Feb 13, 2009 at 11:36 AM
Edited Feb 13, 2009 at 11:38 AM
I got it working now (although it took me 4 hours!).

I had a different name for "Name" and "Host Name" for the Runtime Server. When I entered the computer name in both the "Name" and "Host Name" fields it worked and the tester could discover the methods of my endpoint.

Sounds like a bug to me. There is probably not a consistent use of "Host Name" (sometimes "Name" is used) inside the code of the runtime server.
Developer
Feb 13, 2009 at 2:19 PM
By default, the runtime server Name must match the computer name it is running on.  The HostName must always be addressable to that machine. 

The distinction is so that Name can be something more friendly than a computer name.  The way to support a different Name is to update the app.config file for the runtime server and change the Name configuration value (which is nil by default) to whatever value you specify in the Name field in the management tool.  The Name field is what the runtime uses to ask the catalog for its configuration information.  If those don't match then it reports that the runtime hasn't been configured and therefore doesn't know what service endpoints or notification endpoint to stand up.
Feb 14, 2009 at 5:13 AM
Edited Feb 14, 2009 at 5:21 AM
"the runtime server Name must match the computer name it is running on" and "The distinction is so that Name can be something more friendly than a computer name" seem to contradict eachother.

Is there a need to identify the runtime server any different than by computer name? Can you run multiple runtime server instances on one computer?

If not, the runtime server should be identified by the computer name its installed on and the 'Host Name' property should reflect that. The 'Name' property should be a human thing of how that runtime server configuration shows up in the management console.

So the runtime server contacts the catalog server while grabing the local machine name and passing it to the catalog service. The catalog can perform a query searching for 'Host Name' and returns the runtime server its configuration data. At runtime Name would not be used (other than perhaps in traces and log entries).

If it must keep working the way it works now, I feel you should not show the Name field in the management console. Although the 'Host Name' follows the entered 'Name' field, the consequences of changing that are not intuitive to the user.
Developer
Feb 16, 2009 at 4:38 PM
In the "default" behavior, the Name and HostName field can appear largely redundant.  However, in a production environment with Runtime Servers being load balanced, the distinction becomes more relevant.  The HostName in that case would be the name used by the load balancer to balance traffic (i.e. ww.contoso.com) rather than the unique machine name.  This is important because we want WCF to use the LB name in the url when we create the ServiceHost so references like the Soap Address reffer to the proper location (i.e. http://www.contoso.com/myService vs http://mymachine/myService).

Under this LB scenario, the Name field by default would still need to be the machine name, but could be anything as long as the runtime's app.config is updated accordingly.

Hope that helps clarify a bit more.
Feb 16, 2009 at 6:50 PM
Edited Feb 16, 2009 at 6:53 PM
Right. Load balancing. Good point ;-)

So the "Host" in "Host Name" is not the machine the runtime server is installed on but the name used as a base address for the WCF ServiceHost instances that host the dynamic endpoints!?

In that case you could rename the "Name" field to something like "Machine Name" or "Computer Name".
Rename "Host Name" to something that indicates more clearly what its used for (Endpoint Host Name).
And add an extra field called "Name" to let the operator specify a name of how this runtime server configuration is displayed in the management console.
You can remove the config option, I think...
And perhaps clearify this in the docs ;-)

Now the runtime server could still come in the catalog service using the computer name and retrieve its config data...

EDIT: or perhaps use field names like 'display name' (console), logical name (LB/host name) and 'physical name' (computer name)...?