When I deploy a virtual service to a mediator, the portName of the mediator’s WSDL is generated by the mediator using the protocol details of the virtual service. This name also includes the target name itself. Hence, when i deploy a service to more than one mediator, the different WSDLs of the service from the different mediators, will have different PortNames.
Clients configured to consume one WSDL thus, cannot be used again for the other WSDL with a different portName, without code changes.
Any suggestions on avoiding client side code changes for this scenario ?
The Virtual Service WSDL in Mediator will have only ports defined for that Target.
Use the Virtual Service WSDL from CentraSite.
This WSDL will have ports defined for all Mediators to which it is deployed.
In case of WSDL of native service having WS-Policy or any schema imports, all this information will be available in Consumer WSDL which is available in Virtual Service’s Specification profile .
To get the Consumer WSDL please make the Design-Time policy “Consumer WSDL Generator” Productive.
I also have this question. The design time policy that you mentioned is a built in one ? I am using centrasite 8.0 and i dont see it under Policies->Design/Change Time.
I would be providing the mediator WSDL to consumers for interfacing with the service. I would want a WSDL to represent each of the standard dev evironments (dev-qa-prod).
Also, i am not seeing any difference between the CS WSDL of the vservices and the mediator WSDL.
Please suggest.
Do you have different CentraSite and Mediator for each environment?
If same CentraSite is shared in all environments then you may use WSDL from Mediator.
Currently yes. We have one CS each for dev, qa and prod, with corresponding mediators. However, we are planning on consolidating all the CS environments into a single one, and have the services deployed to the different mediators from the same CS env. At a high level, this is an issue for us because each mediator is generating its own port name as per the mediator WSDL. This prohibits consumers from using the same code for all three environments without changing their code/recreating the consumer using the new WSDL.
The target consumers of the WSDL for all environments are same? Does the below scenario suite your requirement?
For a Virtual Service is deployed to a Dev environment Mediator, the service consumers could be developers.
For a Virtual Service is deployed to a QA environment Mediator, the service consumers could be Testers.
For a Virtual Service is deployed to a Prod environment Mediator, the service consumers could be the end users for whom the service is developed.
In this scenario if the WSDL has the ports and endpoints of all the environments, users can access any of the environments which might not be expected.
With the CentraSite version you are using, how is the WSDL in CentraSite when same Virtual Service is deployed to multiple Mediators?
I mean what are the ports and endpoints available?
Not exactly. I mean, the consumers are basically applications that themselves get migrated to their dev/qa/prod environments. Hence consumers that are created using the first WSDL (dev) will be migrated to the QA, and so the QA code will also expect the same port name in the QA mediator WSDL that is given to it for consumption. We can of course externalize the WSDL URL, endpoint etc. in properties files, but the port name’s dependency cannot be avoided. I am following this documentation: [url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/centrasite/inm803/ig-deploy/Impl_Endpoints.htm[/url]
I have a service currently deployed to two targets. The service definition in the CS WSDL is like this:
In your earlier comment you have stated “We have one CS each for dev, qa and prod”.
So you have different CentraSite & Mediator for each environment.
In this case if you define the same target name in all CentraSites I guess there wont be any change in WSDL.
In the case where you have only one CentraSite and different Mediator instances for different environments, you will have ports of all Targets in the WSDL.
What is your expectation on the WSDL? you need WSDL for each environment or same WSDL which has all ports?
I am assuming the WSDL snippet you have provided is taken after the below steps
Deploy to devpep.
Undeploy from devpep.
Deploy to qapep.
My requirement- have a single instance of CS, and multiple targets that correspond to the different environments of the native service. thus, each mediator WSDL must have a single port definition, with the same port name. the endpoints in these ports however, point to the different environments of the native service.
steps i am following-
-create a service and attach a WSDL to it,having a single port definition with the dev URL [eg. jboss dev] of the native service. at this stage the service is deployed to a single environment.
-virtualize the above service and deploy it to the dev-pep.
-after the service is tested in dev, it is deployed to the qa native environment [eg. jboss qa].
-in CS, i update the service WSDL, by adding a new port definition to the original WSDL. so effectively, my service WSDL now has two port definitions.save the service.
-navigate to the processing steps of the virtual service created earlier. change the endpoint [under straight through routing] to point to the new qa endpoint. i do this by using the ‘search for endpoint’ utility and not typing the new endpoint.
-deploy the virtual service to qa-pep.
-so basically, my dev-pep mediator wsdl should route all requests to the native dev environment and my qa-pep mediator wsdl should route them to the qa native environment.
the issue i am facing with the above steps is that when i deploy to the dev-pep, the port name in the mediator wsdl is picked up from the service wsdl itself. however, when i deploy it to the qa-pep, the mediator wsdl is having a port name that is generated by the mediator itself. what i need is to understand if this port name pattern can be configured somewhere, so that i can have the same pattern in all my mediators, effectively getting the same port names when deployed to any of them.
the WSDL snippet i have provided is the CS wsdl of the virtual service after deploying it to the qa-pep.
the objective of the above activity is to have a separate wsdl for each native environment having a single endpoint. only the wsdl i attach to the service in CS will have multiple port definitions. the virtual service will always be deployed after setting a single endpoint, hence each mediator wsdl will have a single port definition.
I am using Centrasite 8.2. I have not faced such issue. Irrespective of how your Binding and Ports are defined, as long as a consumer sends a SOAP request to the correct virtual service endpoint, and the request includes a soapAction header, then Mediator can detect the correct service and operation. So if your request is able to hit the correct endpoint with appropriate soap action, you should be good.
Hey Yogesh,
The consumer would be communicating with the ‘virtual service’ WSDL that is spun by mediator. This WSDL has a Port, the name of which is specific to the mediator to which the service is deployed. Also, we are noticing that this Port name generation happens only when a service is deployed to multiple mediators from the same instance of centrasite. Currently, we have three instances each of centrasite and mediator to correspond to dev, qa and prod. In this setup, the virtual service’s WSDl contains the port name that is the same as the name in the native WSDL. Hence all mediator WSDLs have the same port names.
But when i deploy a service from centrasite to more than one mediator, the WSDL from the ‘second’ mediator has a Port name generated by the mediator itself. Hence, the different mediator WSDLs of the same service end up having different Port names. This requires client re-configuration/recoding.
I am not sure how soapAction would help resolve this issue, as the client created with one WSDL cannot be used to invoke the service using a similar WSDL with a different port name. Could you please elaborate if i have misunderstood/not understood your suggestion at all ?