pub.remote:invoke
wM doc reads “All current pipeline inputs are passed to the remote service.”
Here is my issue. when a local invoke of wm.tn.doc:recognize is done with *node object (XML Node object) in the pipeline, the service returns bizdoc nicely.
The same service wm.tn.do:recognize when invoked remotely over pub.remote:invoke the results are not intact. I see the issue when services like recognize, routeXml with input in the pipleine *node are invoked remotely, the remote service doesnt treat *node object the same way any more.
Remote invocation does seem to convolute the *node object over remote invocation.
Note: TN DB is same for remote invoke and local invoke
The serialization used for remote invoke is the same binary serialization that is used between Developer and IS. Since the parse tree is much larger than the original XML, there is an optimization that serializes a reference to the parse tree stored in the IS session rather than transferring the XML as a tree. Also, since the IS XML parser is streaming, the XML isn’t actually parsed into a tree until there are requests for each element, so doing a remote invoke on a node may actually require work to generate the full parse tree before this larger structure can be serialized.
If you want to pass the actual XML of the node you must convert it back to an XML string and then send the string to xmlStringToXmlNode on the other end.
There are a few other limitations to this serialization, for instance Streams are not automatically serialized into a byte and deserialized back into a Stream.
Fred,
Many thanks.
The intention of the remote invoke is to bypass converting XML Node to XML String using RecordToDocument and DocumentToString services. This will strip the xml name space declarations of the XML content inside the node object if ns declarations are not suplied. I cant supply them coz i dont have them at this in procssing time.
The other approach was to do a wm.tn.docrecognize of the node, and do a bytesToString of the bytes in the bizdoc. This retains all the ns declarations. Having said that to do a recognize, you need TN DB configured locally to the server to do recognize. In my situation TN is only on remote server. This forces me to do a remote invoke of recognize with a node object.
I guessed this would be some serialization/deserialization stuff coz the remote recognize returnes the bizdoc with a mime type of application-x/wmidatabin which is wMish.
You can get the full XML document back from any XML Node.
Do queryDocument/queryXMLNode of the node. The WQL query is doc.src the XQL query is /source(). These will give you the XML string back complete with all the xmlns declarations. I am sure that the XQL implementation does not require the XML to be parsed, it just reads the raw input stream back into a String.
I am unsure of exactly what you get if the node is a sub-node of the tree and there are xmlns declared in a node that is outside of the current node (for instance, if you are using NodeIterator or queryDocument to get a sub-node of the doc first), but I don’t think this is your case.
getDocumentType on every Node/Sub Node works too to retrieve the XMLNS declaration in addition with queryXMLNode. Actually this sets me in correct direction giving me more options to deal with XML Node object.
Where is it documented to use source() for XQL to get the XML string back from XML node ? It is not found in any of the wM docs v4.6 and v6. Otherwise is it some industry standard XQL method supposed to be implemented by all vendors ?
However I dont see source() function/method in the above spec. May be source() is an extensive function provided by webMethods. It is odd hat wM doesnt document on this method. It would be great if Fred can shed more light on this.
I just looked at the 6.1 XMLServicesDevGuide.pdf and none of the webMethods extensions to XQL are listed. They have been in the product since IS version 3.5. I don’t understand how they are not in the documentation and it is certainly my fault. I wrote those methods and managed the IS Team at the time. I know I proofed the manuals, but there is even less on XQL in those manuals than in 6.1.
The regex methods use the same ORO lib that Flow uses for regex in switch labels.
The stringmatch is the same webMethods library that WQL uses.
XQL was largely based on WQL and these methods were features of WQL that did not make it into XQL (which morphed into XPath) which I believed were useful.
Thanks, Fred. I think I found the regex reference in the XQL spec proposal on the 'Net, but I didn’t know about the different flavors or the stringmatch function.
What’s the prognosis for direct support of XPath in a future version? Unofficially and just between us, of course.
As long as you don’t tell anyone, there is a movement afoot to allow IS to run using xerces (IS has supported pluggable parsers, but that doesn’t replace the tree builder), so the actual Node API (which is not public) would become DOM (services that access the XML parse tree would be re-implemented on DOM, so we should have backward compatibility). This would allow layering DOM-based open source implementation on top like XPath and XSLT.
There are a number of sticky points, such as porting the XQL and WQL implementations (or dynamically converting the queries to run in an XPath processor). Once work gets further along and we have a better idea of exactly what incompatibilities or limitations there may be, release scheduling will happen. ie. stay tuned, but not imminent.
