We Keep Coding

Suggestion on approach to compare XMLs (instead of using regex with Java's String replaceAll)

I'm writing a test utility that I intend to use to create artificial traffic to the main application (a Spring Integration based application that has entry points in both JMS based and SOAP services downstream and upstream).
In addition to creating the traffic I want to be able to tell if the application is responding properly (i.e. taking an XML and comparing against a predetermined expected value). I have base XMLs for the different types of responses, but there are dynamic values that based on the situation I need to manipulate to be able to compare against the base source for comparison.
One way to solve it: using the replaceAll method of the String Java class, where I manipulate both source and target XMLs as needed to a logical point where I can determine if the response is valid or not.
I'm interested to know if there is any XML utility framework that provides a more advance set of capabilities to achieve this?
Many thanks

Do the "replace" normalization using an XSLT transformation, then use the XPath 2.0 deep-equal() function (perhaps within the same transformation) to do the comparison with reference results. This enables proper XML comparison semantics, e.g. ignoring insignificant whitespace, or arbitrary distinctions such as single-versus-double quotes.

You could generate jaxb classs for your xml, unmarshal it, and then check the properties of interest. Chances are you already have those classes as your dom objects for your JMS and WS logic, so maybe they need only #XMLRoot anotation on top.
To stay closer to xml, you could use XPath to extract the dynamic bits that you expect.

Skip CXF interceptor for one of the methods in webservices

I have CXF Interceptor that checks field in SOAP header. I want to skip this check for a single method.
Is it possible to do it without parsing soap and checking for method name (for example, annotation).
Thank you!

If you put your interceptor fairly late in the chain (USER_LOGICAL for example), you can grab the BindingOperationInfo object from the exchange to determine which operation was used to process the body. From there, decide wether to look at the SOAP headers or not.

An interceptor gets executed even before CXF has started parsing the xml message (actually I use them to change the xml parser secure factory implementation class :P ), so I think what you need is not supported by the architecture (or at least I am unable to find it, if someone wants to bring some light here I will thank it too).
http://cxf.apache.org/docs/interceptors.html
May you separe your functionality in 2 webservices, each one with different interceptors and validation levels?

Known RPC Protocols to put ontop of JMS

I am developing a distributed system which consists of different components (services) which are loosely (asynchronously) coupled via JMS (ActiveMQ).
Thus I do not want to reinvent the wheel, I am looking for a (well) known protocol / library that facilitates remote procedure calls inbetween these components and helps me deal with method interfaces.
So let's decompose the problem I am already solving right now via dirty solutions:
A consumer component want's to call a service, thus it constructs a request string (hand-written and dirty)
The request string is than compressed an put into a JMS message (dirty aswell)
The request message is than transmitted via JMS and routing mechanisms (that part is ok)
The service first of all needs to decompress and parse the request string, to identify the right method (dirty)
The method gets called and the reply goes like #2 - #4.
So that looks pretty much like SOAP, whilst I think that SOAP is to heavy for my application and further I am not using HTTP at all. Given that I was thinking that one might be able to deconstruct the problem into different components.
Part A: HTTP is replaced by JMS (that one is okay)
Part B: XML is replaced by something more lightweight (alright, MessagePack comes in handy here)
Part C: Mechanism to parse request/reply string to identify operation name and parameter values (that one is the real problem here)
I was looking into MessagePack, ProtocolBuffers, Thrift and so forth, but what I don't like about them is that they introduce their own way of handling the actual (TCP) communication. And bypass my already sophisticated JMS infrastructure (which also handles load balancing and stuff).
To further elaborate Part C above, this is how I am currently handling it: Right know I would do something like the following if a consumer would call a service, let's assume the service takes a text and replies keywords. I would have the consumer create a JMS message and transmit it (via ActiveMQ) to the service. The message would contain:
Syntax: OPERATION_NAME [PARAMETERS]
Method: GET_ALL_KEYWORDS [String text] returns [JSON String[] keywords]
Example Request: GET_ALL_KEYWORDS "Hello world, this is my input text..."
Example Reply: ["hello", "world", "text"]
Needless to say that it feels like hacked-together. The problem I see is if I would be to change the method interface by adding or deleting parameters, I would have to check all the request/reply string construction/deconstructions to syncronize the changes. That is pretty errorprone. I'd rather have the library construct the right request/reply syntax by looking at a java interface and throwing real exceptions on runtime if I do mess up stuff, like "Protocol Exception: Mandatory parameter not set" or something...
Any projects/libs known for that?
Requirements would be
It's small and lightweight and fast.
It's implemented in JAVA
It doesn't serve too many purposes (like some fullblown framework e.g. Spring)

I think this Spring package is what you're looking for. See JmsInvokerProxyFactoryBean and related classes.
From the javadoc:
FactoryBean for JMS invoker proxies. Exposes the proxied service for
use as a bean reference, using the specified service interface.
Serializes remote invocation objects and deserializes remote
invocation result objects. Uses Java serialization just like RMI, but
with the JMS provider as communication infrastructure.

Another .Net consuming a Java WSDL question

This may have already been answered and I just can't find it so feel free to point if needed.
I have a JAVA WSDL endpoint that I can successfully use to generate a reference. I have also used the WSDL sent from the programmers of this end point and again was successful in creating class files to use.
However when I create the objects needed to feed this service, in both cases, I receive an error that he cannot use the payload that I am sending.
Looking at it using the SoapUI tool it seems that his service is expecting some more information in the payload tags that does not seem to make into my classes.
Example: I can create <Tag1></Tag1> but he needs <init:Tag1></init:Tag1>
I don't know where the "init" prefix is getting dropped.
I am using VS 2010 and generating a simple web reference. Any tips would be helpful at this point.

The way I approach these problems is this:
use a same-technology client to connect to the service.
Trace the message on the wire. If ncessary strip out signatures and encryption so that you can get a readable XML message.
now, use the different-technology client (in this case .NET) to build client-side stubs and connect to the service. Trace the message on the wire.
Compare the two, and tweak the different-technology client to get it to match.
I use Fiddler2 to captures the traces of the HTTP messages. If you are not using HTTP then you will need something else.
Keep in mind, what you want is not string equality, but equivalence in the XML infoset.
An element like <init:Tx> may be equivalent to <Tx>, if the default namespace in the latter case matches the init namespace in the former. If you don't quite get what this means, then you need to read up on xml namespaces and get comfortable with the concepts.
In many many cases, I've found that it's XML namespace disagreement issues that cause the lack of interoperability. In one case I found that a missing slash on a namespace (http://foo/bar rather than http://foo/bar/) was enough to cause communication to fail. Figuring out what to tweak in order to get the actual message to match the requirement message is somewhat of a black art - I don't know how to explain it.
in some cases I resort to doctoring the WSDL document to get the different-technology client to do what I want.
good luck.

Yes I have since figured out that using the 4.0 svcutil.exe is the best thing in the world for seeing these issues. Again as I stated in a comment above, I figured out that it was merely a namespace issue and it wasn't .Net that was having the issue but the Java on the other end.
Hopfully this will make it easier to see usinf the specific 4.0 generator...
"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\svcutil.exe" /async http://SomeExternalWeb/ExtService.svc?wsdl /ct:System.Collections.Generic.List`1 /n:*,MyNS.Messaging.Services
I love the class generation over the reference generation any day.

Creating multithreaded Java server and clients, but messages have to be in XML format

I've got to write a multithreaded chat program, using a server and clients but each message sent has to be in XML.
Is it simpler/easier just to write out all the code in java, and then try and somehow alter it so the messages are sent in XMl format, or would it be simpler just to try and go for it in XML and hope it works. I'll admit I don't know that much about XML. :)
Also any links to any relevant online help/tutorials would be much appreciated.
Thanks.

When messing with XML in Java, PLEASE consider using JAXB or something similar. It allows you to work with a normal object graph in memory and then serialize that to XML in one operation (and the other way around).
Manipulating XML through the DOM API is a slow way to lose your sanity, do not do it for any non-trivial amount of XML.
I fail to see what the program being multithreaded or a server have to do with it though...

Check out XStream. You can use this to marshall a normal Java object into XML, and back again into an object, without having to do anything instrusive like define interfaces or specify schema etc. i.e. it works out of the box for objects you already have defined. For most cases it's seamless in its default mode.
XStream produces a direct XML serialised representation of a Java object (i.e. XML elements represent each field of a Java object directly). You can customise this further as/when you require. If you want to define persisted objects in terms of schema (XSD) then it's not appropriate. However if you're transporting objects where persistence is short-term and you're not worried about conforming to some schema then it's definitely of use.
e.g.
Person person = new Person("Brian Agnew");
XStream xStream = new XStream();
System.out.println(xStream.toXML(person));
and conversion from XML to the Person object is similarly trivial.
(note XStream is thread-safe)

There is something called XML RPC. This examples pretty much shows what you're looking for:
http://docstore.mik.ua/orelly/xml/jxml/ch11_02.htm

It would be simpler to use existing XMPP clients and servers and not write your own at all.
If this is in fact homework, then I would suggest writing the client and server as you have suggested, using all java, but use a String as the message. You can then easily add parsing of the string to/from XML when all other parts are working.

I would suggest to also have a look at Betwixt and Digester. For Digester there are some tutorials which can be found in the Digister-wiki. Betwixt provides some pretty good tutorials right on its website.
Additionally to these two tools there is a list of alternatives that can be found in the Reference section of http://wiki.apache.org/commons/Digester/WhyUseDigester

You're on the right page trying to break the task into smaller pieces.