Why mexHttpBinding is required in WCF service - web-services

mexHttpBinding is required to exchange metadata over Http, this is useful when clients want to create proxy classes.
I have a WCF service without mexHttpBinding but i can still see its WSDL on the browser, i can still create proxy classes by adding reference of it in VS.
What is the exact need of this binding or am i missing something?

My bad, below is the answer.
MexHttpBinding v/s WSDL

Related

OSB Service based on WSDL having multiple ports

How are you doing!
I have a scenario where I need to create an OSB service(which is a mere pass-through service) that will be based on a WSDL that contains 2 ports, each pointing to a different URL. In this case, How do I create the proxy and business services. As I see, when I create the proxy service based on a Port, only one port can be selected at a time, so I'll need 2 OSB Services/proxies. If I select the binding, then the port informaiton won't come from the wsdl into the generated effective proxy wsdl, and it will have only one port, so even in this case, I'll have to generate 2 wsdl's for those 2 ports. Am I right? or Am I missing anything?
Another question on the same scenario
We are storing all the wsdl's in MDS, so need they are abstract(atleast not service/port information). So, in this case, if I make the wsdl as abstract, it will lose the port information, so how do I do? 2 business services, each pointing to a different URL? So even in this case, what about the proxy service? How can a proxy service that exposes one port cater to 2 different services?
Is there anyway that I can achieve this with a single OSB Service? I would prefer the 2nd approach of storing abstract wsdl's in MDS.
Regards
RaviKiran
When you create a Proxy service, you have full control over how that proxy service calls out to business services. In your case, something simple like an Operational Branch would suffice, but really, OSB allows you to control calling out to multiple services. You don't need to provide multiple ports for your proxy service, as you can make all the calls and control from inside.
Regarding your second question, it wouldn't matter if you're using abstract or concrete WSDLs in your OSB configuration for either the Proxy or the Business Services. You define the endpoint you're connecting to. In Business Services, OSB will take your WSDL and call whatever endpoint you tell it to. For a proxy service, the server OSB runs on will dictate what port address it's going to use, outside of the Endpoint URI that you've defined for it.
I would read Oracle's documentation on the Concepts and Architecture for OSB. It covers alot of this background information on implementing proxy and business services, and might point you to the more specific question you want answered. In particular, section 2.2 covers the Proxy and business service abstraction concept pretty well:
Oracle® Fusion Middleware Concepts and Architecture for Oracle Service Bus
11g Release 1 (11.1.1.7)

WSDL for WSO2 ESB proxy service

I have done a few use cases on WSO2-ESB including protocol mediation with transformation and service-chaining.
In all of them I had to manually write the wsdl for the proxy service. Having experienced other vendor products including Oracle and Tibco where wsdl generation is done by the tool.
Would it be right to assume in WSO2 ESB one needs to manually write the wsdl file to expose a proxy service on any protocol, do not see any documents calling that out.
Considering the usage of wsdl in practical use cases.
I have seen posts stating "you can give the WSDL available at your Axis2 service" but most of real time use cases would not be pass through and have custom request and response.
Thanks,
Wajid
I'm also confused with manual wsdl creation. As far as I can see there are gaps in wsdl proxy description. When I do wsdl proxy with WSO2 I have to indicate wsdl to expose
its either as:
"none" and I have only mediate function exposed
"same contract" and this breaks the whole idea of proxy because after that clients read original wsdl and go straight to original server access point.
or and I have several options to make my own wsdl.
With rich SOAP API (hundreds of methods) none of above work well, considering that manual support of exposed WSDL is rather cumbersome.
I wonder if there is more adequate way for proxying WSDL?
You can use java2wsdl generator tool to achieve the WSDL generation.
For the proxies, if you try to restrict access for some operations in your backend service, you can attach customized wsdl to the proxy.
The customization has to be done by yourself and it is simple..
If you want to generate a wsdl fro your service, jsut deploy the service in wso2as, and check the service dashboard, wsdl option to view the wsdls.

