The server side implementation class that gets generated has no dependence
on Axis or SOAP. It is meant to contain your business implementation of
the function. The skeleton class is Axis aware and calls the implementation
class. So the implementation class can be tested without any dependence
Each web service instance could, potentially,
process requests from many different clients. I'm sure that this is the
reason for the stateless requirement. Static state is not an issue, only
instance state, where the service stores information from previous requests
to process future requests, is
I would guess that these different interfaces
and their implementations are separate for a reason. If so, why not keep
the web services separate, for the same reasons, plus the additional reason
that you don't end up with a huge, incomprehensible WSDL?
Incidentally, you don't have to create a
To my mind, unless you are writing code purely
as a web service (that is, code that could never possibly be reused), it's
best to go with writing the business logic separately. In this way, it
can be tested without needing any web service infrastructure in place,
and can be written for
You can specify the file path of the WSDL
in the server-config.wsdd configuration file.
service
!-- add your service configuration
elements here --
wsdlFile/yourService.wsdl/wsdlFile
/service
The file is not a URL but a resource location.
I can't remember exactly how it looks for the file
Well, there is a valueComplete() method that
you could override. In the body of the method, call super.valueComplete()
and then release your deserializer back into the pool.
If you haven't already done so, it's a good
idea to download the source for Axis. Then you'll be able to investigate
what
Create a new class that extends org.apache.axis.handlers.BasicHandler
and override the invoke method, to do your validation. Specify the handler
in the request flow within the global configuration section of the client-config.wsdd
file. The wsdd file should be in the current director when
When one is talking about exchanging messages,
using XML, between different platform technologies and across a range of
possible transports, it's not hard to see that remote references, other
than URLs, are not likely to be supported any time soon. I'm not even sure
what it would mean, in a Web
If that doesn't work, there
are two other possibilities. Use a custom serializer for the type. If there
are invalid properties, throw a runtime exception in the serialize() method.
Or write a handler that you configure into the request chain on the client.
The handler would have to examine
Custom serializers and custom deserializers are part of
Axis. I've done a little work with them but you should try to learn about
them yourself. I'm not sure if throwing a runtime exception is the best
way to handle invalid objects, in the serializer, but it looks like it
should work.
The
Some suggestions have been made on this.
Alternatively, you might be able to add a servlet to the root context,
mapped to get called for all root context requests, and it can forward
the request to the appropriate real endpoint URL, depending on the path
in the request.
Tony
ANDREW MICONE
Or you can just change the names in the WSDL
you have. If the service is deployed as a wrapped service, then it shouldn't
matter what names you use.
Tony
Adrian Perez Jorge [EMAIL PROTECTED]
wrote on 14/12/2004 15:09:34:
You have to specify to java2wsdl the implementing class (option -i),
and
I've never seen any reference to threads
in descriptions of serializers and deserializers (Axis 1.1). Certainly,
the BeanSerializer has no special code for handling multiple threads, that
I can see. It looks as though a new serializer/deserializer is created,
from the factory, each time a type
The deserializer factory creates the deserializer.
You could have the deserializer factory set the date format object on the
deserializer, before it gets returned o Axis to use for deserializing.
In this way, the deserializer factory could maintain a list of SimpleDateFormat
objects, marking each
I don't think wrapped has any effect on the
response and only an effect on the server side of the request. The WSDL
describes exactly what goes on the wire, so wrapped is a convention for
Axis (and some other toolkits) that allows it to unwrap the request message
one level and use the child
I've never used these particular method signatures
but you will have to create an array of body elements to return. You can't
use the input elements (from the request) to get hold of the response
SOAP envelope. You need to create a new array of reponse elements, to return,
there is no point in
Have you looked at the Service constructors
that take a WSDL? This might be the best route for you, rather than using
WSDL2Java. You can build a client very simply. For example (with a service
operation that returns a list of types):
...
import org.apache.axis.client.Call;
import
I don't think Axis can dispatch the call
for you. With message style, you've told Axis that you're effectively handling
the SOAP message yourself (though Axis allows you to use one of several
method signatures), consequently, you'll have to do the dispatching.
This is my reading of the
Madeleine,
The wrapped style only refers to the parameters
to the service, not the response. Consequently, your two WSDLs produce
the same input to the same service. However, the output from the service
is presumably sending back the following XML fragment:
processResponse
processReturnthe
I'm guessing that Axis is replacing any characters
that might be confused with XML markup, hence is being
replaced with lt; and so on. I'm not sure why this wouldn't
get changed back again at the server side. Perhaps you can try defining
the parameter as a CDATA section, in your XML schema.
Kabaya,
You'll have to learn a bit about defining XML schema. Often just looking
at examples will teach you enough to get something working. There are also
some books on Web services, which include information on defining WSDL.
This is what I had to do, as I'd done no web services work up to a
Kibaya,
My guess is that you have specified the exchangeRequest
message as being of type xsd:anyType and Axis can't do anything except
assume that it is a simple type. This means that Axis is expecting no child
elements of the RequestSecurityToken element. But you have lots of child
elements. As
Axis can be used on the client, or the server,
or both. So you should have no problem. There is no real installation to
do, on the client. Just use the axis.jar file, plus some associated jar
files, that come with the distribution, and program as normal. You can
either generate client code using
You can also specify the methods to expose,
using the -m option.
Tony
Tim K. wrote on 01/12/2004 19:21:04:
Vy Ho wrote:
I wonder if you declare an interface for this service, then use
it to
generate wsdl.
This shields you from how you implement your service.
Right, that's the
Have you thought about SOAP headers? The
first response could include a header giving a new URL for subsequent calls.
On the client, a handler could check for the header and, if present, store
the value as the endpoint address. You could probably work out how to then
modify the Service object or
Nige,
Axis supports handlers that can get at the SOAP request and response on
the way out and on the way back. It supports this on the client and server
sides. You just have to configure the client and server side WSDD files
and supply classes for the handlers. Axis calls the invoke method of
Well, Axis stores cookies in the message
context, so I guess you could simply put your cookies there and they will
be picked up for transmission to the server. Axis uses two cookies, Cookie
and Cookie2. The first contains the session ID (e.g. JSESSIONID=206048F23B7AB387C5B2801622EF2C1C).
I'm not
Brian,
Thanks for sharing the solution. And for working it out yourself in the
first place!
Tony
Brian J. Sayatovic [EMAIL PROTECTED]
wrote on 01/12/2004 02:45:45:
I finally figured out how to set the targetNamespace of the wsdl:
definitions. The WSDD services have parameters, one of which
John,
I'm not sure what you were getting back from
the MessageContext but there is no HttpRequest available from the Axis
client. HttpRequests only exist on the server. Of course, your client may
be embedded in a server side object but the HttpRequest for that would
not be the one associated
In that case, as I mentioned in my first
reply, extract the cookies from the message context, in the first reply
and store them somewhere (for example, in a static variable or in system
properties) that will be available in the next call. In that next call,
add the cookies to the message context
No problem, Tim.
I think I'm going to have to worry about
this problem before too long, so I'd be interested in options. SOAP headers
are probably the way to go. If you implement the cookie functionality in
handlers, then it should be relatively easy to move to another method.
I'll probably look
I've used a custom header that incorporates
some of the WS-Security markup for sending a binary token. As far as I
can tell, WS-Security just defines syntax and semantics of security information
in a SOAP message. So you can do it all yourself, though there can be a
lot to it. No doubt the WSS4J
I don't think Java2WSDL takes account of
serializers, but I could be wrong. One of the methods of the Serializer
interface is a writeSchema method. This gets called when WSDL is automatically
generated when the ?wsdl suffix is used in the URL to a service.
It knows to do this because of type
Tim,
I've just come across the fact that the BeanSerializer
does make use of a BeanInfo class. Have you tried using a BeanInfo class
with your bean? I don't know if Java2WSDL makes use of it, but the bean
serializer seems to, at run time. Give it a go and let us know.
Tony
Just a couple of point on this.
The JavaBean specification does not requite
a getter and setter for each property. A get method implies a readable
property (in Axis terms, it means that property can be serialised). A set
method implies a modifiable property (in Axis terms, it means the property
The only other simple thing I
can think of is, instead of using an interface, as you've tried, use a
wrapper class. If the service returns the wrapper object, that only exposes
the attributes you want, but wraps the real object, then Axis will only
serialize the properties you want serialized. If
I don't think that the BeanSerializer, or
any Axis serializer, can be used on its own. It works via callbacks from
Axis, in a particular serialization context. I don't think it has an methods
that can simply serialize an object to an XML string, or an XML document.
Tony
-Original
I don't think there is any way of hiding
properties explicitly. If you use a BeanSerializer, all properties that
follow the JavaBean convention will be picked up. One way is to not use
JavaBean conventions for those properties that you want to hide. Take a
look at the JavaBean specification and
That sounds like the standard way to me,
Satish.
Tony
Koney, Satish
[EMAIL PROTECTED]
23-Nov-2004 04:53
Hi,
I created the war file for the web service. In that service I placed
the axis related jars.
Then I configured web.xml such that the request goes to
You live and learn! Thanks, Michael.
But I guess this demonstrates that they're
not really designed for stand-alone use, despite the fact that they can
be used that way. I don't know if the SerializationContext constructor
is a public API that won't change.
Tony
Michael Schuerig [EMAIL
Thanks, Paul. Implement it in what? I think
this is for listeners that can be defined in web.xml, but how do I get
hold of the global parameters defined in the WSDD file? Does Axis provide
a reference, to that information, in the servlet context?
Tony
Paul Callahan
[EMAIL PROTECTED]
You can get the original HTTP servlet request with:
( HttpServletRequest )msgContext.getProperty( HTTPConstants.MC_HTTP_SERVLETREQUEST
)
And, from this, you can get at all the information you
need about the request, including getRequestURL(), which returns the full
client request URL.
Tony
Is there a way to run some initialisation
code once, when Axis starts. I realise that I could include another servlet,
in the application, purely for initialisation, or perhaps run some static
code in a handler class, but I'd like to be able to get at options defined
in the WSDD configuration,
I don't understand this comment.
Whether you define your model in terms of XML schema, in
WSDLs, or in terms of Java classes, is irrelevant and services that use
different models will always have the problems mentioned. Standard models
for the same kinds of data would help in either situation.
The message context is available for the
life of the request (according to the documentation). Therefore, you can
call setProperty, on the message context, in any handler, to set a property
that is available to any other handler, outbound or inbound. The current
message context is passed to each
Some interesting discussion, here. I noticed
that many people seem to use WSDL generation. I don't think this is standard
(or done in a standard way) for all web service runtimes but it might not
generate very readable WSDL. One poster said something about the names
of parameters but we also add
Marcello,
I don't know about attachments, but you don't
need to use the MessageContext to add headers and body elements to the
response. The second parameter has the SOAP envelope that will be passed
back to the client and it already has a SOAP body. So you only need to
add body element to the
The method, in your service, has two parameters. The second
parameter is a SOAPEnvelope, in which to put your response. You can get
the body of the element with:
SOAPBody body = resp.getBody();
You can add a body element (this will be the root of your
response message XML) to the body using:
Anne,
I'm not sure what you mean by code-centric, versus WSDL
centric. The approach of writing the business functionality first (if it's
not already there) and then generating the first WSDL from that, before
deploying as a web service, may be thought of as code centric, but is not
tightly
I think those steps are pretty much what you need to do. If you're adding
to an existing web application, then the web.xml file will need to be modified
to declare the Axis servlet and the mapping for it. Basically, you'd need
to merge whatever a stand-alone Axis web application needs, into your
Check out the methods on the classes I've
mentioned, and the other related classes. I haven't done a lot of this
kind of work and haven't got time, at the moment, to delve further, but
if you check out the methods and look at some of the examples that come
with Axis, you should be able to work
I'm not aware that there was a standard way.
I don't think that the ?wsdl suffix on a service URL is standard
(though it may be a common convention). Our clients don't mind. Providing
they have a URL to the WSDL, it doesn't really matter what that URL is.
I'm not sure if this would work through
Does no one have, or have knowledge of, any
best practice in the web service arena?
I'm looking for a set of hints and tips, rather
than a 800 page book.
Tony
Does anyone know of a published set of best
practices, both for web services in general and Axis in particular?
I've scoured the Net
Thanks, Nikki.
We have a standard of complying to Basic
Profile 1.0, for interoperability but, on top of that, I'm looking for
generally accepted good ways of doing stuff during development of web services
servers and clients. Beyond BP 1, are there useful ways to structure WSDL
and type
Thanks, Henrik.
That's the sort of thing I'm after.
I couldn't quite work out the difference between 1 and
2, though. In 1, you are defining the messages for the service methods
and this naturally includes the parameters of the methods. In 2, it seems
you're doing the same thing again (except for
Thanks, Joe.
I've had a quick glance through the mailing
list, back a year, but couldn't find anything obvious, in the best practice
area.
In this particular aspect, I prefer to work
from Java. The way I see it, I'm developing some business functionality,
that might be usable in many ways, not
Bernard,
Axis is like any other web application. Depending on how
it is deployed, the first service call may have to wait for the application
server to create an instance of the Axis servlet and initialize it. In
addition, I guess Axis is doing something similar for each service that
is
Axis just runs as a servlet, so I can't see why you can't
have as many web applications running that servlet as you want. There's
nothing special about Axis, from Tomcat's point of view. Each web application
that defines the Axis servlet will run in a separate context, of course,
just as any
I've never done this but I don't see any
reason why it shouldn't be possible. To use the Axis bean serializer/deserializer,
the class would have to follow JavaBean conventions, otherwise you'd have
to write your own serializer and deserializer. In either case, you'd need
to register the class to
I didn't see that href before. I have no
idea why Axis is doing that. Try creating the complete header, before passing
it to the Call object, something like:
SOAPHeaderElement header = new SOAPHeaderElement( urn:uGlobalSOAPTypes,
TSecurity );
try {
SOAPElement child;
I would guess that Axis couldn't figure out
how to serialize a TSecurity instance. You'd need to define the type mapping
to Axis. This can be done with a registerTypeMapping call on the Call object,
or through the client-config.wsdd file. If the standard Axis serializers
can't handle it, you'll
The WSDL2Java tool always generates classes that can be
used on the client, regardless of whether or not you specify the -s option.
Classes that it generates for the defined types can be used on the server
or client. The locator and stub can be used on the client. I don't think
there is a way to
Christian,
It has been a long time since I worked with applets but
I think that an applet can open connections with the host that served the
applet. In this case, if the web service is hosted on the same machine
as the applet, you should have no problems in either loading classes from
the server
Sorry, I can't help any more. However, I'm
surprised that any of the commons libraries would try to install a custom
class loader.
Tony
[EMAIL PROTECTED] wrote:
It has been a long time since I worked with applets but I think that
an applet can open connections with the host that served the
Georgia,
Axis just provides the infrastructure, you can send and
return anything you want. However, if you are talking about the code generator,
WSDL2Java, then it may not give you code that supports polymorphism and
inheritance directly. You may need to write your own classes and
I've just looked at Amazon.co.uk. Up until last week, it
was quoting October 31st, this year. Now it is quoting March 2005. I've
seen earlier estimates of May 2004, so this is a book that has slipped
and slipped its target date. They are probably having to rework it to take
into account Axis 1.2.
I was relying on the O'Reilly book coming out in the next
couple of weeks. I'm now turning my attention to Apache Axis Live
at http://www.sourcebeat.com/TitleAction.do?id=1.
Has anyone subscribed to Apache Axis Live? I was wondering
if it was worth it (not that it costs very much). I can't find a
They're both good. Building
Web Services with Java has a section on
Axis, which the other one doesn't. J2EE Web Services has better
coverage of XML schema. I haven't read through all sections of each but
they both have something to offer. If you need some Axis coverage, get
the first.
Tony
I'm
By the way, J2EE Web Services
is primarily concerned with web services that conform to WS-I Basic Profile
1.0. It doesn't mention non-conformant APIs or technologies, unless it
is likely to be covered by a later version of the profile (in which case,
appendixes are used to describe them).
There
I've used the org.apache.axis.client.Service
constructors, that take a WSDL file name or URL, but haven't done the kind
of dynamic invocation that you're talking about. I still needed to know
the port name and operation that I wanted to call. However, the Service
class does have a getPorts()
Pat,
By default, Axis has a mapping, in WEB-INF/web.xml,
that specifies a URI of /services/*, to get to the Axis servlet
(and, thus, to the services). This is the path below the context root.
It looks like your context root is taskServices, but I'm not
sure what mapping you have for the Axis
It may be related to IWSState not following
Java Bean conventions (get and set methods for each property). I don't
know why a types section wasn't generated, though, to define the
types in the tns1 namespace.
Tony
Greetings.
I am using java2wsdl to generate
wsdl for my web service.
I have a
Raiden,
I'm not sure I understand what you really
want, even after reading your other posts. As I understand it, using a
jws file allows easy deployment of simple services (though I guess you'd
need to include any support classes that your service might need into the
WEB-INF/lib directory of the
Chris,
I'm still new to this myself but here's my
take on it. Axis provides a servlet, which is deployed in an application,
through which all HTTP request for a service go. From Tomcat's (or any
other application server's) point of view, it's just another web application.
If you have
That's good news, Chris. Would you like to
share some of the problems and their solutions? If others are doing the
same kind of porting, they might be able to avoid the same problems that
you had.
Tony
Thanks to all that replied to my messages. I
finally managed to get my app
ported over and
Chris,
Try posting your web.xml here. It sounds
like it's screwed up; maybe someone here can spot the problem.
Tony
I keep getting taglib errors. It says that taglib
must match Doctype root
null. I'm not using any jsp's.
Chris
Chris,
From your posts, it seems as though your
service is working and the client is getting a response (even though it's
an empty response). The only problem is that you aren't able to get any
log messages out of your code and it appears to be ignoring your various
code changes (including
Morten,
Have you told Axis where to find your WSDL?
It's a setting in the WSDD file. If you haven't told it, it will generate
the WSDL and this may be what you are seeing.
Tony
Hi,
Does anyone know why the WSDL used to feed Axis' WSDL2Java' differs from
the WSDL returned by the final online
Hi Morten,
The service element, in the WSDD
file (deploy.wsdd or server-config.wsdd, which ends up holding all the
deployed WSDD elements anyway) allows a sub element wsdlFile that
specifies the location of the WSDL file for the service. If this is present,
Axis, won't generate the WSDL.
If the
Well, I can't see how it could be different
from any other client, although I'm not sure how you'd specify a client
WSDD, if you need to. The fact that the client is also a web service should
not matter at all.
Tony
Hi,
Somebody could say me what are the steps to do a WebService which call
Sami,
You stated that you used the --server-side
flag when running WSDL2Java. Did you use the generated server skeleton
to implement the web service (on the server side)? If you were just using
the generated client side classes, then the service has always returned
GetStatusReturn, you
The Axis servlet loads web services on request,
depending on the scope. As you have session scope, the web service class
will be instantiated once for each session. So the first call, in that
session, will take longer than subsequent calls.
I'm not aware of any configuration that will
cause Axis
Steven,
I'm not sure exactly what is going on here,
as I've never used Java2WSDL, yet. However, it seems to me that the tool
would not have much information to go on, for the Bean class, and probably
wouldn't be able to deserialize or serialize it. The Bean class simply
has one private field,
Branko,
The Axis servlet is just that, a servlet,
and so creates a thread for each request. So request scope should be identical
to a thread scope.
If the instantiation is expensive, why do
you want to do anything other than application scope? Session scope is
in the middle, instantiating the
If you copy and pasted this bit of XML, then
you have an error. The sequence element doesn't have a closing tag and
there are two closing tags for the extension element. However, I would
have expected this to show up as an error when running WSDL2Java.
Tony
I'm trying to factorise my wsdl
I wouldn't expect session scoped services
to get created for each thread, since they need to stay around for the
life of the user session (which may span multiple requests). Request scope
seems to be the one you want. Servlets create a new thread for each request
and, with request scope, each
Peter,
I don't have any experience with VB for accessing
Web services but others may be better able to answer your question if you
report what the actual problems are. It doesn't work is not
a useful symptom description.
Tony
Jochen,
I've only read a little about sessions but
I think you have to deploy the SimpleSessionHandler on the client's request
and response flows. I don't know if you need to do this on the server.
Also, did you define the handler type session before refering
to it in your requestflow?
I think
Hi Jochen,
From the little I've read, you need to deploy
the session handler on the client side also. I've never done this but I
believe you can use a WSDD file on the client side to specify request and
reponse handlers, so I guess this is where you need to do it. If it already
works for one
Jochen,
Did you include the transport pivot handler
that I think is specified in the default client-config.wsdd? That's the
bit that actually sends your request. The client-config.wsdd default file
is in the axis.jar file, in the org.apache.axis.client package.
Tony
Thats not the problem.
Jochen,
I suspect that you would have to keep the
client JVM alive and make all service calls from that JVM, in order to
maintain the session across different service calls. Using the HTTP sessions
might work better, though I doubt it. Other than that, you'd probably have
to write your own
OK, Jochen. Following your reply, I had a
quick look at the Axis source and it seems as though a new AxisClient is
created for each Service object. The session ID is stored in the AxisClient
so I guess you'd need to use the same Service object for all service calls.
This may not be normal
Hamish,
I've just been made aware of Apache XML Beans.
It seems one can compile XML Schema into Java classes that can access an
underlying DOM in a Java friendly way. Maybe you can access the incoming
SOAP body using XML Beans, create your new Java objects (with XML Beans
generated from your
Well, you seem to be making progress, Jochen.
I'm surprised that reusing the engine or
service didn't work. I was looking at the 1.1. source, maybe you're using
1.2, which could be different. According to the Building Web Services
with Java book, the session ID is stored in the Message Context,
Sushil,
I've only used JNDI once, with Tomcat, so
am not too sure about the details. I also don't have Tomcat on my machine
at the moment. However, you can define resources in the Tomcat configuration
files, in terms of a JNDI name and a class name. Tomcat will instantiate
the class and bind it
Thomas,
To return the WSDL file that you used to
generate the service skeleton, you have to specify the wsdlFile
element in the deployment descriptor for the service (WSDD).
Tony
Hello,
I think I found a bug or I dont know?
When I call my Service, with
It's just a simple element, under the service
element, Thomas. For example,
service name=myService ...
...
wsdlFilemyResources/myService.wsdl/wsdlFile
...
/service
There is a little bit more description in
the Axis Reference Guide under Individual Service Configuration.
Tony
Hi Tony,
Sorry, Thomas, I have no idea why the generated
WSDL is misleading. I'm fairly new to Axis so there could well be a good
reason that I'm not aware of. I think it uses the same code as Java2WSDL
does, so you could try experimenting with that tool (part of the Axis distribution)
to find out
I'm not too sure about using JNDI on the
client side. If you are using client code in a J2EE application, running
on Tomcat, then you should be able to specify a JNDI resource, in the Tomcat
configuration, that defines a stub class (or factory class) for your web
service stub. But if your client
Apologies for the length of this but
I wanted to include WSDL and generated code to give a complete picture.
I've been trying to get simple Java
client code generated for a service that has no input but does have some
output. Defining an input message with a part that has an empty element
1 - 100 of 101 matches
Mail list logo
