Has anybody worked on wsdl testing? Namely,
Schema validation
Semantic validation
Regression testing of WSDL
Interoperability
Does anybody have an idea of how to implement the above?
I use SoapUI for all my SOAP/REST testing. It does all the things that you want and is probably one of the most widely used tools out there.
It can also be integrated as an API. Integrating with SoapUI
For interoperability testing of WSDL's the toolkit I would recommend is that which is published by the WS-I for testing compliance against Basic Profile 1.1 and Basic Security Profile 1.0.
To download the tools look for "Interoperability Testing Tools 1.1" on the WS-I Testing tools page
Note that the test tool does 2 types of testing, a) Analysing the WSDL and b) Monitoring the traffic on the wire. I've only used the WSDL analysis.
The output from the WSDL analysis can be a pig to understand and decode and it really helps if you have a handy WSDL/XSD guru near to hand. Sadly these seem in short supply. Also it really helps to have a thorough understanding of WS-I Basic Profile beforehand (the 1.1 specification is at Basic Profile) and if you write your WSDLs to this specification then you should achieve conformance readily; which is also an argument against letting tools generate WSDLs for you as they rarely have achieving compliance as a goal.
Also note that when your WSDL comes through the analysis with a PASS this still doesn't guarantee interoperability with consumers written with the wide range of tools out there which generate proxy code from a WSDL.
At best you are getting a "stamp of approval" that gives you the best chance of meeting interoperability with the widest range of consumers. Once you do have a compliant WSDL you can claim compliance and assert this in the WSDL using the recommendations in the Conformance Claims specification.
I used to use SoapScope from MindReef (ok, I used their trials, but couldn't convince the company to buy it!) This was a very good product for compliance testing as well as for creating regression tests.
They have been purchased by Progress Software. The new URL is http://www.actional.com/mindreef/. I have not used this product they are now a part of.
You'd normally use a tool/product to do this. Altova (XMLSpy) comes to mind.
Related
I am very interested in Integration Platform as a Service.
As we know, it is possible to generate an API spec from an API. Is the opposite possible?
I want to write a piece of software that automatically create some functions for calling the endpoints of an Open API. In order to achieve that, the piece of software should consume an API spec and generate the code. Theoretically, this could be possible, if the spec covers all endpoints with all parameters of the API, etc. but:
this is often not the case
specs are written differently from each other
My question is: what should my software consume in order to get reliable information about the API endpoints, parameters etc.? Is there a standard for that? Is the API spec the way to go?
Look at Github Copilot. They're able to generate pretty descent facsimiles of functions from API spec. Just a word of caution, the function might not be 100% accurate and so you'll still need to check over it.
In a properly designed webservice there are at least 4 layers, presentation, application, domain and infrastructure.
REST documentation describes only the presentation layer's outer surface: HTTP interface and operations, so it is not possible to generate a complete webservice based on the REST API documentation. If your application does not have any kind of logic, it is just a data structure and CRUD, then it is possible, but in that case you'd better to find a database which has a REST API and very good access control and problem solved mostly.
If you have some sort of standard documentation like WADL or JSON-LD with Hydra, then you can generate a REST API skeleton for the presentation. I just googled the topic a little bit, maybe this thesis can be useful for you: https://repositorio.ul.pt/bitstream/10451/35311/1/ulfc121800_tm_Telmo_Santos.pdf
What is the difference between swagger-api and JAX-RS ?
Is the swagger-api only for documentation? (for example #ApiOperation)
As per the API docs, JAX-RS is the Java API for RESTful Web Services that provides portable APIs for developing, exposing and accessing Web applications designed and implemented in compliance with principles of REST architectural style.
Swagger, on the other hand, comes in picture when you have implemented your restful web services using any of the JAX-RS implementations (Jersey, RestEasy, Apache-CXF, etc as already mentioned by #Bijoy). Swagger adds form to your APIs by making them look good and presentable so that client code can be written easily, at the same time it also makes documentation a much less boring task by integrating it with code. Needless to say, also saves the extra time it takes to document if done after coding is over. In this sense, it is a bit revolutionary.
jax-rs is REST specification, and it is implemented by ones like jersey, resteasy etc, swagger is more on documenting and it has an easy interface if you want to test and make lot easier from different platform for adapt your rest functionalities
One of the crieria we are using when deciding between using REST and SOAP (RPC) style services is not just programmer convenience, but which is easier to test using Automated test tools. It seems there are lots of good tools for both, but is one inherently easier?
RESTful APIs are usually simpler, and built on top of well developed technologies that are easy enough to test (specifically, HTTP), so I would say RESTful APIs may be simpler to test. You can even do most of your testing with just a web browser, so I think that's pretty simple.
I want to buy a book on WCF because I need to develop latex to pdf conversion web service.
The idea is to let the customer submit latex documents (known as input file with .tex extension) to my web site and download the pdf output generated by the server helped by a service behind the scene.
I am new to WCF, so I have no idea, whether WCF can ease my development.
I am also considering the security issues such as protecting the server from any bad input.
Could you give me a suggestion whether or not WCF will suit my need?
EDIT 1: I am confused with choosing only one answer as both Martin's and Ben's really help me. Using classic probabilistic approach by throwing a coin, the result is Ben's. I am sorry.
WCF will neither help nor hinder your effort overmuch - it's designed to facilitate the actual plumbing of service routing and message handling. The "business logic" (in this case, the latex->pdf conversion) is left to the programmer to implement themselves. For a task with such a simple workflow, WCF would definitely be overkill.
If you had complex authentication requirements, WCF's security features would help you immensely, after a very steep learning curve. I'd recommend sticking with a simple POST or something. Your question about bad input is, again, outside of the scope of WCF. You'll have to take care of that in your business logic.
That said, good luck - sounds like a fun project!
I don't think WCF will help much. For the service itself, I recommend to use form upload (ie. e regular HTML page with a regular form producing a regular POST); this can be done with any web framework, including asp.net.
For the protection against bad input, you'll have to define "bad input": what kind of threat could a Latex file pose? But regardless of the threat - WCF is not designed to help protecting your service from bad input; the security is rather designed to prevent unauthorized users from accessing your service (whether or not they then submit bad input).
I'm just about getting into WCF; but from what I've read so far, like the sample scenarios I found on MSDN and some other sites, I can do all that with web services and applications that call those web services. So why the need for an elaborate layer like WCF?
Most of the comparisons I've googled for explain it more from a programming point of view. Still trying to find answers without much success as to when it makes business and of course programming sense to use the WCF layer as opposed to traditional application to web services model.
Anyone here with experience on both and can advice on how to go about choosing either web services or going the WCF way? What are those things that can't absolutely be done using just plain old web services called by applications and where the WCF layer will save the day.
You've fallen for the Microsoft trap of "it's just about web services" :-)
It's actually a lot more:
it's about service-oriented programming in general (not just web services - you can also write TCP/IP based services, MSMQ queue-based messaging and a lot more)
it's about unifying all the diverse programming models that existed so far (ASMX, Enterprise Services, DCOM, .NET remoting)
it's about providing a lot of ready-made and ready-to-use plumbing which can handle things like reliable messaging, transaction support, security in any shape or form you'd like, service discovery, and a lot more
it's about separating the service implementation from the details of how clients will call it and making this a configurable stack of protocols, encodings etc.
Sure - most of this stuff can be done in ASMX, or .NET remoting - but try to convert an ASMX web service to be callable in your intranet using TCP/IP and transport security... Many of those "older" technologies have a very intricate and direct link to how they're being used - you can't easily change that without changing the whole service code.
WCF separates all these "plumbing details" like what endpoint to call, what protocol to use to call it, how to handle security etc. out into a "WCF stack" that's configurable and composable, so you can easily switch your service XYZ to use HTTP allowing anonymous users to call it, to using TCP/IP with Windows credentials required - your service code won't change a bit - it's only configuration of the plumbing.
That to me is the most compelling reason for WCF - I can totally concentrate on my actual service code, and not pollute it with lots of plumbing stuff - how to handle transports and text encodings and all that. And I can easily change that and adapt to new requirements and needs in deployment without having to touch my actual service code.
Plus, the second major point is extensibility - most of the older technologies just had their one, set way of doing things and many didn't lend themselves to being extended. You had to either adapt to use it the way they did it - or forget about it. WCF has a vast and very intricate system for extending just about anything - you can create your own transport protocol (people have created UDP or SMTP based bindings), you can create your own message encoders (like I had to do to talk to a web service which could only understand ISO-8859-1 encoded messages), and you can extend just about anything else in WCF - all in an organized, well-documented, very stable and safe way.
So these two things - separating out plumbing into configurable layers, and extensibility to the maximum - are the most compelling reasons for me to use WCF.
Edit: Kobi's link above, is a far better answer than mine.
WCF is basically a better architecture for supporting communications. It breaks many dependencies such as hosting (not iis dependent), transport, security, addressing into plugin components, and allows customisation to a very high degree.
Yes you can do a lot with traditional technologies, however you can do more with WCF. If you don't need the features now then of course you can can continue with legacy technologies, however if you prefer you can opt for a better architecture now with an eye on the future but it comes at a cost of having to switch technologies now.
Take this example. If you have a legacy asmx web service, how easily can you offer the same service via an MSMQed endpoint? With WCF its as simple as adding new config settings.
I assume that you are not asking "why not just stick with SOAP/HTTP". WSF allows you to choose a number of different transports rather than just simple HTTP, but as you observe the WS-* technologies allow you to do all that. So I think you're asking why use a powerful but complex framework when the raw technolgies are not impossibly complex?
You could ask this same question of any Framework. You could just use the basic technologies and avoid the learning curve of adopting the framework.
Frameworks such as WCF do have a learning curve, but consider what happens if you don't use them:
You find that you write boiler-plate code for each service invocation. You then either accept duplication or begin to refactor and build your own libraries. Before long you've developed your own Framework, but it's not the same as anybody else's. So then any new team memeber has to learn your local framework, serious learning currve.
Note also that WCF addresses issues such as the monitoring of the deployed solution.
The biggest appeal to me is testability. Services are defined by a CLR interface, which is quite easy to mock inside a test harness. Some words of warning, however. With great flexibility comes some pain in the configuration process, along with a few "gotchas". An example of a gotcha is that WCF--adhering closely to a "best practice"--requires an active SSL connection in order to pass SOAP authentication credentials over HTTP. This hinders testing quite a bit.