After going through the following article I came to know that if Axis2 is used on both ends, we could expect high improvements in performance.
Link : http://wso2.org/library/91
I'm writing code to consume a webservice. I'm just curious to know the framework used on the server side. How do I do it programatically using Axis2.
Server side you can use any java class.The following are the server side styles that axis provides.
Service Styles - RPC, Document, Wrapped, and Message
Also see the documentation here.
There is no such API available as such. Of course, such API is not supposed to be there at all. The whole point of using web services is interoperability i.e. the server doesn't care how the client is implemented and the client does not care how the server is implemented. Defining such an API does not make any sense, adds no business value except curiosity as in your case above.
Albeit, It still might be possible to do so, unofficially. Try to send some parameter value which is not correct business value. From the fault that is generated, it might also give stacktrace of the server through which you can probably guess the server side framework being used.
Related
Our team is currently looking at developing the interfaces for a new network monitoring system. We are to support access to the system from:
a web browser (Javascript/HTML5 based)
any REST client (could be a command-line REST shell or some other higher level system, for ex: to do mashups).
We were thinking of providing same REST endpoints at the Server side (Java EE based) to support both types of clients. This is because, we think a browser is also a REST client, in a sense. And because we thought it will avoid any duplication at the server-side. And we are running low on engineers (which may be a good thing after all!).
We will be doing Asynchronous request/response-handling at the browser using Ajax. And we think any other REST client needs to take care of any asynchrony it wants.
1) Is this how it is usually done these days ?
2) Is this a good approach, regardless of any other consideration?
Or does one need to consider any other aspect, before making this decision ?
3) I think this implies that we are to send all responses as JSON only from the server and do client-side rendering only. Right ?
Yoy're right! Here's my opinion:
1) Is this how it is usually done these days ?
Yes. The most of REST Api were builded on same server side API. This API provide information to the client, whatever is the client side, that must be an browser or command line call.
You can take a look on free Apigee ebooks, especially this one, to get more information about how to build a powerful Restful api.
2) Is this a good approach, regardless of any other consideration? Or does one need to consider any other aspect, before making this decision ?
I think is the finest approach, you have one api to manage your services to clients.
3) I think this implies that we are to send all responses as JSON only from the server and do client-side rendering only. Right ?
Right. Some javascript frameworks, like AngularJS, do all the rendering on browser only with JSON responses from the Rest Client. You can do it with JQuery as well.
In the place I work there are some software written in C# and some written in C++ (the most important ones). Some time ago we decided it would be a good idea to track any possible problem in the software, by sending stack trace and exception information over a web service. So I came with a WCF Service, that gets the information and store them on a database and send an automatic e-mail. It worked, we had to secure it through password, it's done, but now I want our other software, the one written in C++, to use this webservice (this software is used both on windows and linux, so we can't just make a call to another software in the user machine).
I've googled about it, and found this tutorial on how to use gSOAP, which so far didn't help me very much (lots of errors, it is not very detailed, and the web.config file is impossible to read). I was wondering if is there any other way to achieve this. In adition, since I'm using authentication on my webservice, it now has a wsHttpBinding (which AFAIK isn't supported by gSOAP).
Can you guys help me out?
Since your WCF service is in C# with .NET, and the only issue is getting the C++ application to be able to talk to it, one way is to follow the advice in REST / SOAP Endpoints for a WCF service and related articles.
Your C# programs continue to have the full SOAP access to your service.
Your C++ programs could do something like this for REST access:
"Browse" to the HTTP GET URL for the service command you wanted.
Then toss (or parse and use) whatever response came back.
It is a pretty minimal change to your WCF service to offer both SOAP and REST.
The REST ability opens your service to JavaScript as well as C++ clients.
You may need to restrict the interface to simple data, or class objects that are easy to parse in C++.
Will the machines running the C++ applications have the .NET Framework installed?
Check out: Create WCF service for unmanaged C++ clients
I am building a prototype hybrid app with a Flex3 RIA client and backend Axis2 in Java on Tomcat 6. As this is a prototype, and given that I keep options open for factoring in other client types, I'm using a plain old SOAP service between client and server, rather than any Flex-specific technologies like BlazeDS
Although there is much debate about the need for stateful behaviour on the backend for an RIA, I need to consider the possibility of maintaining transport-level sessions between client and server. From reading the docs for both Axis2 and Flex, this appears to involve
(a) setting scope="transportsession" in services.xml, and
(b) ?what? in Flex
Can anyone help with (b)?
The webservice client classes are being generated in Flex Builder using the WDSL introspection wizard, so unless I refactor this, I only have access to the methods thus exposed.
I have found zero examples of the above online, and the FLex documentation leaves something to be desired in this area.
All help appreciated.
D
This is bit old article . but may be useful.
transportsession : This session is managed using transport cookies, and the lifetime is equal to the lifetime of the underline transport.
http://wso2.org/library/2060
I am little bit confused about what really a web service is. You say Amazone web services,etc like that, they offer information. So what is the requirement to be a web url to be a web service ? Let's say I am not much familiar with web development, how could you explain it to me ? But I can get it if you point some ways.
And also little about SOAP and REST basically for someone really new
What is a web service
It is many things. In programming, in generally refers to a web page, that can be called from an application (be it another web page, or desktop app), and the caller will pass in data to it, or receive data from it.
In this sense, it's basically like a 'method' or 'function' in a normal programming language; except you're calling it over the internet.
SOAP
A message format. As discussed above, a web service is a basically a 'method' or 'function'. SOAP is the 'instructions' and 'data' to this method. It will outline data types, and possibly a bunch of data as well. It is an XML format.
REST
REST is the means of implementing an interface to your application but, implementing access control, and other such things, specifically with HTTP Response codes. So you will get a 401: Denied (I think that's the right code), if you don't have access. There are other types of response codes that are useful. It also makes use of other HTTP commands like PUT/HEAD/OPTIONS.
The W3C defines a Web Service as (quoting) :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network. It has an interface described
in a machine-processable format
(specifically WSDL). Other systems
interact with the Web service in a
manner prescribed by its description
using SOAP-messages, typically
conveyed using HTTP with an XML
serialization in conjunction with
other Web-related standards.
That definition is maybe a bit too restrictive, considering how that term is used nowadays -- I'd probably go with just the first part of that definition, which is quite generalist :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network.
Wikipedia also has some interesting definitions, like :
In common usage the term refers to
clients and servers that communicate
over the Hypertext Transfer Protocol
(HTTP) protocol used on the Web.
From what I've seen :
A couple of years ago, when we said "web service", we generally meant "SOAP, WSDL, ..."
Now, when we say "web service", we often mean "whatever allows to call something on another server, be it SOAP, REST, ..."
A Web-Service can be considered as a set of methods that enables communication amongst applications irrespective of the application's coding language or framework.
http://acharyashri.com/blog/WebServices.html
Think of Web services as remote APIs (since they are basically just that). You have a method that you want to implement. Let's suppose the method wasn't built by you and resides somewhere else in the world on equipment that you have no control over—how can you go about providing that remote method what it needs in order to get instantiated?
When you find a Web service that you want to include in your application, you must first figure out how to supply the Web service with the parameters it needs in order for it to work. That need also extends a bit further. Even if you know the parameters and types that are required for instantiation, you also need to understand the types that are passed to your application in return. Without these pieces of information, using Web services would prove rather difficult.
Just as there are standard ways to represent data as well as standard ways to move this data over the Internet using Web services, there is a standard way to get a description of the Web service you are interested in consuming. Web Services Description Language (WSDL) is a specification of XML that describes the Web services you are interested in consuming. It's just an interface to describe a web service.
I am writing an interface for our VXML application that will allow access to a SOAP service.
Because of the difficulties inherent in trying to use javascript to make SOAP calls and the limitations of VXML, as in making external resource calls are pretty much limited to HTTP requests, GET and POST.
I designed a java servlet that would act as a service provider to the VXML application. It can call this servlet with arguments indicating the web service type, the method name to invoke and the arguments to pass to it. The servlet then makes the appropriate web service call and returns the response in a standardized VXML document response.
The issue is I severely underestimated how difficult SOAP really is. I thought I could just simply construct the soap call and do it in java, however its looking to me like this is something a little more involved, requiring things like Apache Axis2.
I read somewhere that listeners for Axis could be HTTP servlets, which sounds a lot like what I am doing already.
Am I re-inventing the wheel here?
Is there any suggestion out there for me as to how to do this better?
I am pretty invested in the way I'm doing it now and so would be very receptive to an easy way to accomplish the SOAP call and process the response from a jsp servlet.
EDIT - After taking the advice here I've delved a little further into Axis.
As it turns out, Axis2 is Apache's third generation of Apache SOAP. Whats unfortunate about this is that after extensive searching I cannot find a single solitary place where the original Apache SOAP implementation can be downloaded.
I might not care if:
A) Axis would allow me to integrate a few jars and jsps rolled
into a standalone WAR app
B) everything .. i mean everything up to this point has been done using
examples from ApacheSOAP (the book i was using, the code I've
written thus far .. everything).
So I google some more thinking .. hey, there has to be some kind of stand alone library for Java that would just simply allow me to make a single solitary simple SOAP call and parse the results.
But no, no such luck!
Apparently if you want to use Java and SOAP you have either the gigantic incomprehensibly thick and complicated axis or .. you roll your own soap implementation from the ground up. I am so burned on this. I don't get why soap is so wonderful given the last 7 13 hour days I've spent just trying to get a simple hello world request to work from JSP.
A library like Axis is definitely the solution, you do not want to attempt to build/parse SOAP messages on your own.
Look at using wsdl2java (another link, and another) to create client proxies for which you can invoke the web services. This will generate a bunch of Java code which you can call into from your code, and then Axis will handle packaging your arguments into XML messages, sending it across the wire to the server, de-serializing the response, etc.