perfsonar development work

[Cándido Rodríguez Montes <>]

Hi Jeff,

El 04/06/2008, a las 20:11, Jeff W. Boote escribió:

Hi Candido,

I realize that you are fundamentally trying to use pS-base without modification - but given all the complaining I've heard from Java developers about the parsing model in the Java implementation for the past 2 years - I am surprised no one has bypassed it yet. It doesn't look that hard if you are ok just using the dom as provided by axis. (Granted, this solution is probably not appropriate for services that deal with large requests/responses - but I would expect that it should be fine for the AS.)

I think what you need to do to support this is to catch the parsing exception in RequestHandler.java and then don't do the marshaling. You can easily interrogate the message type and initialize your service the same way as the current RequestHandler. Then you would need to modify the the MessageHandlerFactory to support a non-marshaling request handler in place of the marshaling one. And your service method would then need a different method that handled dom instead of the nmwg objects. I'm sure I'm missing a few things in here since I only looked for a couple of minutes and I am not all that familiar with the Java implementation - but fundamentally I don't think it would be that hard to provide service message handlers that deal with dom instead of nmwg objects in parallel with the existing method. 

I think the solution you propose can solve the problem. I can make the changes in perfSONAR base but, first, I want to be sure that the rest of developers agree with it. Anyone has any comment on it?

Regards

I think it is certainly better to fix the implementation than to make decisions on the message format based on the limitations of one implementation - especially when the developers of that implementation want it changed.

jeff

On Jun 4, 2008, at 9:09 AM, Cándido Rodríguez Montes wrote:

Hi Jason and Jeff,

El 03/06/2008, a las 18:35, Jeff W. Boote escribió:

On Jun 3, 2008, at 9:23 AM, Jason Zurawski wrote:

Cándido;

I think the request should be XML and not 'string' data. This would allow services/clients to use the full set of XML api's to look at requests/responses. (Otherwise, why are we messing with this bloated XML stuff anyway?)

Yes, I agree with you but I don't know how to do it. I can have the Document or the String of the <Request> element but how I integrate it in a nmwg message? I guess I should use the org.ggf.ns.nmwg.base.v2_0.Element class but it wasn't work.

So, any help for adding the <Request> element inside an <aa:subject> element? :-)

To do this you would need to add the necessary objects and handlers to the nmwg object structure.

Or stop using the object marshaling model and just use dom directly or perhaps a push-pull model... Not sure where that is on the Java developers plans, but the marshaling model has obviously shown itself to be a pain in more ways than one and I don't think we should be crafting message formats due to this implementation limitation. (Especially given the fact that the main Java developers have already expressed the wish to remove it.)

I think you can use dom directly when you're generating a nmwg message for sending to a perfSONAR service. But, when a pS service receives it, it will launch an exception because it doesn't know how to model the message with nmwg objects. Please, fix me if I'm wrong...

Probably the short-term solution in the Java implementation is as Jason says: Add the needed objects into the nmwg library.

But, in this case, I prefer to use 'string' data. Why? Because I don't want to model all the XACML objects into the nmwg library. Too many objects!

I agree with you that the request should be XML and not 'string' data, but so far, I don't see the way of doing it.

Regards

jeff

--

Cándido Rodríguez Montes E-mail: 

Middleware warrior Tel:+34 955 05 66 13

Red.ES/RedIRIS

Edificio CICA

Avenida Reina Mercedes, s/n

41012 Sevilla

SPAIN

--

Cándido Rodríguez Montes E-mail: 

Middleware warrior Tel:+34 955 05 66 13

Red.ES/RedIRIS

Edificio CICA

Avenida Reina Mercedes, s/n

41012 Sevilla

SPAIN