What's the difference between WSDL,DISCO and EVENT? - web-services

All of them are web services, but what's the difference?

WSDL (Web Service Description Language) is a standard notatation for describing a Web Service in xml.
DISCO is a tool for querying SOAP and similar services and extracting useful information from the WSDL provied.
EVENTs is a proposed standard which uses WSDL and extends WSDL to support publish subcribe type event driven processes.

WSDL:
WSDL is a markup language that describes the web service. In order to use this Web service, the Client application developers need to know the methods exposed by the Web service and the parameters to be passed to these methods. It is imperative that access to these methodologies is available at development time and it is just this need that WSDL addresses.
DISCO:
The Web Service Discovery Tool (DISCO) is used to discover the URLs of XML Web Services located on a Web server and saves documents related to each XML service on a local disk. The DISCO takes the URL and discovers and produce publishes discovery documents (.wsdl, .xsd, .disco and .dicomap files) as arguments. Some of the options available for use with this tool are:
/d[omain]:domain - Specifies the domain name to use when connecting to a proxy server that requires authentication
/nosave - Does not save the discovered document or results
/nologo - Suppresses the Microsoft startup banner display
/o[ut]:directoryName - Specifies the output directory in which to save the discovered documents. Current directory is the default one.
/p[assword]:password - Specifies the password to use when connecting to a proxy server
/proxy:url - Specifies the URL of the proxy server to use for HTTP requests.
DISCO is a tool, not a web service itself.
EVENT:
if you mean to WS-Eventing, see here.

UDDI- UDDI is a central directory. It will have web services listed from multiple domain and servers.
DISCO- Disco contain web services listed from one domain and server.By which particular web service can be selected.
WSDL- It describe the rules or grammar for the function that are exposed in the web services.

Related

Testing Applications for use of Web Services

1) Is it possible using burp suite/ ZAP or any other web testing tools to find out
if an application is making calls to web services?
2) As SOAP web services reply in XML is it also possible to view the responses of
the HTML request to distinguish between use of REST web services?
Thanks
Yes, this is normally possible.
You need to configure the application to use the interactive proxy (Burp, Zap, etc.) as its proxy. Most applications will use your system proxy settings.
Once the proxy is configured, you can see a full history of HTTP interactions (in Burp: Proxy > HTTP History). This includes requests and responses, which will clearly indicate a SOAP or REST service.

Web Service, Services & Endpoints

I am looking for clarification on the definitions of Web service(s) and endpoints.
I have always thought of web service and services as the same thing but I am not sure if this is correct. I have always thought of Endpoints are related to the resource they are retrieving and not whether it is a PUT/POST or whatever.
So with my understanding the following are two separate endpoints regardless if they are PUT, DELETE and so on:
/user/
/organization/
And as a collective the application is a Web Service.
I have seen others document each resource including the HTTP verb as a separate endpoint and that each resource is a web service and so a collection of the resources are web services like so.
Web Services (Web Service x2):
/user/
/organization/
Endpoints (two):
GET /user/
POST /user/
Is there a general clarification or standard that I am missing?
If not what is the common definitions of Endpoint, Web Service and Web Services
Cheers
Endpoints and webservices
You can understand endpoint as the URL where your service can be accessed by a client application. And a webservice can have multiple endpoints.
REST architectural style
Webservices can use the REST architectural style, which is protocol independent, but it's frequently designed over HTTP.
The REST architectural style was defined in the chapter 5 of Roy Thomas Fielding's dissertation. And the following set of constraints was added to this architecture:
Client-server
Stateless
Cache
Uniform interface
Layered system
Code-on-demand
The fundamental concept in a RESTful API is the resource. Resources can have different representations. For more details, this answer can be helpful.
REST over HTTP
Consider, for example, a webservice that exposes the following endpoints:
/messages: This endpoint identifies a collection of message resources.
/messages/{id}: This endpoint identifies a particular message resource.
Operations can be performed on the resources by performing HTTP requests to the endpoints using HTTP methods, as following:
GET /messages: Get all messages.
DELETE /messages: Delete all messages.
POST /messages: Create a new message.
GET /messages/{id}: Get a message using the identifier.
DELETE /messages/{id}: Delete a message using the identifier.
PUT /messages/{id}: Replace a message using the identifier.

What is the difference between a Rest WS and Servlet

How do they differ in action? Servlet print html only?
Servlet :
--is a web component
--it's a powerful java technology
--managed by a container (namely web server such as tomcat) that generates dynamic content
--platform independent java classes (byte code)
--interacts with web clients as request response paradigm
--Request handling methods
****doGet,doPost,doDelete,doPut,doOptions,doHead,doTrace****
Rest WS (Representational State Transfer Web Service)
--A way to achieving service oriented architecture in web application
--it's an architectural concept
--web service resource is uniquely identifiable using URLS
--it has explicit relationship with HTTP methods namely GET,POST,PUT,DELETE
--highly re useable across the platform
A Rest WS is a service which you call, which returns data in a REST format.
A Servlet is a bit of UI that shows information to the user.
They are very different, although a Servlet could get the information that it displays from a Rest web service.

How to call web service method in C++?

As title, in Linux System,how can I call web service method in C++?
Use open source libraries like gsoap or Apache Axis.
Note that this has nothing to do with the underlying platform, Web services need the data to be encapsulated in a SOAP object(in case of SOAP web service) and these libraries just provide you the framework to do so.
The above libraries use the wsdl of the web service as an input parameter and generate the necessary stubs for communication with the web service.They abstract the nitty gritty's of communication with the web service from the end user and provide simple interfaces to get and set the data to be sent or received over the web service.

WS security Coldfusion

Working on a docuSign integration with Coldfusion and need assistance in making the SOAP request using WS security.
Your question is a little short on detail, but I presume you mean the Web Services SOAP security extension.
We had to do this a few years back when communicating with a .NET web service. The basic idea is that you provide a set of extra SOAP headers that contains security info such as:
Timestamp
Username
Password
Etc
To do this you need to create a new XML document as per the standard defined here. Next you will need to write code to create the SOAP headers. This means:
Create your remote web service object, e.g.
var objWebSvc = createObject("webservice", "http://remoteURL?WSDL");
Creating an XML document to represent the new headers
Populating it with the required info (such as username and timestamp etc.)
Adding the XML document to the web service object, using addSOAPRequestHeader()
Call your remote web service
Then of course if and when they call your web service you'll need to parse out those headers from their SOAP request and validate them. That can be done by grabbing the XML using getSOAPRequestHeader() and parsing out the info.
I found this to be an error prone task and (basically) a royal pain. The web service we integrated with eventually dropped the requirement, apparently becuase the any web services trying to connect that were not native .NET were having a hard time implementing the specification.
Good luck!
I blogged this a while back. See if this helps:
http://onlineanthony.blogspot.com/2010/05/using-ws-security-for-soap-in.html