RE: RPC and Doc/Literal...
First, read this if you haven't: http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-wsstyles.html Bottom line is that you can't do doc/literal with Axis 1.1. We're currently using Axis 1.2 alpha builds to publish doc/literal Web services. It goes something a little like this: Build XML Schemas (by hand, using XMLSpy 2004). Build WS-I compliant WSDL (by hand, using XMLSpy 2004 and SOAPScope 3.0). Axis 1.2 WSDL2Java to generate: a) server side web service skeletons b) Java data objects c) deploy.wsdd snippet d) client side proxy stubs Sounds easy, right? Just remember Google, Bugzilla, Red Bull, and Starbucks are your best friends. Good luck. -Jon -Original Message- From: KimJohn Quinn [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 2:48 PM To: [EMAIL PROTECTED] Subject: RPC and Doc/Literal... Everyone, Quick question, currently we are using RPC for building WebServices that interact with .NET (.NET is the client, Axis is the Server). We can do this with no problem including using the wsdl to and from tools. We are now trying to generate those same objects for doc/literal but without much success. Are there any good resources to reference for doing this? Running into problems with the encoding and the namespaces mostly. Thanks. KimJohn Quinn [EMAIL PROTECTED]
RE: RPC and Doc/Literal...
In most of our experiments all of the doc/lit WSDL emitted by Axis 1.2a's java2WSDL tool was either invalid or not WS-I compliant. I define invalid to mean not immediately usable for a client to bind to and successfully invoke the service. I define not WS-I compliant to mean failing Mindreef SOAPScope 2.0's (recently 3.0) WS-I WSDL compliance checks. We also ended up defining custom XML schemas for our XML datatypes, and then importing those schemas into our WSDL to include the datatypes in our WSDL messages. This was the final decision that ruled out java2WSDL as an option for us. If WS-I compliance is not a requirement, and you can live with the Axis XML datatypes automatically generated and included for you in the emitted WSDL's type section, I would suggest experimenting with the latest Axis 1.2 CVS. But it is important to realize that in the big picture you are essentially deciding to either a) model your Java and then work backwards (java2WSDL) to get your WSDL, or b) model your XML and then work forwards to generate your Java object model (WSDL2Java). Regards, -Jon -Original Message- From: Saravanan Markandeyan [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 5:21 PM To: '[EMAIL PROTECTED]' Subject: RE: RPC and Doc/Literal... Is the hand built WSDL required for this to work. I have a huge interface that I want to expose as a service using doc/lit and was wondering, if I picked up 1.2 and used the JAVA2WSDL and WSDL2JAVA method, could I get the doc/lit to work. Tried with 1.1 for a while and gave up. Has anyone tried the JAVA2WSDL and WSDL2JAVA process to do doc/lit services? Any input would be greatly appreciated. Thanks in advance -Saravanan
RE: Axis and Basic Profile 1.0a
A really great WS-I WSDL/XSD testing tool is Mindreef SOAPScope (www.mindreef.com). We successfully used their 2.0 release to ensure that our doc/lit WSDL/XSD was WS-I compliant before running Axis 1.2 alpha wsdl2java against it. Their current release, 3.0, touts further WS-I testing capabilities: integration with the WS-I test suite and automagic WS-I conformance report generation. We just got 3.0 in house, however, and have yet to play with these new features. -Jon -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 9:33 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Axis and Basic Profile 1.0a http://www.ws-i.org/implementation.aspx --- Tony Opatha [EMAIL PROTECTED] wrote: 1. Which WS-I testing tools can be used to ensure that the WSDL/XSD are clean? 2. What kinds of test coverage does the WS-I testing tools have for checking SOAP request and response messages?
RE: Doc/Literal support in axis
Hey gang,
Time for my two cents. We've been using Axis 1.2 alpha builds since
November '03 to build WS-I compliant document literal web services. How is
this possible? Here's our cookbook:
1) Create XML schema in Altova XMLSpy that defines the datatypes that the
web service is to exchange.
2) Define a second XML schema in XMLSpy that defines Request and Response
types for each operation you wish to define. This second schema imports and
references that types defined in schema #1, thereby wrapping your
datatypes in additional request and response elements.
3) Create document literal WSDL in XMLSpy that imports schema #2, referring
to the Request and Response types in the WSDL message parts.
4) Run WSDL through a WS-I conformance test tool such as Mindreef SOAPScope.
5) Run Axis 1.2 alpha WSDL2Java, either by command line invocation or as an
Ant task on the valid WS-I compliant WSDL.
An example:
java org.apache.axis.wsdl.WSDL2Java -o .\build\wsdl2java-output -a -s -t -T
1.2 .\resources\MyDocLiteralService.wsdl
6) Take WSDL2Java deploy.wsdd deployment descriptor and paste it into a
server-config.wsdd. Compile code, deploy service.
Some notes:
a) Why the two schemas? Well, we don't like defining Request and Response
wrapping types in the same schemas we use to define our core domain
datatypes. We use the two separate schemas to abstract the SOAP
request/response wrappers from their payloads.
b) To wsdlFile or not to wsdlFile? It's a trade off either way. If
you DO choose to specify your own wsdlFile in the deployment descriptor,
you then have to worry about the following:
- Included schemas cannot be referenced on a local file system, as they
most likely were during WSDL2Java processing. You must not actually host
your schemas somewhere and refer to the with URLs.
- Endpoint location URLs need to be modified per deployment, since you
don't want your production WSDL to reference localhost:8080.
If you do NOT choose to specify your own wsdlFile Axis will include all of
your nice, neat XML datatypes defined in multiple schemas DIRECTLY into your
WSDL types element when it autogenerates the WSDL. If this is not a
showstopper for you, the Axis autogenerated WSDL might possibly be invalid
or not WS-I compliant - make sure you inspect it carefully.
Either method creates a burden for us developers.
c) Target namespaces: we've had success defining the WSDL + domain schema +
wrapping schema in either the same target namespace, or each in their own
namespaces. It's up to you.
d) Namespace to package mapping: this is a skill acquired through trial and
error. To have WSDL2Java generate code in specific packages, you need to
specify namespace to package mappings. We automate the whole mess through
Ant by specifying a mapping file:
axis-wsdl2java
all=true
output=${app.build}/wsdl2java-output/
verbose=true
serverside=true
testcase=true
noWrapped=true
namespacemappingfile=${app.build}/properties/nsmappings.properties
typemappingversion=1.2
url=/resources/MyDocLiteralService.wsdl/
In any case, since you are essentially generating the Java types (read:
JavaBeans, value objects, whatever you call them) you will need your web
service implementation to work with from your schemas, you will have to have
some logical manner of taking the generated code and including it into your
codebase. We're paranoid that some developer is going to regenerate from
WSDL and hose our existing codebase, so our build scripts dump WSDL2Java
output into a neutral directory for us to manually copy into our src tree.
philosophy
To me, document literal services implies a whole new way of thinking about
web services - both from the development perspective and the architecture
perspective. No longer are we using java2wsdl to simply provide a RMI over
http - the mentality of take your Java class and expose it as a web
service should be combated wherever encountered.
The WS-I religion is based around coarse-grained document oriented web
services. I hand a web service a document, and it hands me one back after
performing some processing (not necessarily synchronously, either - it is
possible to do asynchronous SOAP messaging over HTTP!). If you think of it
from that perspective, your entire mentality towards what problems they can
actually solve changes - in addition to how you build them.
/philosophy
Hope this helps guys. Pass it on.
-Jon
-Original Message-
From: Marepalli, Somesh [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 16, 2004 9:25 AM
To: [EMAIL PROTECTED]
Subject: RE: Doc/Literal support in axis
If you have taken the pains to hand craft a WSDL and make it WS-I
compliant, you might as well specify it in the .wsdd file with the
wsdlFile tag. That way, you can override the generation of the WSDL
from service by Axis...
-Original Message-
From: David Bell [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 6:35 PM
To: [EMAIL PROTECTED]
Subject: RE: Doc/Literal
RE: Web Service Security - what's the best way to achieve it?
No easy answer, as it all depends on the deployment environment that you need to support. Who is consuming the service? Is it a portal? Do you own the portal server that is consuming it? What about the service itself? Do you own the whole server? Where are they located? Are they both on a VPN? What about throughput? Is your service deployed in a clustered, load balanced environment? All of these things factor in, I'm afraid. It's a nasty, nasty problem domain right now. plugWe're using WSS4J to apply WS-Security 1.0 compliant digital signatures to SOAP messages,/plug but that's because we need that level of security in our deployment environment. Food for thought. -Jon -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 10:37 PM To: [EMAIL PROTECTED] Subject: Re: Web Service Security - what's the best way to achieve it? http://ws.apache.org/ws-fx/wss4j/ --- [EMAIL PROTECTED] wrote: Hi people, I am considering two different ways of using Certificate based authentication of a client connecting to our Web Service: 1. Certificate is contained in the HTTPS request. I intercept the Request in my Web Service, get the Certificate out of it, and do the authentication. 2. Certificate is contained in the signed SOAP Envelope. My Web Service (a Handler) gets the SOAPEnvelope, gets the Certificate out of it, and does the authentication. Which one of these options is the better one, what do you people think? Best regards, Zoltan Schreter Nokia/Finland = Davanum Srinivas - http://webservices.apache.org/~dims/
RE: Doc/Literal support in axis
Jim, Nelson, all, So, now that we all agree that SOAP is just a framing protocol and processing model, and XML Schema is that de-facto type system for defining interoperable data types... The $50,000 Question: What problems can we solve with SOAP based Web Services? A colleague of mine has suggested three criteria for when to use SOAP, in light of WS-I and past experience. These are by no means definitive, and open to discussion. 1) Functionality or Data to be exposed must useful across many types of systems. (The need for interop) 2) The data being returned can be expressed as a document conforming to an XML Schema. (WS-I) 3) The size of the documents being returned are relatively small. (The cost of XML serialization, much less XML Signature or Encryption) The $5000 Question: Should we not have native support in a programming language for XML Schema? Why all this mapping nonsense? To quote another colleague of mine: the W3C really created a monster with XML Schema. It's far more powerful and expressive than most OO type systems like C# or Java. One of the Axis developers, Richard Kellogg I believe, posted this paper awhile ago concerning the mismatch of XML Schema and OO languages. It's a good read. Realize that Axis is not schema aware out of the box, hence the Axis-Castor integration effort. Check it out if you have not already - it's in Axis CVS. http://www.cl.cam.ac.uk/~gmb/Papers/vanilla-xml2003.html Food for thought. Is it not an interesting time to be a developer? -Jon Nelson Minar wrote: This seems to be the central quesiton of web services design. I know a lot of people are thinking about it and it's driving a lot of technology development. It's latent in the WS-I spec. But I haven't seen so much clear writing about WS interface design directly. Jim Murphy wrote: Halleluah! I'm just starting to blog about that! IMHO, Web Service Message design has been an afterthought of the spec working groups that comprise your typical WS stack. You need to know a lot of grunge to design an easy to consume service: 1. XSD - what to use and what to avoid is the hard part especially when modeling non trivial data. What will axis do with a .NET DataSet, or collections or... 2. WSDL - WSDL 1.1 is chaos. Hopefully WSDL 2.0 will improve that but it looks m ore complex not less to me though several problem have been addressed. There is the question of migration from WSDL 1.1 to WSDL 2.0 as well. Not exactly straight forward. 3. Various language bindings. What will you interface be like to code against in the foo language?
RE: Doc/Literal support in axis
Dennis Sosnoski wrote: As I've said before, I think it's unfortunate that JAX-RPC/Axis is coming from such a strong rpc/enc orientation. I think an API for doc/lit services can be *much* simpler than the current mess of stubs, ties, wire, duct tape, chewing gum, etc. Is this not where everyone came from? Glue 4.1.2 has it's own doc/lit problems. .Net might be the only SOAP stack that nailed it with doc/lit support out of the box from day 1, and even they have interop problems when it comes to XSD - C# type mappings. WS-I, for me, was a huge wake-up call. It shifted not only my how to develop SOAP Web Services mentality, but my why we need SOAP Web Services mentality as well. -Jon
RE: Doc/Literal support in axis
Reading that Dennis, I actually think we're in the same camp. :) Thanks for taking the time to re-illustrate your position (I missed it in earlier threads). I have NEVER understood why XML Schema went as far as it did - extending simpleTypes to restrict values based on regular expressions seems to me to be out of the scope of a type system. Given that not many Schema - OO type mapping tools currently even support XML Schema to that level, we typically stick with plain-jane complexType, element, and attribute declarations. So far it's proven a safe strategy for WSDL2 toolkit iterops. Maybe we'll see an XML Schema Lite in the future? -Jon -Original Message- From: Dennis Sosnoski [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 5:29 PM To: [EMAIL PROTECTED] Subject: Re: Doc/Literal support in axis Anderson Jonathan wrote: ... The $5000 Question: Should we not have native support in a programming language for XML Schema? Why all this mapping nonsense? That appears to be the bold new computing direction of the month for Microsoft. I think it's a bad idea. flameSchema is a design-by-committee monstrosity that makes the old Ada programming language look clean by comparison, combining the worst features of SQL and VB. Why would anyone want to bake it into a programming language?/flame To quote another colleague of mine: the W3C really created a monster with XML Schema. It's far more powerful and expressive than most OO type systems like C# or Java. Schema does a decent job of letting you define XML structures. It also has a fairly nasty hodgepodge of types that, while awkward, at least allow you to express the intent of what you want to see in different components of your XML. Then it adds a truly bizzare set of ways to get down to the detailed level of what each component should be - things like the multitude of facets, regular expression matching, extensions of restrictions and restrictions of extensions, etc. What makes the latter set of detailed data descriptions of little use in practice is that there's no way to condition the values permitted for one attribute or element on the values (or even presence or absence) of another attribute or element. Sure, you can do really complex descriptions of simple text values in schema - there's a 100-page ISBN number schema I use as a look-at-that example in training classes, for instance - but why would you want to? For real applications schema validation is going to be prohibitively expensive once you get into the complex rules, and most applications require more intelligent data validation than schema can support anyway. My recommendation for anyone writing schemas is to use it for structure and basic data types, but stay away from the facets and such unless you really have a need to use them for descriptive purposes... and then don't write your program on the assumption that the facets will be enforced, for two reasons: (1) if someone changes the schema your code will break, and (2) schema validation will probably be turned off when you're deployed. - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Development Support http://www.sosnoski.com Redmond, WA 425.885.7197
RE: Doc/Literal support in axis
Awesome. I was aware of TREX, but not of RELAX or RELAX NG. I'd honestly forgotten there were alternatives to W3C XML Schema, which is most likely an unfortunate side effect of having my head down in the SOAP bubbles for too long. So the question really, as you pointed out, is toolkit support. Anybody know for certain if JAXP allows for pluggable schema languages, or are did Sun standardize on W3C? -Jon Joseph Dane writes: we already have one of these: http://www.relaxng.org/ or maybe you meant maybe we'll see support for other schema languages in our WS tools in the future, in which case I wonder the same thing.
RE: XmlBeans and Axis? [Re: Doc/Literal support in axis
The only problem with decoupling the SOAP processing layer from the Java data binding layer is the implications such an approach has on intermediary node processing. Almost every SOAP stack I've seen implements SOAP intermediary nodes as some sort of interceptor (Axis handlers, JAX-RPC handlers, .Net WSE filters, Glue filters). The problems is that intermediary nodes can change the content of the SOAP envelope, plain and simple. This really complicates that SOAP XML data binding issue. Intermediary node implementations need access to the SOAP header information at the very least... any type of security processing (Web Services Security XML Signatures or XML Encryption, for example) requires access to the entire envelope, typically as a DOM. Case in point: the WSS4J Axis handlers HAVE to marshall/unmarshall to DOM Level 2, given that the WSS4J XML-Security toolkit of choice (Apache XML-Security) operates on DOM Document instances. This flies in the face of Axis' SAX based data binding approach. Seems to me that a) intermediary nodes are very significant when you're dealing with the SOAP processing model and b) they could potentially have their own unique data binding requirements in addition to the data binding approach the actual service implementation uses. I'm very anxious to see how the JAX-RPC 2.0 JAXB 2.0 marriage handles this problem. -Jon -Original Message- From: Jim Murphy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 2:21 PM To: [EMAIL PROTECTED] Subject: Re: XmlBeans and Axis? [Re: Doc/Literal support in axis I favor the approach this suggests: Make the SOAP stack an XML delivery and minimal SOAP processing engine and leave XML-Java type translation to another layer. Chose Castor, XmlBeans, JAXB 1.0, 2.0 whatever. The choice is dictated by how I want to work witht he XML recognizing that the XML is really what I'm working with! Jim Murphy Mindreef, Inc. Aleksander Slominski wrote: Dennis Sosnoski wrote: Long term it's clear that real data binding support needs to be integrated into the SOAP framework. JAX-RPC 2.0 has the stated intention of doing this using JAXB 2.0. Right now you can kind of do this with Castor in Axis, if you're willing to go through enough trouble (I've just spent 3 days getting an Axis-Castor example to work properly, as opposed to less than a day using the hideously complex JAX-RPC RI for doc/lit, less than a day with Axis rpc/enc (even though I had to try three different versions of Axis to find one that worked), and less than a day with Axis doc/lit (again requiring trying three different versions of Axis before finding a - different - one that worked). The current Castor in Axis support is basically just grafted in, to, so you pay a high price in performance. hi, do you know if anybody tried to add support for XmlBeans (http://xml.apache.org/xmlbeans/) to AXIS? we have XmlBeans integrated in WS/XSUL (aka XSOAP4) which is document style based in its core so it needs some kind of data binding. XmlBeans works very well in this capacity as it has a very extensive support for XML Schemas (AFAIK there is nothing open source that has better support ...). thanks, alek
RE: XmlBeans and Axis? [Re: Doc/Literal support in axis
Jim Murphy wrote: I don't get why this is a problem. Say I have a handler that wants to transform a request in some way (decrypt, remove a Header whatever). Isn't that just consuming one stream and producing another? If it wants to consume one stream map that to Java using some marshaling/binding mechanism to operate on then generate the result stream based on that why would it matter? Why wouldn't a very thin Axis working with several Java binding/marshaling layers be a compelling approach? Problem is, I have yet to see a SOAP stack that works this way. Consuming one stream and producing another implies that each intermediary node would potentially have to go from XML-Java-XML before the call got passed to another the next intermediary node. This would certainly allow each node to use it's own data binding schema - but think of the serialization performance hits! -Jon
RE: Doc/Literal support in axis
There are a bunch of doc/lit specific bugs that have been fixed in both the straight 1.2 alpha release and the latest Axis CVS. Originally we were using the straight 1.2 alpha release - then we started playing with WSS4J and have been using the build from Axis CVS that they are using ever since. As to your template WSDL suggestion... not sure what the best solution is there. The way the Axis code works right now the right way to do it is to let Axis generate the WSDL for you once you've published your doc/lit service - Axis will then fill in the appropriate endpoint URL. It is only because we don't trust Axis right now to emit correct WSDL that we end up in wsdlFile hell, having to host our included schemas and changing our WSDL endpoints per deployment. One can also argue that if you've gone through the trouble of putting a lot of comments into your WSDL then you would want to make use of wsdlFile as well. The bigger problem though is that WSDL requires service endpoints to be in the WSDL AT ALL. I'm not sure if this is being addressed by either WSDL 1.2 or WSDL 2.0. -Jon -Original Message- From: Nelson Minar [mailto:[EMAIL PROTECTED] Sent: Thursday, March 18, 2004 3:33 PM To: Anderson Jonathan Cc: [EMAIL PROTECTED] Subject: RE: Doc/Literal support in axis I was looking again at your excellent cookbook for doing doc/literal in Axis and had a couple of followup practical questions: You specify using Axis 1.2 alpha. Is there any hope with Axis 1.1? And do you mean the alpha release or the latest Axis CVS? You mention that if you use wsdlFile, Endpoint location URLs need to be modified per deployment, since you don't want your production WSDL to reference localhost:8080. I find the hardcoded URLs are a really frustrating part of working with WSDL. It would be easy to add a simple templating system into Axis to smooth this over, just load a template WSDL and rewrite it at runtime to have the right URL. Is this a good idea?
RE: Doc/Literal support in axis
I second that suggestion. :) -Original Message- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 2:08 PM To: [EMAIL PROTECTED] Subject: RE: Doc/Literal support in axis When starting with WSDL, what that really menas if that you should be starting with a WSDL portType definition (plus it's referenced message and types definitions) -- not with a complete WSDL document including binding and service elements. The binding information should be specified during packaging and deployment. The service element should be generated by the runtime when you deploy it. You definitely don't want to hardcode the endpoint address. My suggestion is that we fix Axis so that it appends the binding and service elements to existing portType definitions. Anne At 12:56 PM 3/19/2004, you wrote: There are a bunch of doc/lit specific bugs that have been fixed in both the straight 1.2 alpha release and the latest Axis CVS. Understood. This is really frustrating if you're trying to use Axis 1.1. A beta of Axis 1.2 that passes all tests would be very welcome. As to your template WSDL suggestion... not sure what the best solution is there. I think a solution is needed. Most of the web services developers I talk to tell me two things: use document/literal and start with the WSDL and generate server code from it. Apparently this is the path to stability. It makes sense to me, too - you write the interface as the center of your system. The bigger problem though is that WSDL requires service endpoints to be in the WSDL AT ALL. I'm not sure if this is being addressed by either WSDL 1.2 or WSDL 2.0. This is important for user convenience - you just point the client at the WSDL and you're done. For production deployment this is the right thing. For testing, most clients do support a way to say use the proxy from this WSDL, but use a different endpoint for the service. A template mechanism would also solve the what's your hostname problem. It seems pretty random to me whether Axis thinks its hostname is http://foo/ or http://foo.example.com/ ~~ Anne Thomas Manes VP Research Director Burton Group
RE: Doc-Style Web Clients
I heard grumblings awhile ago that Microsoft might be dropping support for DIME in lieu of some WS-I discussions concerning attachments. Might wanna try googling around for more information, but this probably won't occur until the next .Net/Vis Studio release anyway. -Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 8:12 AM To: [EMAIL PROTECTED] Subject: AW: Doc-Style Web Clients How about passing the whole document as a single string parameter of a doc/literal web service? Is there a better performance to expect when using SAAJ? What i don't like about SAAJ: .NET requires the use of DIME format. I don't know all platforms or toolkits used to develop the potential clients and so i don't know if DIME is supported by them. The first time i heard of DIME was when i was looking into SAAJ. Is DIME widly supported? Thanks Thomas -Ursprüngliche Nachricht- Von: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 25. März 2004 14:03 An: [EMAIL PROTECTED] Betreff: Re: Doc-Style Web Clients Use the SAAJ API. At 08:38 AM 3/25/2004, you wrote: Hello Guys, Can we develop doc-style web service clients? When I say doc-style web service clients, I mean a client which calls a web service directly without the involvement of Axis serialization wherein marshalling of function calls to XML is circumvented. What I want to do is, I have my Document constructed which I want to embed in a SOAP envelope and call the web service. My web service processes the Document and I dont want Axis to marshall the function calls to XML. P.S: My web service is implemented in .NET TIA, Vivek _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ~~ Anne Thomas Manes VP Research Director Burton Group
RE: What are the advantages of Message style web services?
Anne, Any idea if and/or when JAX-RPC will standardize this? So far it seems like an Axis specific thing - has anyone seen it elsewhere? (Glue? CapeClear?) Would it not make sense to give the developer the choice of either using the XML - Java data binding facilities that a particular JAX-RPC implementation provides OR allow them to deal with the document directly? And let's not forget about JAX-RPC handlers either - I want to be able to use either use the data binding facilities or handle the document in either the client, handlers, or service implementation. Your thoughts? -Jon -Original Message- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Monday, April 05, 2004 1:07 PM To: [EMAIL PROTECTED] Subject: Re: What are the advantages of Message style web services? If your application prefers to work with the information in it's native XML format, then you want to use the message style. For example, if your application simply wants to process one portion of a large document and then send it along in a workflow, it doesn't make sense to convert the entire document into Java objects, only to convert it back into the XML document again. You also might want to use the message style for one-way or asynchronous processing. Anne At 04:00 PM 4/5/2004, you wrote: Hi Axis Community, Could anyone shed some light on real advantages of Axis Message Style services compared to passing in and out complex beans? Any help will be deeply appreciated, Ranjith Pillai. ~~ Anne Thomas Manes VP Research Director Burton Group
RE: microsoft discontinuing dime spec?
Anne, Monika - Check out Rich Turner's blog entry: http://blogs.msdn.com/richturner666/archive/2004/03/10/87602.aspx Thankfully, the Microsoft guys involved with Indigo blog pretty regularly. Makes it easier to read the tea leaves. :) Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 13, 2004 4:44 PM To: [EMAIL PROTECTED] Subject: RE: microsoft discontinuing dime spec? Microsoft plans to support XOP/MTOM in the future. XOP/MTOM is being defined by the W3C XMLP working group, and it will [most likely] be the standard mechanism used to pass binary data with SOAP messages in the future. For the moment Microsoft is still supporting DIME, but they will phase it out once XOP/MTOM gets finalized. Please see my blog for a description of XOP/MTOM. http://www.burtongroup.com/weblogs/annethomasmanes/archives/cat_ws_status.ht ml Anne -Original Message- From: Monika Gorkani [mailto:[EMAIL PROTECTED] Sent: Monday, April 12, 2004 7:32 PM To: [EMAIL PROTECTED] Subject: microsoft discontinuing dime spec? Has Microsoft discontinued it's work with the dime spec. Has anyone heard about this? Is axis going to continue supporting dime? Thx, Monika __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html
RE: JAXB vs Axis generated classes
1. What are the benefits of using Axis generated classes as against using standard like JAXB? More robust XML Schema support is my guess - but I'm fuzzy on which Java - XML data binding engines support what. 2. Will JAXB generation be included as part of the next version of JAX-RPC spec? Not sure about the specifics, but JAX-RPC 2.0 looks like it will be tied to JAXB 2.0. Check out: http://www.jcp.org/en/jsr/detail?id=224 3. Has anyone tried to compare the performance using Axis generated classes as against using JAXB? Not to my knowledge. See Dim's rant for some possible insight into the current state of performance metrics: http://marc.theaimsgroup.com/?l=axis-userm=108186602814158w=2 I have got Axis to work with JAXB. Cool! The problem is when I get my response I see that it gets recorded by the SAX2EventRecorder in MessageElement. Is it possible for to use JAXB to read from the stream instead of using the using the event recorder to record to a string and then using jaxb to construct an object tree? Might want to try posting to Axis-Dev. They might be very interested in what you're trying to do. Regards, Jonathan Anderson Booz Allen Hamilton
RE: Need suggestions on web service interlope and design
Henrik, Axis 1.2 beta is out... http://archive.apache.org/dist/ws/axis/1_2beta/ Though if you're the adventurous type you can always pull straight from CVS and build it yourself. And yes, we're ALL struggling not only with building WS-I compliant SOAP services, but WS-I complaint SOAP services that fit together into some sort of loosely coupled, scalable, and gasp actually useful Service Oriented Architecture. Somebody should really open a Service Oriented Architect school. :) Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: HG [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 10:20 AM To: [EMAIL PROTECTED] Subject: Re: Need suggestions on web service interop and design Anne, Thanx for the fast info..Just the thing I needed. Now, the task doing schemas first, makes sense..That way you won't get tempted to expose platform specific stuff..Great. Maybe for once in a lifetime I should follow the .NET guides and do things the MS way :-) I can see that Axis 1.2 is alpha...Anyone knows of the beta or final release plans..? Best regards Henrik - Original Message - From: Anne Thomas Manes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 3:38 PM Subject: RE: Need suggestions on web service interop and design Henrik, The WS-I Basic Profile disallows the use of SOAP Encoding. It allows only Document/Literal and RPC/Literal. Technically, WS-I BP doesn't *require* support for RPC/Literal, though. Microsoft fought long and hard to exclude RPC-style from the WS-I BP, but they lost that vote. In any case, Microsoft does not support RPC/Literal, and my guess is that they will never support RPC/Literal. (Please note, though, that the JAX-RPC specification requires support for RPC/Literal.) If you want to design for interoperability, you should use Document/Literal. Axis 1.2 provides much better support for Document/Literal than previous releases. I suggest that you follow the .NET guides and define your schema first -- then generate your beans from the schema. This approach ensures that you won't attempt to expose Java collections through your WS interface. For best interoperability, your interface should consist of simple types, arrays (defined using minOccurs/maxOccurs), and complex types defined as sequence structures of simple types, arrays, and/or sequence structures. Anne -Original Message- From: HG [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 3:43 AM To: [EMAIL PROTECTED] Subject: Need suggestions on web service interop and design Hi all I have developed some WebServices using Axis...nothing big...just a couple of examples serializing beans and so between a java (Axis) server and a java client...however...now a project is arising where web services is going to be used in large scale... and to add even more complexity..the web services deployed must be consumable by other platforms...first case is .NET I have read inteop guides in both camps, ie Java/Axis/J2EE and .NET..In the .NET camp they favor one style of messages and claim that this is according to the WS-Basic profile...So it makes me wonder...how is Axis support for this style (can't remember if it is doc/literal or rpc/literal) ? In the .NET guides, thet also say that one must define the schemas first? Why...? Because a schema can be understood by both sides? or to define the message structure as they seem to favor message style instead of rpc style? The primary goal of the web servcices developed is to be consumable by many platforms...first two targets is .NET and Axis...more coming Any thoughts, ideasAnne, please...you seem to have done a lot in this fields.. Best regards Henrik
RE: Need suggestions on web service interop and design
David, you may be understating the problem a bit. Building interoperable, WS-I compliant SOAP services with Axis is a little involved. See: http://marc.theaimsgroup.com/?l=axis-userm=107945370506044w=2 Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: David Thielen [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 12:18 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Need suggestions on web service interop and design Speaking for myself (and I think lots of others), while a tutorial would be wonderful, if you could just tell us what method to use to create a server using java under access that .net can access - that's 90% of what we need. Especially if one of the existing axis examples implementes that method - then you can just point at that. thanks - dave -- Original Message -- From: Nelson Minar [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 14 Apr 2004 09:01:42 -0700 HG writes: I can see that Axis 1.2 is alpha...Anyone knows of the beta or final release plans..? There is a beta, but for some inexplicable reason it's not visible on the site. You can find it here: http://archive.apache.org/dist/ws/axis/1_2beta/ I'm having good luck with it. Anne Thomas Manes writes: For best interoperability, your interface should consist of simple types, arrays (defined using minOccurs/maxOccurs), and complex types defined as sequence structures of simple types, arrays, and/or sequence structures. A really clear example on how to build an Axis server this way, along with client examples in the major platforms, would be a tremendously useful tutorial. I've been toying with the idea of writing one myself but have been too busy. I'm pretty sure xml.com would be glad to publish it.
RE: Need suggestions on web service interop and design
Between you, me, and Axis User :) - amidst my searching to grasp the SOAP based SOA big picture, I'm starting to feel as if SOAP support is just being bolted onto the J2EE stack. JAX-RPC, SAAJ, JAXM, JAXR, yadda, yadda. The fact that it's hard to quantify exactly what Axis is (saying that it is a JAX-RPC implementation is not really doing it justice) just exemplifies this. There is just seems to be no clear overall direction for supporting SOAP based SOAs with Java. Keep an eye on Indigo. Read through their white papers, if nothing else - they really seem to have their act together as far as SOAP based SOAs. If Microsoft can do for SOA with Indigo what it did for thick GUI architecture with .Net, then the time to market simplicity of it all is going to be hard to ignore. http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx Even if J2EE technologies can compete, it's almost as if we'll be following Microsoft's lead and interoperating with THEM rather than the other way around. Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: Nelson Minar [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:30 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design David, you may be understating the problem a bit. Building interoperable, WS-I compliant SOAP services with Axis is a little involved. Yeah, a little too involved. Shouldn't this be easier? No specific criticism of Axis intended. I'm just amazed at how much effort I'm going through to pass arrays of numbers around.
RE: Need suggestions on web service interop and design
David, Do these help? :) It's a stupid doc/literal WSDL I threw together for testing. Note the hard coded absolute schemaLocation paths in the WSDL and XSD imports - you'll have to change them to feed them into Axis WSDL2Java. If you have XMLSpy, you can verify that all is well when you open the WSDL and click the green Validate button. And as far as feeding them into Axis WSDL2Java goes, you have two options: Command line: java org.apache.axis.wsdl.WSDL2Java -o src\samples\axis -a -s -t -T 1.2 .\resources\BankService-DocLiteral.wsdl or Ant build script: target name=axis.wsdl2java.docliteral axis-wsdl2java all=true output=src/samples/axis verbose=true serverside=true testcase=true typemappingversion=1.2 url=resources/BankService-DocLiteral.wsdl/ /target Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: David Thielen [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 3:22 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design Your link is really helpful - and where I was thinking we were heading. That said, any place that can help a newbie through the hand generation of the wsdl file? There is a ton of samples in axis but I can't find one that shows the document/literal case. However I do have 1.1, not 1.2. (I'd prefer to have a sloution that runs on both.) Anyways, if anyone can point me at a sample or other help (preferably of a correct wsdl file for document/literal) I would really appreciate it. thanks - dave ps - The people who created axis have done an extraordinary job both with the product, the documentation, and the samples. -- Original Message -- From: Anderson Jonathan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 14 Apr 2004 12:37:17 -0400 David, you may be understating the problem a bit. Building interoperable, WS-I compliant SOAP services with Axis is a little involved. See: http://marc.theaimsgroup.com/?l=axis-userm=107945370506044w=2 Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: David Thielen [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 12:18 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Need suggestions on web service interop and design Speaking for myself (and I think lots of others), while a tutorial would be wonderful, if you could just tell us what method to use to create a server using java under access that .net can access - that's 90% of what we need. Especially if one of the existing axis examples implementes that method - then you can just point at that. thanks - dave -- Original Message -- From: Nelson Minar [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 14 Apr 2004 09:01:42 -0700 HG writes: I can see that Axis 1.2 is alpha...Anyone knows of the beta or final release plans..? There is a beta, but for some inexplicable reason it's not visible on the site. You can find it here: http://archive.apache.org/dist/ws/axis/1_2beta/ I'm having good luck with it. Anne Thomas Manes writes: For best interoperability, your interface should consist of simple types, arrays (defined using minOccurs/maxOccurs), and complex types defined as sequence structures of simple types, arrays, and/or sequence structures. A really clear example on how to build an Axis server this way, along with client examples in the major platforms, would be a tremendously useful tutorial. I've been toying with the idea of writing one myself but have been too busy. I'm pretty sure xml.com would be glad to publish it. ?xml version=1.0 encoding=UTF-8? schema targetNamespace=http://webservices.bah.com/examples/docliteral/bank; xmlns=http://www.w3.org/2001/XMLSchema; xmlns:bank=http://webservices.bah.com/examples/docliteral/bank; xmlns:banktypes=http://webservices.bah.com/examples/docliteral/bank/types; elementFormDefault=qualified attributeFormDefault=unqualified import namespace=http://webservices.bah.com/examples/docliteral/bank/types; schemaLocation=file:///C:\projects\webservice-examples\resources\BankTypes.xsd/ complexType name=DepositRequestType sequence element ref=banktypes:Deposit/ /sequence /complexType element name=DepositRequest type=bank:DepositRequestType/ complexType name=DepositResponseType sequence element ref=banktypes:Confirmation/ /sequence /complexType element name=DepositResponse type=bank:DepositResponseType/ /schema definitions xmlns=http://schemas.xmlsoap.org/wsdl/; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:http=http://schemas.xmlsoap.org/wsdl/http/; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/; xmlns:bank=http://webservices.bah.com/examples/docliteral/bank; targetNamespace=http://webservices.bah.com/examples/docliteral/bank; types xs:schema
RE: Need suggestions on web service interop and design
Paul, Sounds like you might be hung up on W3C XML schema. Why not just do something like this? complexType name=BooksType sequence minOccurs=1 maxOccurs=unbounded element name=Book type=string/ /sequence /complexType element name=Books type=tns:BooksType/ That way, you could have XML that looks like this: Books xmlns=... xmlns:xsi=... xsi:schemaLocation=... BookBook1/Book BookBook2/Book /Books Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 4:05 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design Jonathan, Good effort! While I was able to create simple doc/literal service which works with .NET (in this case InfoPath), the stumbling block is having arrays of simple types as return types. If you could extend your example to handle return types as e.g. string arrays that would be REALLY helpful. Thanks, -Paul
RE: Axis 1.2 supports doc/lit better, they say
There are a number of doc/lit showstopper bugs in Axis 1.1 - the ones I encountered were in the WSDL2Java emitter, I believe. Check out JIRA, the Apache bug tracking tool. Go here: http://nagoya.apache.org/jira/secure/Dashboard.jspa Then click on Axis, then click on Find Issues. In the Text Search Query field, enter doc/lit, check the Summary Query Field box, and click the View button. This should pull up all of the 1.1 doc/lit bugs. Enjoy. Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: Barzilai Spinak [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 4:37 PM To: [EMAIL PROTECTED] Subject: Axis 1.2 supports doc/lit better, they say Everyone is saying that Axis 1.2 supports doc/li better. Anybody can tell me in which ways, especifically? BarZ Nueva forma de conectarse a internet en URUGUAY - Cuanto gasta hoy ? -- Tel. 0909.20.30 = Acceso 100% digital 56K! Promocion lanzamiento: $0,10 mas IVA el minuto. === http://www.internet.com.uy - Internet en serio.
RE: Need suggestions on web service interop and design
You are touching on an interesting and deep running debate, my friend. In order to build a SOAP service, should you be modeling the data types that you wish to exchange (the message payloads) in your native object oriented programming language (Java, C#, etc) or in your XML schema? Modeling the data types in the XML Schema first is generally considered a sound approach to SOAP service implementation when a) cross SOAP platform service interoperability and b) cross SOAP platform service portability issues are concerns. Hence the focus on hand crafted XML Schema and WSDL. You are advocating an approach that builds Java language specific types first and generating WSDL + Schema from them, using a SOAP platform specific WSDL emitter. Not everyone is sold on this approach, given that the different SOAP platforms on the market right now all have a) differing levels of support for W3C XML Schema and b) different approaches to the XML data binding problem. A Java class run through a particular SOAP platform's presto-magic WSDL + Schema generator a la Java2WSDL might not generate the same WSDL + Schema when run through another platform's WSDL + Schema generator. The converse is also true - WSDL + Schema run through a particular SOAP platform's XML - OO binding generator (WSDL2Java or the .Net equivalent WSDL.exe) will most certainly generate different service implementation skeletons/XML schema bindings/service deployment descriptors than another SOAP platform's equivalent tool. Dennis Sosnoski (www.sosnoski.com), a long-time XML deep thinker, first turned me onto the XML data binding problem with his excellent articles (4 parts) on the issues over at IBM developerWorks. http://www-106.ibm.com/developerworks/library/x-databdopt/index.html These issues are extremely relevant to WS-I compliant document/literal SOAP service design and implementation, given that current SOAP platforms (Axis, webMethods GLUE, Cape Clear, BEA Weblogic, Systinet WASP, Microsoft .Net) all approach the XML data binding problem differently, given that no J2EE specification currently mandates one particular approach (even JAX-RPC 2.0's usage of JAXB 2.0 as its default data binding API will probably be overridable). A SOAP service implemented on one Java platform today is simply not portable to another Java platform - and that is indeed a sad state of affairs. Regards, Jonathan Anderson Booz Allen Hamilton -Original Message- From: Yakulis, Ross (Ross) [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 5:35 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design Note, that while Axis cannot currently generate this wsdl file, the WSDL2Java in Axis will consume the wsdl. This seems more painless that the other documented process. Ross -Original Message- From: Yakulis, Ross (Ross) Sent: Wednesday, April 14, 2004 1:43 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design It can be eaiser. Download the Systinet developer tools for eclipse. Given the .java file it generated a doc/literal wsdl. Ross -Original Message- From: Nelson Minar [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 10:30 AM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design David, you may be understating the problem a bit. Building interoperable, WS-I compliant SOAP services with Axis is a little involved. Yeah, a little too involved. Shouldn't this be easier? No specific criticism of Axis intended. I'm just amazed at how much effort I'm going through to pass arrays of numbers around.
What is needed from the JCP to ensure SOAP service portability across all Java SOAP platforms? (was RE: Need suggestions on web service interop and design)
Anne Thomas Manes wrote to axis-user: JAX-RPC 1.1 defined standard mappings between Java types and RPC/Encoded, but it doesn't do the same for Doc/Literal (even though Sun claims it does). It could be done as part of JAXB 2.0 or JAX-RPC 2.0, but I'm not convinced that it belongs in either one. Anyone on this list care to initiate a JSR? Is there any way to gain visibility into the JAX-RPC 2.0 (JSR 224) design discussions? Do I have to become a member of the expert group, or is there anything open to the public? I'd be very curious as to their opinions on this topic. I'm very much of the opinion that there should be one standardized and specified set of W3C XML Schema - Java mappings THAT ALL JAVA SOAP IMPLEMENTATIONS SHOULD BE MANDATED TO USE. But hell, webMethods GLUE touts its ElectricXML XML - Java binding engine as one of their discriminating features. WASP likewise touts its robust W3C schema support (substitution groups, etc). So am I dreaming of a utopia that vendors will never agree to? Is it not in a SOAP platform vendor's best interest to make SOAP services implemented on their platform proprietary? Regards, Jonathan Anderson Booz Allen Hamilton
Known WSDL emitting issue or new 1.2 beta bug?
Greetings everyone, I want to get a reality check before entering a JIRA bug report. Thanks go out to the SOAPtest guys over at Parasoft for helping me realize this problem - it was quite subtle. In the following WSDL, I do the following: BankService-DocLiteral.wsdl, target namespace: http://webservices.bah.com/examples/docliteral/bank ...which imports... BankService.xsd, target namespace: http://webservices.bah.com/examples/docliteral/bank ...which imports... BankTypes.xsd, target namespace: http://webservices.bah.com/examples/docliteral/bank/types Note that the Deposit element and DepositType type are defined in BankTypes.xsd, under the target namespace http://webservices.bah.com/examples/docliteral/bank/types. The DepositRequest element and DepositRequestType type are defined in BankService.xsd under the target namespace http://webservices.bah.com/examples/docliteral/bank, and DepositRequestType then *references* the Deposit element for inclusion inside of a sequence. At the end of the day I should have a wrapper element in namespace A with a child element in namespace B, a la: soap:Envelope xmlns:bank=http://webservices.bah.com/examples/docliteral/bank; xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; xmlns:banktypes=http://webservices.bah.com/examples/docliteral/bank/types; xmlns:xs=http://www.w3.org/2001/XMLSchema; soap:Body bank:DepositRequest banktypes:Deposit banktypes:AccountNumber100/banktypes:AccountNumber banktypes:Amount100/banktypes:Amount /banktypes:Deposit /bank:DepositRequest /soap:Body /soap:Envelope The problem is then in the Axis 1.2 beta emitted WSDL (http://.../DocLiteralBankService?wsdl) for the service - it places the DepositType type in the correct namespace (http://webservices.bah.com/examples/docliteral/bank/types), but the Deposit element itself is in the wrong namespace (http://webservices.bah.com/examples/docliteral/bank). This results in the following: ?xml version=1.0 encoding=UTF-8? soap:Envelope xmlns:bank=http://webservices.bah.com/examples/docliteral/bank; xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; xmlns:banktypes=http://webservices.bah.com/examples/docliteral/bank/types; xmlns:xs=http://www.w3.org/2001/XMLSchema; soap:Body bank:DepositRequest bank:Deposit banktypes:AccountNumber100/banktypes:AccountNumber banktypes:Amount100/banktypes:Amount /bank:Deposit /bank:DepositRequest /soap:Body /soap:Envelope Which of course the generated WSDL2Java service impl does not expect, so it throws: org.xml.sax.SAXException: Invalid element in com.bah.webservices.examples.docliteral.bank.DepositRequestType - Deposit Any thoughts? The WSDL2Java generated service is definitely expecting the Deposit namespace to be in the http://webservices.bah.com/examples/docliteral/bank/types namespace, making me think the problem is only with the ?wsdl auto-emitting. A workaround, of course, is to use wsdlFile to manually return good WSDL, but hey - now's the time to fix this, right? Thoughts and comments are quite welcome. Regards, Jonathan Anderson Booz Allen Hamilton ?xml version=1.0 encoding=UTF-8? schema targetNamespace=http://webservices.bah.com/examples/docliteral/bank; xmlns=http://www.w3.org/2001/XMLSchema; xmlns:bank=http://webservices.bah.com/examples/docliteral/bank; xmlns:banktypes=http://webservices.bah.com/examples/docliteral/bank/types; elementFormDefault=qualified attributeFormDefault=unqualified import namespace=http://webservices.bah.com/examples/docliteral/bank/types; schemaLocation=file:///C:\projects\webservice-examples\resources\BankTypes.xsd/ complexType name=DepositRequestType sequence element ref=banktypes:Deposit/ /sequence /complexType element name=DepositRequest type=bank:DepositRequestType/ complexType name=DepositResponseType sequence element ref=banktypes:Confirmation/ /sequence /complexType element name=DepositResponse type=bank:DepositResponseType/ /schema definitions xmlns=http://schemas.xmlsoap.org/wsdl/; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:http=http://schemas.xmlsoap.org/wsdl/http/; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/; xmlns:bank=http://webservices.bah.com/examples/docliteral/bank; targetNamespace=http://webservices.bah.com/examples/docliteral/bank; types xs:schema xs:import namespace=http://webservices.bah.com/examples/docliteral/bank; schemaLocation=file:///C:\projects\webservice-examples\resources\BankService.xsd/ /xs:schema /types message name=DepositRequestMessage part name=depositRequest element=bank:DepositRequest/ /message message name=DepositResponseMessage part name=depositResponse element=bank:DepositResponse/ /message portType name=BankServicePortType operation name=deposit input
RE: Best Practices?
I would venture to say that 80% of the complications and frustrations implementing interoperable (WS-I compliant Doc/Literal) SOAP web services on Java platforms stem from the XML datatype to Java datatype binding problem. If you take the time to learn W3C XML Schema, you'll see the problem: it's not an OO type system. Therefore modeling your data types in Java and expecting some automagic Java2WSDL utility to do all of the hard work to generate your XML schema is naive, and it is unfortunate that so many OO developers think this way. I've encountered several approaches for dealing with this problem with Axis - virtually all of them involve hand crafting your WSDL and XSD (with a WSDL/XSD IDE, of course) and generating a Java type system using ***a particular Java XML binding engine***. Using Axis's internal XML binding engine is one of several options available to you. For more info on the XML binding problem in Java, I defer to Dennis Sosnoski (www.sosnoski.com), a long-time XML deep thinker. He first turned me onto the XML data binding problem with his excellent articles (4 parts) on the issues over at IBM developerWorks. http://www-106.ibm.com/developerworks/library/x-databdopt/index.html If you're trying to use Axis's internal XML binding engine, here's some advice: http://marc.theaimsgroup.com/?l=axis-userm=107945370506044w=2 We've since moved away from this approach, and are currently using Axis's Message Style services to pass the SOAP Request Body DOM straight to Castor, which unmarshalls the XML into a Castor generated type system. We further introduced a broker pattern to abstract the SOAP messaging layer from our business layer, which currently is not tied to any XSD generated types. Axis Message Style Service Implementation - Service Broker Layer (unmarshalls SOAP Request DOM via Castor, extracts the necessary information from Castor types - literally traversing the graph's getters - to invoke Business Manager Layer, and catches Business Exceptions and maps them to proper SOAP Faults using AxisFault)- Business Manager Layer (not tied to XSD types, but rather pure Java business domain types, invokes DAO layer as needed) - DAO Layer (a Spring/Hibernate layer to manage persistence for business domain types) The problem here is definitely managing and translating between the two type systems: Castor generated classes from XSD and non-generated Business Domain classes. The alternative, however, is to just try to use the XSD generated type system and persist that directly. This is too big of a leap for us right now, as our business layer doesn't think in pure XSD type terms. You'll probably encounter this a lot given how much legacy functionality people are trying to SOAP service enable. Bottom line: implementing a WS-I compliant SOAP service in Java is not a trivial thing. There are two types of people building Web Services in Java: those who are extremely frustrated with the completely stupid state of the Java based Web Services world right now and yet still trying very hard to do it right, and those who haven't grasped that world is in a completely stupid state right now. -Jon -Original Message- From: Joe Plautz [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 10:02 AM To: [EMAIL PROTECTED] Subject: Re: Best Practices? My first attemps have started with a WSDL/Schema then I generate everything. I was able to find an example at W3.org and I just manipulate it to the way I need it. I thought this to be the best way at the time because of interoperability. From what I've been finding thus far there are no Standard practices, just Accepted practices. Starting with a class then using Java2WSDL and then WSDL2Java seems to be the most common. But, it almost seems that this was not the intention of the designers of Axis. Why use two steps when you can use one? Creating a WSDL from scratch seems like the intended way, but is not the most accepted way by the developers/users of Axis. Why write what you can generate? I know this isn't difficult earth shattering stuff, I'm just looking for the best way of doing this. So, when I start working with other people to create services, we're doing it the right way. - Original Message - From: Dorner Thomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 7:01 AM Subject: AW: Best Practices? You are right - if you will do a interoperable webservice that deal with other clients (.Net ...) its better to go from the wsdl. But when i use String, int and so on and i generate a wsdl by java2wsdl, I hope the wsdl i get, depends on the standard spec. for wsdl! So there should no problem to use the wsdl by other languages!??? Dont know how it looks with complex datatypes! Do you all write your own wsdl by hand Tomi -Ursprüngliche Nachricht- Von: David Cunningham [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 12. Mai 2004 13:14 An: [EMAIL PROTECTED] Betreff: RE: Best Practices? I
RE: Best Practices?
the obvious place to start. If WSDL is a burden to work with, that's not a criticism of Axis. My $.02, Russ -Original Message- From: Yakulis, Ross (Ross) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 1:30 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Best Practices? Exactly, that is why Jonathan Anderson is on the wrong track. He describes what he currently has to do. The real question is in the long run what is the right way to do things and push for that and get Axis to migrate in that direction. I personally still believe that writing wsdl files is for the birds and should be avoided. Ultimately, only tools should be generating wsdl files, scans for rare cases. If web services are not easy to create and deploy they are generally not much better that their predecessors. Ross -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 10:14 AM To: [EMAIL PROTECTED] Subject: Re: Best Practices? Let's twist this discussion on its head - Is there a list of bugs hiding in there somewhere? (bug reports) - What would you do if you were to write/re-write parts of axis? (enhancements requests) If we can't create new bug reports / enchancements to tell axis developers how axis should behave in the future (1.2 Final) then all discussion is just water under the bridge. thanks, -- dims On Wed, 12 May 2004 12:12:44 -0500, Joe Plautz [EMAIL PROTECTED] wrote: Thanks for the advice! This is exactly what I've been looking for. It almost seems that people end up using Axis inspite of itself. But, it's just too dang easy to get something up and running. I imagine JWS files have lead many people astray with their simplicity. If all services could work like them, plus using user defined objects/type with little to no configuration. The world would be a fabulous place. I too have been not tying my service layer to my DAO layer. My reasons are more personal preferrance then need. But, I can take my DAO and put it behind something else with little changing except creating a new broker. -Joe - Original Message - From: Anderson Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 10:03 AM Subject: RE: Best Practices? I would venture to say that 80% of the complications and frustrations implementing interoperable (WS-I compliant Doc/Literal) SOAP web services on Java platforms stem from the XML datatype to Java datatype binding problem. If you take the time to learn W3C XML Schema, you'll see the problem: it's not an OO type system. Therefore modeling your data types in Java and expecting some automagic Java2WSDL utility to do all of the hard work to generate your XML schema is naive, and it is unfortunate that so many OO developers think this way. I've encountered several approaches for dealing with this problem with Axis - virtually all of them involve hand crafting your WSDL and XSD (with a WSDL/XSD IDE, of course) and generating a Java type system using ***a particular Java XML binding engine***. Using Axis's internal XML binding engine is one of several options available to you. For more info on the XML binding problem in Java, I defer to Dennis Sosnoski (www.sosnoski.com), a long-time XML deep thinker. He first turned me onto the XML data binding problem with his excellent articles (4 parts) on the issues over at IBM developerWorks. http://www-106.ibm.com/developerworks/library/x-databdopt/index.html If you're trying to use Axis's internal XML binding engine, here's some advice: http://marc.theaimsgroup.com/?l=axis-userm=107945370506044w=2 We've since moved away from this approach, and are currently using Axis's Message Style services to pass the SOAP Request Body DOM straight to Castor, which unmarshalls the XML into a Castor generated type system. We further introduced a broker pattern to abstract the SOAP messaging layer from our business layer, which currently is not tied to any XSD generated types. Axis Message Style Service Implementation - Service Broker Layer (unmarshalls SOAP Request DOM via Castor, extracts the necessary information from Castor types - literally traversing the graph's getters - to invoke Business Manager Layer, and catches Business Exceptions and maps them to proper SOAP Faults using AxisFault)- Business Manager Layer (not tied to XSD types, but rather pure Java business domain types, invokes DAO layer as needed) - DAO Layer (a Spring/Hibernate layer to manage persistence for business domain types) The problem here is definitely managing and translating between the two type systems: Castor generated classes from XSD and non-generated Business Domain classes. The alternative, however, is to just try to use the XSD generated type system and persist that directly. This is too big of a leap for us right now, as our
RE: Best Practices?
Don't get me wrong Dims - I have a lot of high hopes for the JAX-RPC 2.0/JAXB 2.0 marriage. I'm just wondering what Axis can productively do until they start dropping draft specs. I think all you realistically hope for is to shore up JAX-RPC 1.1/WS-I BP 1.0a support as best you can in Axis 1.x, and wait for JSR 224 to lead us to salvation. Sun led us into this mess with JAX-RPC 1.0 (in their defense, I don't think anybody truly foresaw WS-I) and I'm hoping they can lead us out. I don't think I've ever seen a technology get off on the one foot, call it wrong, and reinvent itself as quickly as SOAP technology has. -Jon -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 1:14 PM To: [EMAIL PROTECTED] Subject: Re: Best Practices? Let's twist this discussion on its head - Is there a list of bugs hiding in there somewhere? (bug reports) - What would you do if you were to write/re-write parts of axis? (enhancements requests) If we can't create new bug reports / enchancements to tell axis developers how axis should behave in the future (1.2 Final) then all discussion is just water under the bridge. thanks, -- dims On Wed, 12 May 2004 12:12:44 -0500, Joe Plautz [EMAIL PROTECTED] wrote: Thanks for the advice! This is exactly what I've been looking for. It almost seems that people end up using Axis inspite of itself. But, it's just too dang easy to get something up and running. I imagine JWS files have lead many people astray with their simplicity. If all services could work like them, plus using user defined objects/type with little to no configuration. The world would be a fabulous place. I too have been not tying my service layer to my DAO layer. My reasons are more personal preferrance then need. But, I can take my DAO and put it behind something else with little changing except creating a new broker. -Joe - Original Message - From: Anderson Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 10:03 AM Subject: RE: Best Practices? I would venture to say that 80% of the complications and frustrations implementing interoperable (WS-I compliant Doc/Literal) SOAP web services on Java platforms stem from the XML datatype to Java datatype binding problem. If you take the time to learn W3C XML Schema, you'll see the problem: it's not an OO type system. Therefore modeling your data types in Java and expecting some automagic Java2WSDL utility to do all of the hard work to generate your XML schema is naive, and it is unfortunate that so many OO developers think this way. I've encountered several approaches for dealing with this problem with Axis - virtually all of them involve hand crafting your WSDL and XSD (with a WSDL/XSD IDE, of course) and generating a Java type system using ***a particular Java XML binding engine***. Using Axis's internal XML binding engine is one of several options available to you. For more info on the XML binding problem in Java, I defer to Dennis Sosnoski (www.sosnoski.com), a long-time XML deep thinker. He first turned me onto the XML data binding problem with his excellent articles (4 parts) on the issues over at IBM developerWorks. http://www-106.ibm.com/developerworks/library/x-databdopt/index.html If you're trying to use Axis's internal XML binding engine, here's some advice: http://marc.theaimsgroup.com/?l=axis-userm=107945370506044w=2 We've since moved away from this approach, and are currently using Axis's Message Style services to pass the SOAP Request Body DOM straight to Castor, which unmarshalls the XML into a Castor generated type system. We further introduced a broker pattern to abstract the SOAP messaging layer from our business layer, which currently is not tied to any XSD generated types. Axis Message Style Service Implementation - Service Broker Layer (unmarshalls SOAP Request DOM via Castor, extracts the necessary information from Castor types - literally traversing the graph's getters - to invoke Business Manager Layer, and catches Business Exceptions and maps them to proper SOAP Faults using AxisFault)- Business Manager Layer (not tied to XSD types, but rather pure Java business domain types, invokes DAO layer as needed) - DAO Layer (a Spring/Hibernate layer to manage persistence for business domain types) The problem here is definitely managing and translating between the two type systems: Castor generated classes from XSD and non-generated Business Domain classes. The alternative, however, is to just try to use the XSD generated type system and persist that directly. This is too big of a leap for us right now, as our business layer doesn't think in pure XSD type terms. You'll probably encounter this a lot given how much legacy functionality people are trying to SOAP service enable. Bottom line: implementing a WS-I compliant
RE: Have doubts about Doc/Lit with axis
Java2WSDL implies that you are modeling the documents being exchanged by
your document/literal SOAP web service as Java objects, or in other words
Java types.
Given that W3C XML Schema is not an object oriented type system, you are
then required to trust your Java2WSDL GUI (BEA Weblogic Workshop, for
example) to map your language specific object oriented types to W3C XML
Schema types. The tool is literally generating the WSDL+XSD. A
SOAP/WSDL/XML purist might not be willing to let an OO data modeling tool
produce the XML type system and SOAP message exchange patterns documented in
the WSDL+XSD. Most of the time they want more control over the XML type -
OO type mapping process - and arguably so. If I'm building a web service
that does XML document oriented messaging over SOAP - shouldn't I be
primarily concerned about the XML document data models?
Which is why the SOAP/WSDL/XML purists are all modeling their W3C XML
Schemas first, then their WSDL, and then figuring out how to implement a
SOAP service that complies to that WSDL using an object oriented programming
language. A SOAP platform specific WSDL2Java utility is sometimes the
solution, sometimes not.
W3C XML Schema - Java data binding is standardized in the JAXB
specification, but some people don't like JAXB. They prefer other mapping
APIs/toolkits like Castor. Complicating this issue is that currently,
JAX-RPC 1.1 does not govern W3C XML Schema - Java data binding issues -
JAX-RPC 2.0 is being tied to JAXB 2.0. Time will tell if this helps to
alleviate any of these problems.
Axis WSDL2Java and Java2WSDL assume the use of the underlying Axis W3C XML
Schema - Java data binding engine, and lots of people just sidestep the
data binding engine altogether by using Axis message style services, a la:
public Document myOperation (Document requestDocument) {}
Realize that when you are comparing Java based SOAP platforms and toolkits
it may be that you are comparing apples to apples - but a Macintosh apple
tastes very different than a Granny Smith, and each may be suited for
different types of recipes. :)
Regards,
Jonathan Anderson
Booz Allen Hamilton
-Original Message-
From: Shantanu Sen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 27, 2004 2:46 PM
To: [EMAIL PROTECTED]
Subject: RE: Have doubts about Doc/Lit with axis
That may be a good enhancement request, but Java2WSDL
gives you more flexbility in the sense that you can
specify doc/lit or wrapped based on your need. So it
assumes that you know what you need.
I was playing with BEA WebLogic 8.1 workshop and when
I create a method and choose to expose it as a web
service and choose the soap-style as document, it
always generates the WSDL in the wrapped mode. I am
not sure what the WASP developer toolkit does. But it
seems that wrapped mode is becoming standard because
probably most toolkits think that it is the best bet
for interoperability.
When you are using a command line utility you have
more options, so it is upto you to specify whether you
want doc/lit or wrapped. I feel it is the
responsibility of a tool higher up e.g. a GUI tool
which uses Java2WSDL, to warn the user that they
should use wrapped if the number of params 1. But
there may be differing opinions on this.
Shantanu
--- Yakulis, Ross (Ross) [EMAIL PROTECTED] wrote:
Okay that is all fine and well. And in general I
agree.
But if you are using Java2WDSL and not hand writing
these ugly wsdl files, the tool(Java2WSDL) should
say something
to the effect that your java source file
(class/interface) is
not suitable for the chosen style and that WRAPPED
or RPC might be
a preferable way to generate the wsdl file, and not
out put an obscure
message that leaves one wondering what the heck went
wrong.
All David did in his original try was to use a
simple java class an
what appeared to be the proper tool Java2WSDL. A
good error message would
have suggested to him to use wrapped and then he
could have changed
the -y and -u options and he would have been a happy
camper.
Ross
-Original Message-
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 27, 2004 10:31 AM
To: [EMAIL PROTECTED]
Subject: RE: Have doubts about Doc/Lit with axis
For the most part, I concur with Jim. If you want to
create an RMI-style
programming interface, always use wrapped/literal.
On the other hand, if you
want to send a predefined schema (such as a standard
schema defined by your
favorite vertical industry group), you may need to
use Document/Literal --
particularly if the schema contains attributes.
Wrapped/Literal simulates
the RPC style, and it doesn't permit attributes.
Just to be clear, I don't believe that Axis is all
that buggy when it comes
to wrapped/literal. Certainly lots of folks have
been able to get it to
work. If there are bugs, then I think they're fairly
obscure (only occur
with unusual structures, etc). If you do find bugs,
then please report them.
RE: Best Practices?
Try Mindreef SOAPScope 3.0. It runs as a web app on your local machine, and you can either upload a WSDL to it or point it at a ?WSDL endpoint. It consumes the WSDL and constructs an HTML form page that allows you to populate the SOAP request. Click invoke, see the response. Very handy - can get hairy with complex schemas though. Regards, -Jon -Original Message- From: Galbreath, Mark A [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 5:41 PM To: '[EMAIL PROTECTED]' Subject: RE: Best Practices? bingo -Original Message- From: Volkmann, Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 3:03 PM To: '[EMAIL PROTECTED]' Subject: RE: Best Practices? I think the goal is to be able to test nearly any web service from a web browser when all you have is a WSDL URL. You'd enter that URL into a browser text field and be presented with a list of operations. You'd then pick an operation and be presented with an HTML form where you can enter the data to be passed to the operation. Next, you'd click the submit button and be presented with the results of the operation. attachment: winmail.dat
RE: specifying JAXP 1.1 compliant XML parser for Axis
We're running Axis in Weblogic 8.1 SP2 with only the following modification to the startManagedWeblogic.cmd startup script: set JAVA_OPTIONS=-Djavax.xml.soap.SOAPFactory=org.apache.axis.soap.SOAPFactoryIm pl But this has nothing to do with JAXP XML parsers (Xerces) or JAXP XML processors (Xalan) - you're simply telling it to use the Axis SOAPFactory instead of the BEA Weblogic platform specific SOAPFactory. Even then, we only need this configuration because we do things like this in our Axis handlers: SOAPFactory soapFactory = SOAPFactory.newInstance(); Name assertionName = soapFactory.createName(SAMLConstants.SAML_ASSERTION_NAME, SAMLConstants.SAML_NS_PREFIX, SAMLConstants.SAML_NS_URI); What problems are you encountering with the XML parser + processor (a build of Xerces + Xalan that they package in the consolidated weblogic.jar) that come with BEA Weblogic? -Jon -Original Message- From: Khare, Jagdish [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 10:28 AM To: [EMAIL PROTECTED] Subject: specifying JAXP 1.1 compliant XML parser for Axis Hi, I am running AXIS in weblogic 8.1 container. I have few other external JARs in the classpath which have XML parsers but not the ones compatible with Axis. I need to use the XML parsers included in Weblogic for the use of Axis. Is there a way (any property/parameter that Axis reads) by which I can specify weblogic version of XML parser to be used by Axis? Any help will be appreciated. Thanks!
RE: Populate WSDL2Java object from XML file.
Ever looked into Axis MSG style calls? This is client code, but you can do
the same thing on the server side as well, assuming you've built a MSG style
service. Check out the Axis docs for more information.
Service service = new Service();
Call call = (Call) service.createCall();
call.setSOAPActionURI(MyOperationName);
call.setTargetEndpointAddress(http://localhost:8080/services/MyService;);
SOAPBodyElement body = new SOAPBodyElement(doc.getDocumentElement());
body.setNamespaceURI();
call.invoke(new SOAPBodyElement[]{body});
-Jon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:40 PM
To: [EMAIL PROTECTED]
Subject: Populate WSDL2Java object from XML file.
How do you populate a WSDL2Java created object from an XML file?
I've hunted around in the mailing list archives, and I've seen this question
a few other times, but no answers that were clear enough for me to
understand.
Scenario: We have a WSDL which describes some service and imports some
schema which describes some data structures. Run WSDL2Java on the WSDL and
get out lots of nice Java. Typical usage is then to bind to a service
endpoint URL, create a parameter object, populate it, and invoke the service
with the method and parameter object.
Like this:
myService = new MyServiceLocator().getMyService(new URL(serviceEndpoint));
_myObject requestObj = new _myObject();
requestObj.setSomething(someValue);
Status s = myService.request(requestObj);
However, if _myObject is very complex, manually populating it is a pain.
It'd be easier to have an XML document lying around that complies with the
schema and just deserialize the XML into the WSDL2Java created object.
I tried:
DeserializerImpl myDeserializer =
(DeserializerImpl)_myObject.getDeserializer(, _myObject.class, myQName);
XMLReader reader =
SAXParserFactory.newInstance().newSAXParser().getXMLReader();
reader.setContentHandler(myDeserializer);
reader.parse(new InputSource(new FileInputStream(filename)));
_myObject myObj = (_myObject)myDeserializer.getValue();
But all I get is an empty _myObject. I _THINK_ part of the issue is that
the deserializer doesn't have access to the type mapping info in
deploy.wsdd, but I'm at a loss how to get that info to the deserializer.
Maybe this is worth putting in the Wiki?
Help, please.
Thanks.
- Jasen.
RE: purpose/usage of .wsdd file
I think of it this way: Axis is essentially a servlet, and you deploy it in a WAR via the WEB-INF/web.xml deployment descriptor. Well, how do you tell Axis what services to deploy? The Axis WEB-INF/server-config.wsdd deployment descriptor tells Axis what classes to deploy as services and which classes to map to which WSDL (XML Schema) types when the AxisServlet starts up (servlet init). -Jon -Original Message-From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]Sent: Thursday, June 17, 2004 8:16 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: RE: purpose/usage of .wsdd file A WSDL file describes the service from the clients point of view it specifies the name of each operation, and the format and encoding of the message A WSDD file describes the service from the runtime servers point of view it provides information that the runtime server uses to process the requested operation. It must know which provider to use (provider=java:RPC|java:EJB|java:MSG|custom), how to map the message contents to Java objects (style, use, and any custom serializers), what class to load, and what method to invoke for each message type. The WSDD provides this information. The information in the WSDD has to correspond to the information in the WSDL. As a convenience, Axis can auto-generate the WSDL for a service based on the information you specify in the WSDD but as a general best practice, you should define your WSDL first and generate your service from the WSDL. See http://www.osmoticweb.com/axis-wsdd/ for more info on the WSDD. Anne From: pyounguk cho [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 17, 2004 4:00 PMTo: [EMAIL PROTECTED]|Subject: purpose/usage of .wsdd file Hello, Could anybody explain what deployment.wsdd file is for? Is it used to generate wsdl file on the fly? Or, is it used to map and resolve runtime information necessaryto processeach soap request sent todeployed services? The answer to the above question will help clarifywhat kind of informationone needs toput in the deployment.wsdd file. For instance, I am having troubledeploying document-literal web services, whose root cause seems to have to do with lack of entries in the wsdd file, and I feel completely clueless. I am using Axis 1.2 beta running on tomcat 5.0.25 on Redhat. Here is what I have done so far. I need to create and deploy document-literal style web services out of an existing wsdl file. It has operations that use message parts of complex types wrapped as elements for both input and output. I - generated jax-rpc client stub and service skeleton using wsdl2java ant task from the predefined wsdl file - created a service class that implements the generated service skeleton - composed a .wsdd file with wsdlFile tag for the purpose of using the orignial wsdl - deployed the service using admin-clientwith .wsdd file and compiled jar file - created a client class that uses the generatedLocator/Stub When running the client, I've got a"No Such operation..." error. After searching the axis mailinglist, I added operation element under the service with name spaces. With that, I've got another error:"org.apache.axis.InternalException: java.lang.Exception: The OperationDesc for ws1 was not synchronized to a method of foo.ServiceImpl". Now the question is what more I need to put in the .wsdd file? When I want to use my wsdl file instead of the one genererated by axis,how does itaffect the runtime behavior to specifyvalues for, for instance,"style"and "use" attribute in service element?How about wsdlTargetNamespace or operation elements? Do I need to add typemapping element for each schema definition in the wsdl file and every class generated by wsdl2java spelling out all the (de)serializers? Does Axis runtime look into the wsdl file before/after server-config.wsdd? If anybody has any ideas what went wrong in my steps or can pass me any pointer touseful .wsdd reference manual, it will be appreciated. Composing deploy.wsdd would be more straigtforward if Axisseparates items for wsdl generationfrom those for processing requests. Regards, Pyounguk
RE: Java2WSDL help
My team has been building WS-I compliant doc/lit services and clients for
months now using Axis 1.2 alphas, beta 1, and beta 2.
We just build our services from the XSD+WSDL in (WSDL2Java), instead of from
the Java code out (Java2WSDL). Very important to understand the
implications of either approach.
http://marc.theaimsgroup.com/?l=axis-userm=108437425229600w=2
-Jon
-Original Message-
From: Henry Lu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 25, 2004 3:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Java2WSDL help
As far as I know, Axis 1.2 beta doesn't work with doc/lit. I tried so
many times and I failed to get it going and I filed reports through the
JIRA and no answer so far. I am waiting for the next release to resolve
this very, very important issue.
-Henry
[EMAIL PROTECTED] 8/25/2004 2:36:19 PM
Hi,
I want to convert the %AXIS_HOME%/samples/faults example from
rcp/encoded to document/literal. I run the java2wsdl command but
I get an error. Just curious why is it asking for typemapping info when
it's create my wsdl file. Would you know how I can get pass this error
message? Thanks
axis 1.2 beta
windows xp
java version 1.4.1_03
C:\axis-1_2beta\samples\faultsjava org.apache.axis.wsdl.Java2WSDL -o
wp.wsdl -l
http://localhost:8080/axis/services/EmployeeInfo; -n
http://faults.samples; -p
samples.faults http://faults.samples; -y DOCUMENT -u LITERAL
samples.faults.EmployeeInfo
log4j:WARN No appenders could be found for logger
(org.apache.axis.i18n.ProjectR
esourceBundle).
log4j:WARN Please initialize the log4j system properly.
AxisFault
faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultSubcode:
faultString: Please register a typemapping/beanmapping for
'samples.faults.Empl
oyee'
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:AxisFault
faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultSubcode:
faultString: Please register a typemapping/beanmapping for
'samples.faults.Empl
oyee'
faultActor:
faultNode:
faultDetail:
Please register a typemapping/beanmapping for
'samples.faults.Employee'
at
org.apache.axis.wsdl.fromJava.Emitter.writePartToMessage(Emitter.java
:1810)
at
org.apache.axis.wsdl.fromJava.Emitter.writeRequestMessage(Emitter.jav
a:1386)
at
org.apache.axis.wsdl.fromJava.Emitter.writeMessages(Emitter.java:1034
)
at
org.apache.axis.wsdl.fromJava.Emitter.writePortType(Emitter.java:1005
)
at
org.apache.axis.wsdl.fromJava.Emitter.getWSDL(Emitter.java:459)
at
org.apache.axis.wsdl.fromJava.Emitter.emit(Emitter.java:310)
at
org.apache.axis.wsdl.fromJava.Emitter.emit(Emitter.java:405)
at org.apache.axis.wsdl.Java2WSDL.run(Java2WSDL.java:583)
at org.apache.axis.wsdl.Java2WSDL.main(Java2WSDL.java:629)
Please register a typemapping/beanmapping for
'samples.faults.Employee'
at
org.apache.axis.wsdl.fromJava.Emitter.writePartToMessage(Emitter.java
:1810)
at
org.apache.axis.wsdl.fromJava.Emitter.writeRequestMessage(Emitter.jav
a:1386)
at
org.apache.axis.wsdl.fromJava.Emitter.writeMessages(Emitter.java:1034
)
at
org.apache.axis.wsdl.fromJava.Emitter.writePortType(Emitter.java:1005
)
at
org.apache.axis.wsdl.fromJava.Emitter.getWSDL(Emitter.java:459)
at
org.apache.axis.wsdl.fromJava.Emitter.emit(Emitter.java:310)
at
org.apache.axis.wsdl.fromJava.Emitter.emit(Emitter.java:405)
at org.apache.axis.wsdl.Java2WSDL.run(Java2WSDL.java:583)
at org.apache.axis.wsdl.Java2WSDL.main(Java2WSDL.java:629)
C:\axis-1_2beta\samples\faults
___
RE: Newbie doubts on XML Signature
You are going to need to get in touch with the owners of that Web Service so
that you can determine *exactly* what it is expecting.
A) Exactly what type of XML Signature does it expect? OASIS WS-Security
2004? Microsoft WS-Security 2002? An enveloped signature inside the SOAP
envelope (which is not normally recommended)?
B) If the owners have gone to the trouble of requiring signatures, they
probably do this so that they can authorize access to the service based upon
an authenticated message signature. They might require some sort of
out-of-band service level agreement (calling them, signing some papers,
getting your certificate placed on their trusted list, etc) prior to
invoking their service.
Regards,
Jonathan Anderson
Booz Allen Hamilton
-Original Message-
From: babloosony [mailto:[EMAIL PROTECTED]
Sent: Friday, February 11, 2005 8:10 AM
To: [EMAIL PROTECTED]
Subject: Newbie doubts on XML Signature
Hi All,
There is a third party web service which exposed its wsdl to clients and I
used AXIS 1.2 RC2 to create stubs and have written a web service client
program to access the web service. However may the server is expecting a
signed xml signature in the soap message to verify them I am not able to
successfully get a soap response from the wsdl and instead I get below
exception.
Exception from server
[java] AxisFault
[java] faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server
[java] faultSubcode:
[java] faultString: System.Web.Services.Protocols.SoapException:
Server was unable to process request. --- System.Exception: Signature
Verification Failed.
[java] faultActor:
[java] faultNode:
[java] faultDetail:
[java] {http://xml.apache.org/axis/}stackTrace: AxisFault
[java] faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server
[java] faultSubcode:
[java] faultString: System.Web.Services.Protocols.SoapException:
Server was unable to process request. --- System.Exception: Signature
Verification Failed.
[java] faultActor:
[java] faultNode:
[java] faultDetail:
[java] System.Web.Services.Protocols.SoapException: Server was unable
to process request. --- System.Exception: Signature Verification Failed.
[java] at
org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:2
60)
[java] at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:16
9)
[java] at
org.apache.axis.encoding.DeserializationContextImpl.endElement(Deserializati
onContextImpl.java:1015)
[java] at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1712)
[java] at
org.apache.crimson.parser.Parser2.content(Parser2.java:1963)
[java] at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691)
[java] at
org.apache.crimson.parser.Parser2.content(Parser2.java:1963)
[java] at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691)
[java] at
org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667)
[java] at org.apache.crimson.parser.Parser2.parse(Parser2.java:337)
[java] at
org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)
[java] at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
[java] at
org.apache.axis.encoding.DeserializationContextImpl.parse(DeserializationCon
textImpl.java:242)
[java] at
org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:538)
[java] at org.apache.axis.Message.getSOAPEnvelope(Message.java:376)
[java] at org.apache.axis.client.Call.invokeEngine(Call.java:2583)
[java] at org.apache.axis.client.Call.invoke(Call.java:2553)
[java] at org.apache.axis.client.Call.invoke(Call.java:2248)
[java] at org.apache.axis.client.Call.invoke(Call.java:2171)
[java] at org.apache.axis.client.Call.invoke(Call.java:1691)
[java] at
www.americanexpress.com.schemas.serviceportal.demands.v10.webservices.DOC_Ca
rdsOwnedWSSoapStub.getCardsOwned(DOC_CardsOwnedWSSoapStub.java:154)
[java] at
serviceportal.demands.DOC_CardsOwnedWS.query(DOC_CardsOwnedWS.java:46)
[java] at
serviceportal.demands.DOC_CardsOwnedWS.main(DOC_CardsOwnedWS.java:62)
[java] System.Web.Services.Protocols.SoapException: Server was unable
to process request. --- System.Exception: Signature Verification Failed.
[java] at
org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:2
60)
[java] at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:16
9)
[java] at
org.apache.axis.encoding.DeserializationContextImpl.endElement(Deserializati
onContextImpl.java:1015)
[java] at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1712)
[java] at
org.apache.crimson.parser.Parser2.content(Parser2.java:1963)
RE: Where are WSS4J Binaries?
No binaries exist. Checkout from CVS and build. -Jon From: Ry. [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 16, 2005 2:07 PMTo: [EMAIL PROTECTED]Subject: Where are WSS4J Binaries? Hi, I am looking forward to using WSS4J in my project but I don't knowwhere to find the binaries from http://ws.apache.org/ws-fx/wss4j/. Cansomeone please point me in the right direction! I know this is not the ideal mailing list but I hope someone can still help me out, pleeease! Many Thanks,Ryan. Do you Yahoo!?Yahoo! Search presents - Jib Jab's 'Second Term' smime.p7s Description: S/MIME cryptographic signature
