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
Related
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
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.
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 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.
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.