Client Generation in web service(jax)

I made a web service endpoint and exposed a method now i wanna add more parameter to my method
so each time i change in my method i have to regenerate my client. Is there any way so that i
dont have to generate my client again and again.
No, there is no way. If you change the method then the WSDL file is changed also. Web services communicates through SOAP between client and server. When you deploy your web service application and it has been changed, so how then client supposed to know if there is a new method or a new parameters added if the classes was generated from the old WSDL file. Client will send a SOAP request according to the old WSDL and the server won't be able to understand the SOAP message received from the client if there was any changes made to WSDL part related to the received message.
You could design a better webservice/endpoint that accepts a standalone xml document as argument so that the operation signature stays the same, even when you add more parameters.
More generally, it's bad form for a web service to expose it operations as literal method signatures.

Spring Web Services - WSDL

In your wsdl, is it possible to connect directly to the wsdl(i.e - http://(url)?wsdl.
When I copy the wsdl locally to src/main/resources - I am able to connect generate objects including Web Service client, but when I try to connect to the WSDL that I copied from, I cannot generate. Perhaps I am not understanding QName and wsdllocation and even port for that matter.
I have searched fairly extensively on the web and there aren't that many clear cut examples. I know WebServiceTemplate makes things a LOT easier but without connecting to the WSDL, I cannot connect.
All I am trying to do is connect to the client. So it is a question more about Endpoints.
Also is it best practice to copy the WSDL locally. I am asking this because the client that we are working for has a 100 million environments.
Thanks.
Thanks
WSDL url will be like http://localhost:8080/<< Context-Name >>/<< ServiceName >>?wsdl
If you are generating the wsdl by running a server, then localhost:, should be given. If its a direct wsdl file, then try right clicking and opening it using a web browser. It will simply give you the link. You can use the same link to produce client stubs too.

How to decide between Message Contract and Data Contract in WCF?

I am reading so many things to understand various things in WCF.
Very soon, actually, i want to move/convert existing WSE3 web services to WCF. In existing WSE web services, I have some (data) classes that model entities in our environment.
While transforming those classes, should I use Data Contract/Data Member attribute or the MessageContract attribute?
1. How to decide between Message Contract and Data Contract in WCF?
2. Does type of binding (like basicHttpBinding) has any role in this decision?
3. Does proxies created at client side (when we add web reference) change significantly depending on the Data or Message Contract?
(PS: I am trying to find a way so that existing WSE clients should be able to consume the WCF service without much alterations/modifications. Is it possible to use the current proxies generated from ASMX web services, to connect to the new WCF service just by setting URL of the proxy to WCF service?)
Here is a quick go at answering your questions:
1) Unless there is a specific reason like tweaking the structure of the soap XML, use DataContract instead of MessageContract.
2 & PS) Since you are currently using soap over HTTP, you'll most likely need the new services to be configured for basicHttpBinding. This will provide the interoperability that you need for the ASMX clients.
3) It shouldn't if the soap structure created by the WCF service matches your current soap.
I vaguely remember that WSE 3.0 supported some of the WS-* standards. If your current code depends on these then you may be able to also expose a wsHttpBinding for these operations but I don't think a default ASMX client works with a wsHttpBinding configured service.
It depends on control you need over resulting SOAP message. DataContract defines part of message body wrapped by element defined by operation. MessageContract defines a structure of whole message - you can use multiple body members, you don't have to use default wrapper element and you can also place some data into SOAP headers.
In your scenario the most important part is to define WCF to use same SOAP messages as your former WSE3 service. Here the important is how do you currently serialize data? If you use Xml serialization (and attributes) you can use it directly in WCF by switchinig from data contract serialization to xml serialization.
Btw. why did you use WSE3 instead of plain ASMX? Did you use message security? In such case you will need another binding. BasicHttpBinding is not able to do message security.
General answer is yes, you can create service wich your current client proxies will be able to consume. But in reality the effort depends on your current service and current code.