How Drupal can read the external web services? example:
this web service xml:
"www.mysite.com/dabs/xml_view/xml/bank_id:10/updated:1".
this link is a web services xml, I want to consume it in drupal.
I found drupal can create Web services from its contents, but I do not know how he read the other webservices.
how drupal can read, modify those tags, put, post, delete ..... ??
Usually, consuming a Web Service requires developing a client application. In the case of a Drupal site, it should be done a Drupal custom module. Except for the integration of custom code in Drupal and usage of its API/mechanism to display information on pages, store them, etc. this would standard PHP coding.
There is also two module that are supposed to help you with that, or even remove the need to develop a custom module. Unfortunately, they both have the same name: Web service client. One is https://www.drupal.org/project/wsclient, the other is https://www.drupal.org/project/clients.
The actual complexity will likely be in consuming the service properly. For that, you need good understanding on usage of XML and HTTP Requests, and preferably good documentation of the web service (incl. data format and meaning of the various values in the XML).
Use web service client module in drupal
https://www.drupal.org/project/wsclient
Related
Trying to understand which of the better modules to use for my page's specific need. Services module is popular, but that seems more for providing service, where the Web Service Client is good for consuming a web service.
Here's the requirement:
On the web page, I've got a form whose fields (location, service areas, region, indicators, etc) are to be built dynamically and some are selectable based on other selections. (So choosing worldwide would make Hubzone 8A not appear.)
Another team built the SOAP web service, it sits on another server outside the web server. What they delivered to me is a URL to invoke, basically an XML file:
http://webserviceurl.com:52901/navigator/NavigatorServices?wsdl
(Obviously, I just can't use the Feeds module to import the XML manually, right? The whole point of the web service approach is that as the data in the web service is updated, the Process form will by dynamic.)
So I'm really at the beginning of this. Need some guidance.
Web Service Client and SOAP Client are the ones that should do the work for you.
If you find it difficult to understand how to use them, you can simply use nuSOAP library + some PHP code inside a module. This article provides a good tutorial about providing and consuming Web Services using nuSOAP.
PHP provides a SOAP API. So you can simply create a module using this API (and Drupal Form API).
I am not sure if I am comparing onion with a cabbage. But I am really confused with the portlet and a web service. I know that web service is making your software components in your application as a service to other applications but to me it is similar to a portlet responding to requests. I know that my understanding is making you(Portlet & SAAS developers) really upset. But I need some clarity on this.
Why cannot I use the request-response to portlet work similar to a web service?
If yes, what is the benefit I get in using a web service than a portlet?
If not, then what are portlets lacking to act as a web service?
I am a newbie in portlet development. Please dont curse me for this question.
Please suggest.
EDIT:
Most of the answer say that the portlet is a UI component. My customer has requested me to create a webservice in liferay. So is it to make a portlet as a web service? If yes, can you please provide a pointer or some code snippet?
Addressing your 'edit' specifically with regards to Liferay...
Liferay plugin projects can expose web services without too much work.
The Liferay Service Builder actually has facilities so you can create SOAP web services or JSON web services backed by tables in the Liferay database (and that make queries on existing database tables). In the case of JSON web services, the URL scheme generated is not RESTful (unfortunately), but it is well defined. With a bit of work on your part you can impose Liferay's permission system on web service calls as well.
Here's a reasonable starting point in the Liferay Developer's Guide:
See the links on that page to SOAP and JSON services.
Note that a 'portlet' is only one type of Liferay plugin. The web service facility is part of the service layer - which can be used by many plugin types. So there isn't necessarily a portlet involved in creating a web service in Liferay, you can make a web service that has no visual component associated with it.
Portlets are areas you create to add and display content. Portlets can be added to the left and right of the center body area and can contain myriad content ranging from news, events, calendars, RSS feeds, collections, plain text, and more. Also, you can set properties and policies for showing the portlets.
you want to use portlet when
You have content you want to have special focus, like news.
You need to specify the configuration data for an item. - i.e. number of entries to show.
You want to give the content editors a choice about when and where to display content.
You'd like to show it only to some groups or users.
On the other hand, web services:
Enables applications to expose their services
“progammatically”, i.e. the services can be invoked by programs
Enables software running on other computers (could be a desktop, mobile phone, PDA, etc.) to invoke operations exposed by Web applications
if you are trying to identify the main difference portal historically, the portlets have three layers architechture (client, middle tier, backend) this cause two weakness:
Different portal groups have no well established way of sharing services
Different technologies(Java, Perl, CORBA, EJB) in middle tier.
Different protocols(GRAM, IIOP,...)
Consequently, lots of redundancy, reinvention
Example: batch script generation
so Web services address the service sharing problem and reduces the redundancy.
source1 source2 source3
Portlets are meant to be a user interface component in a portal solution.
Web Services provide functionality to remotely interact with a system commonly using SOAP, REST, JMS or other related
They provide completely separate functions. The closest you get is the serveResource method in portlets. This functionality is used to serve various types of content from a portlet (such as a PDF document or an AJAX response) without the need to perform a full page request.
I am using Axis2 (1.5.3 currently) and Tomcat (6.0.26 currently) and am running a web service. I would like to also host HTML pages for configuring the web service.
What is the best way to go about this? I assume keeping the same context is key, but perhaps it is not.
My current distribution is located under a folder structure similar to this:
Tomcat/webapps/mycompany
With the actual service code here:
Tomcat/webapps/mycompany/WEB-INF/services/myService
In a browser, I can hit my web service by going to here:
/mycompany/services/myService
I note that I can drop actual HTML files in this path and Tomcat will, indeed serve them up.
For instance, if I put "index.html" under Tomcat/webapps/mycompany, I can navigate to /mycompany/index.html and see my html.
What I want to do is have this HTML be attached to JAR/class files that can interact with the already-existing service class files in the same context as the service. Therefore, I can have the browser configure the web service directly.
Is this possible, and is there a tutorial or something out there that will help me with this? Note that I have been working with Tomcat and Axis2 for a while now for this particular web service, but I have never actually deployed a web application/html using Tomcat before.
Thanks.
First of all what do you mean by a configuring a service. Normally in SOA world services are analogous to interfaces. IMHO you can just change a service, since their are other users that rely on the services you are exposing.
If i want to change a service i would rather introduce a new version of the service after deprecating the existing one.
Are you talking about applying QoS to existing serviecs. Then that makes sense.
Anyway, If you want to have a web-app alongside with axis2 service engine, it is possible. If you look inside the axis2 war file you'll find the web.xml entry to Axis2Servlet. It is this servlet that serves the web services requests.
So, what you need is the Axis2Servlet mapping in your web-app along with your usual servlet-mappings. Number of possible ways to configure your services using web-app files. One options is to use web-services call itself to (with authentication) to configure it.
By "configure a service", take this example:
The service has a set of datasets.
Each dataset exists in a separate database.
The service can manage 0..n datasets.
The service must be configured to know about each dataset.
This is what I'm configuring. I'm not trying to configure Axis itself or redefine the service.
I would like to host the HTML using the same instance of Tomcat that I'm hosting the web service with. It needs to manage sessions, have login capability, an whatnot, and has to be able to configure the web service live.
From what I'm reading, it's probably best to make an interface to the web service that the web application module can call into from a different context.
Is there a better way?
I am looking for some good starting point for developing web-service.
I have one application which has C++ library support using which I can get all the details of the product.
I am supposed to write web service SDK for the same.
Any help.
Web services generally refer to a technique that allows code to be called via HTTP requests and responses. This is similar to a web page, except that what is returned from a web service is usually not HTML intended to be displayed in a browser - it is usually data of some kind.
"Web Service" is one of those terms that means whatever the person saying it means. Basically, its just a way to access data or functionality via http. There's a few standardized methods - REST, SOAP for web services, or you can just serve up XML, JSON, or other data from a plain old server side web app.
What you'd want to do is investigate what form this Web Server you are supposed to write needs to be in (SOAP, REST, something else), and then go from there.
When I want to find a "Big" Web service (WS-*/WSDL based) of required functionality I can simply google for ".... filetype:wsdl" because Google indexes also WSDL definitions. Or I can simply use some registries that already crawled the Web for WSDL definitions for me, e.g. SeekDa.com or ServiceFinder.
When I want to find RESTful Web service (RESTful Web API) I may count only on the community, because it is not possible to distinguish between URI of RESTful Web service and other Web resources (e.g. Web sites URLs) and hence any focused crawler cannot tell for 100% sure: this is URI of RESTful Web service. So, I come e.g. to the ProgrammableWeb.com and I hope someone already used/found the service I'm looking for and registered it there.
Recently, I was looking for the Web service for abbreviation expansion. I couldn't find it in portals like ProgrammableWeb, because no-one has put it there. Finally I was forced to browse through several abbreviation dictionaries sites, dig and drill there and I finally found Abbreviations.com Web service API in RESTful form. That took me a lot of time!
Is there any other Way to discover RESTful Web services on the Web?
There is a convention (recommended in REST API Design Handbook for example) that you expose a /api endpoint at the root of your service. This returns an XML or JSON response containing the "child" resources that your service supports e.g. /api/products
The REST ideal is that services are as consumable as Web Pages are, they don't need registries. [Got to admit I don't fully "get" the implications of this RESTful world, no WSDL, no registry feels like riding a bike with no stabilisers.]
In the old Web, pre-Google, how did we find pages? Effectively word-of-mouth and a few key starting points. REST services so far as I can see are pretty much in the pre-Google stage.
I don't agree that "it is not possible to distinguish between URI of RESTful Web service and other Web resources" - if we follow the link we get certain types of content application/xml and application/json would be pretty strong indicators wouldn't they?
There's a WSDL-like file for REST webservices: it's called WADL.
SoapUI now can discover the REST services. It works as a proxy, writing down all requests/responses that pass through. Having requests and responses SoapUI recreates descriptions/definitions of the services.
Now the definitions can be stored in WADL and WSDL formats (as WSDL and XML-Schema in XML world). It also can be stored in Swagger format. I prefer Swagger.
Swagger can be stored in SwaggerHub right from SoapUI, which is like GitHub for source code. SwaggerHub is one of many API management systems.