I have searched for use of WSDL, but I am not able to fully comprehend what would happen if WSDL hadn't existed.
A example explaining the scenario would be nice.
Thank you.
THe WSDL is the "contract" which describe the objet use to call or response a WS and the service and operation expose.
In SOAP architecture, if you don't have this you d'ont know how to dialogue with the WS.
Additionnaly, in many language, it used to generate class that represent the objet.
there is plugin for maven or graddle for example.
Related
I had an endless argument with a friend recently. Our company exposes web services endpoints without their WSDL. WSDLs are hidden inside the system.
Some colleague say "it's better for the security". I say WHAAAAT ?
Another argument is "You don't need to expose the WSDL, because it is only used at development time".
So basically they say that when someone consume our web service, there is always a time where you pass the WSDL by email, in order to let them build a client. Once you are in prod, the WSDL is no longer used.
So, please, tell me I'm right. Tell me that when you expose a service to the outside world, you MUST expose the contract with the endpoint. It's THE RULE. talking about development is irrelevant here, right ?
My friend says that I'm biased because I wrote a dynamic gateway, so I need the WSDL at runtime, and this kind of scenario is very rare.
What really pisses me off in all of this is that the WSDL is considered as the .lib and .h of a .DLL or .SO, it's "just a thing required at development time".
I don't know what it is for CORBA and IDL... Does the IDL was exposed to the public at runtime ?
So, what is the right thing here ? I'm lost. The client is intended to receive the WSDL at runtime right ? Or not ? It should perform some kind of validation at runtime right ?
You are wrong. Making a good interface can take a lot of effort, years of experience, and the WSDL is a very detailed description of the service. If that is a secret, so be it. As authentication might be included, there is also a potential security issue.
I would like to argue that you should NEVER download the WSDL from a service if you can get the original instead. The online WSDLs are sometimes generated by the SOAP framework and things documentation will often not be included. Furthermore the endpoint address should always be explicitly set, never use the value which might be included in the WSDL.
In fact the right way to communicate the service definiton is not only a well-defined set of WSDL / XSDs but also with concrete request/response examples in including error responses.
Relying on downloading a WSDL to bootstrap your service is a receipt for disaster (if this stops your app from starting).
I have a question regarding authorization for SOAP services. Please note I am asking for authorization, not authentication which I know how to do using WS-Policy specification.
What I would like to do is to define access rights for different SOAP operations. For example: getMeSomeData operation is accessible to simpleUser but getMeSomeSecretData operation is not, but it is accessible to adminUser.
I was assuming this is possible since SOAP standard is quite complex. Is there anyone well oriented in SOAP who knows if it is? And if it is possible, could you give me any guidance or article I could read about how to do it?
Based on my extensive googlig, this is not possible.
About the only way to do this would be with some kind of server integration with whatever the back-end of the soap may be. But this wouldn't be a soap functionality as much as a 'hack' sitting behind it using whatever your authentication layer may happen to be.
I am currently looking at redeveloping a web service that is currently written in .Net. I would like to port it across to Java using a CXF, Spring, Hibernate and Maven stack.
The WSDL for the service is already available and is well formed so I would like to reuse rather than redeveloping the interface. This will also mean that the clients will not require significant changes in order to use the new service.
I would like to use a JAX-WS type approach to developing the web service, similar to the Java-first approach at http://cxf.apache.org/docs/writing-a-service-with-spring.html. The only difference being that I would like to follow a contract-first approach and ensure that the exact WSDL is used.
Has anyone attempted this before? Are there any good guides online that I can refer to?
I am actually not seeing in your question what is stopping you from developing it with WSDL first approach.
Check my answer here, for the tutorials you need.
I guess its pretty straight forward (The WS stack part)
1.Create the Implementation stubs using WSDL (contract)
2.Create Client using WSDL
* implement methods using your own logic and syntax
both 1&2 is supported by CXF.
good guides here
and here
We are developing an MDA platform that has support for Web Services. The user can provide a WSDL in runtime and we generate all the artifacts (service interface and implementation for the server, and consumer for the client) using JAX-WS internally.
We want to add validation on the WSDL document provided by the user. Right now the user has to validate that with an external tool like Oxygen, XMLSpy or a web tool, but we want to add that as a part of our system. A nice-to-have feature would be schema validation aswell, including the embedded schemas of the WSDLs.
In JAX-WS (RI) there is support for schema validation in runtime (using the #SchemaValidation annotation) but we haven't found any support for WSDL validation.
We've tried to integrate Eclipse's WSDL validator but it doesn't seem to work for us.
Is there any way of doing this with JAX-WS?
If not, is there any other validation framework that we can integrate?
Thanks
There is a bit of confusion in your question that I need to clarify first.
You seem to want the ability to validate the WSDL (syntax + WS-I) and XSDs, either embedded or referenced externally by the WSDL. On the other hand you bring in #SchemaValidation, which is actually used to validate instance documents.
In a traditional development approach, one might say you want at least the ability to validate design-time artifacts (WSDL+XSDs).
For this scenario then, I would recommend the following:
WSDL: for WS-I compliance testing, please take a look at the test tools section of the WS-I site. It is not clear how the licensing they have with their test tooling would work with yours, but at least it should give you an idea for what to look if it doesn't work for you.
UPDATE: Additional WSDL validation resources:
- Eclipse based, how to use outside Eclipse.
XSDs: if you really need separate validation for XSD files, things may get tricky for a production quality product; WSDL4J is not much help here, and I believe XSOM is the way to go for this kind of job. You have to extract content from the types section as one or more XSD files (could be more than one XSD file, take a look at some examples, Microsoft's SharePoint WSDLs come to my mind as a good test case), assign a base uri for each extracted XSD that matches the WSDLs location, then use XSOM to validate those.
Since you're generating the client, you're most likely not concerned with validating, say of the HTTP headers (SOAP 1.1/HTTP, SOAPAction, if it matches the WSDL operation definition). If you end up developing an interest in that as well, which I call runtime validation, then I would recommend a different layout in your approach (i.e. I would not rely on #SchemaValidation but rather do it through a transparent, and generic, proxy service).
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.