Re: java.util.Properties
munesh wrote: Hi, Can someone guide me how i can Serialize java.util.Properties and send across the wire over SOAP. Maybe this is naive... why can't you send the .properties file? Bill de hÓra
Re: SOAP message parsing redundancy with doc-lit services.
Sharmin Choksey [comcast] wrote: In reference to the message posted, I am specifically interested in knowing if there has been any development done in addressing the issue around parsing of the XML payload sent in the SOAP body by the AXIS runtime. I see a design issue here with respect to performance since parsing of the xml payload in a doc-lit style service does not add any value/functionality in performing AXIS related tasks. I see that the Message object has the ability to store different formats of the SOAP body element, inputstream, string, bytes etc. Why isn't the content of the SOAP body element left alone instead of parsing it. Because the body element and its contents are inside the envelope's root element. That is, this is a SOAP/XML issue, not an Axis issue. And if you're sending XML, you should parse it to ensure well-formedness or you'll break your receiver. Is there an alternative other than using attachments ? where the payload will not be parsed ? Please advise. The MIME people got this right a long time ago. If you don't want to parse a SOAP payload, don't put it in a SOAP envelope. I would use SwA, or multipart mime. CDATA is a hack.
Re: Why Pull-Parser faster ?
Brain, Jim wrote: Reason: XPP is tuned for SOAP and structured XML work, where the whitespace and CRLF marks can be assumed to be there for prettiness only, and have no code value. So XPP isn't a compliant XML parser? Bill de hÓra
Re: Why Pull-Parser faster ?
Dennis Sosnoski wrote: AFAIK XPP has always reported whitespace properly. Glue's Electric XML is the only parser I know of that discards whitespace between elements (though this may have become an option rather than hardwired behavior in recent versions). Fair enough if a feature is provided that allows ignorable ws to be just that. But that doesn't answer my question. XPP3 is the current version of the XPP parser. XPP3 implements the XMLPull interface (http://www.xmlpull.org) and is compliant with the XML specification except with respect to DTDs and related issues (general entities, etc.). These generally aren't used for data-oriented XML, and I think they're actually forbidden by SOAP. XPP hs no business calling itself an XML anything if it doesn't square with XML 1.0. If it wants to be a SOAP processor, it should be renamed. Bill de hÓra
Re: Why Pull-Parser faster ?
Anne Thomas Manes wrote: Keep in mind that SOAP is not XML. Yes. It is an XML application. When you define an XML application, it's perfectly legitimate to restrict certain contructs. No, it is an XML Infoset application. Big difference. XML 1.0 syntax is one possible serialization for SOAP messages. You're the second knowledgeable person I've seen recently make this conflation. And back to the point. Why are these processors named as though the process XML? They clearly process a subset (SOAP) and are thus not compliant XML processors. I don't care so much that they only work with SOAP; that's fine. I do care that they muddy the waters between SOAP and XML 1.0 processors, that's not fine. Bill de hÓra
Re: Why Pull-Parser faster ?
Brain, Jim wrote: Depends on your definition of compliant No it doesn't depend on my defintion of compliant. It depends on the XML 1.0 spec's definition of compliant. If you write a parser that understands all of XML, but may throw away pieces that it knows you don't want or need, is it out of compliance because it pre-discarded the information? I don't know. If you needed it, I guess it is out of compliance. You're missing the point. If you write a XML parser, you write it to parse and emit XML. If you only needed to parse something else, like the SOAP subset, go right ahead, but don't call it an XML parser/processor. Bill de hÓra
Re: Stateful Web Services
Steve Loughran wrote: think about this for a moment. How are you going to specify bank account and auth info? If it goes with every request, then you could be stateless. Otherwise the caller needs to first 'bind' to an account, then make requests on it. We call that 'state', no matter how it is actually implemented. I've come across a similar problem in the context of amendments (writes) to citizen data held by government. Unless you can coordinate agreemement at the application level that a client won't send a new amendment until the previous one was acknowledged and/or written, amendments are stateful because they need to be applied in order. At minimum this requires integer sequencing (agree on an offset!) a reference to the resource being amended, and the identity of the writer (if there are 1 writers). A correlation id or nested correlation ids held across the set of amendments might be useful for auditing purposes, but these aren't neccessary for data safety, nor is a session. Additionally, writes could also require application level acknowledgements that they will be applied and possibly that they have been applied if the writes are highly asynchronous (say if you had a service window). All this is somewhat incidental to session binding unless the session's semantics guarantee calls will be not be applied out of order (for example weird things might happen in Java with the OPs call sequence given Java's semantics). * the getbalance call includes not just the balance, but the time that balance was valid. I'd use xsd:long containg time_t in GMT, for that, as xsd:dateTime always causes problems for me wrt timezones. Dates are flaky, unless your SOAP nodes are synchronized on the same timeserver or there's a human involved, or there's only one client (and maybe even then things will be unsound). They might be helpful for auditing purposes. You could use a logical clock, if that was agreed on beforehand (logical clock semantics for multiple writers are well understood). Bill de hÓra
Re: Design question on using Java classes v/s hashes or arrays
Garbis, Jason wrote: Your option 1 below, is pretty distasteful, since you're bypassing any typechecking, and (more importantly) excluding important information from the WSDL metadata. That is, a user would have to consult some external metadata to understand what is and isn't valid input. This defeats the purpose of using WSDL. I belive a dictionary/data driven approach is a good choice when the interface is unstable or likely to change. Typechecking depends on the nature of the keys used and the argument being passed in. Or, could you change the XML type definition for the input message to support optional fields? Then, in the handler that receives this invocation, you'll have to figure out which set of input parameters are actually in the SOAP message, and dispatch it to the appropriate resource (e.g. Java class). (This assumes you even want to write this dispatching code...) That would be one approach- it sounds very like a generic method, the most specific version of the.method is selected for the arguments supplied. It's a way to work around the fact that SOAP/WSDL doesn't offer much by the way of polymorphism. It's not btw, a million miles away from using a dictionary. Another option is not to use a custom interface, instead see if the service can be described in terms of HTTP methods, which are stable, polymorphic and highly generic and bind the WSDL to that. This is a real challenge in building tightly-coupled distributed systems with WS It is, but, the point of using WS is to build loosely coupled systems with coarse grained messages. Another take is that tightly coupling systems through fine grained method calls is not a good approach for building web distributed systems the problems Rajal is running into simply reflect that it's an antipattern at best. (As an aside, not using a finegrained approach is no evidence of 'not thinking enough'- far from it) Bill de hÓra -- Propylon www.propylon.com
Re: Document style web services
Dennis Sosnoski wrote: The facet of WS-I that smells the worst is this business of *permanent* board seats for the priviledged few. This seems bizzare, especially given that Fujitsu, for example, is not a name that springs to mind immediately when I'm thinking of web services. In fact, it looks more like the permanent board seats were divvied up by Microsoft and IBM over a mutually-agreed set of companies. I don't find Fujitsu's place bizarre at all. There are people in Fujitsu Labs who are heavily involved in FIPA and message based agent computing. The FIPA Abstract Architecture and webservices stacks have a lot in common - the main differentiator being that FIPA AA has a content model for payloads. Bill de hÓra
Re: isolation of web services deployed on axis
Steve Loughran wrote: The trouble with isolation is that you have to be thorough. you need isolated -classloaders -jndi -jmx -rpc -anything else provided by the container servlet engines provide exactly this isolation between webapps. There is no point redoing this in axis, as all we'd end up doing is reinventing stuff and chasing security issues wherever we missed a bit. And then we still wouldnt integrate properly with the isolation provided by the hosting app server. Its easy to add axis.jar to an existing webapp. lets stick with what is known, working and documented. Y'all should review Isolates (JSR 121) to see if your use case(s) are covered - Isolates will part of JDK 1.5. http://www.jcp.org/en/jsr/detail?id=121 Bill de hÓra
