Bug in XSLT SE?

I think I found a potential bug in the XSLT SE, but Im not sure *if* its a bug, and *where* to report it. (OpenESB / OpenJBI components?)

I am trying to use the XSLT SE, in combination with the HTTP BC to create a filter for several operations spread over various services (a canonical schema filter, if you will)

Though in all honesty, I have not gotten very far. Before I describe the situation further, I am trying all this on Glassfish v2 beta 2 (b41d) and openESB Milestone4 (though I have also tried the lastest promoted build)

Here is the situation.

There is a service, let's call it databaseservice for now. It basically has 2 operations; one 'read' operation, which returns a set of records, and one 'modify' operation, which basically modifies a few attributes on a specified record.

The idea is that there are 2 of such databaseservices, each using a slightly different SOAP message format. Now, I want to make something that collects data from these services into a central database. (not an ideal situation, but the whole use-case is too much to explain)

So, to facilitate this, I wan to create a (one or more) XSLT service(s), which translate each databaseservice's own format to a centralized format. I would post a request in teh centralized format to the XSLT service, it would translate it to the dialect for the specific server, execute the call, and translate the response back.

All sounds easy enough, and it works up to a degree. That is. If databaseservice would have had just one operation, it would have worked flawlessly. As it stands now however, I cannot get 2 operations to work.

To be more specific;

- The database service has one WSDL, with 2 operation defined it. (one porttype, and partner/role)

- The XSLT service has one WSDL file, with 2 operations, but I have also tried to use one WSDL for one operation each.

The problem that occurs is, that when I have more then 2 operations invoking the same WSDL (or partnerlink if you will) in my transformmap.xml, it always executes the 'last' defined operation in the transformmap.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<transformmap

xmlns='http://xml.netbeans.org/schema/transformmap.xsd'

xmlns:ns1="urn:centralschema">

<service

xmlns:ns1="urn:centralschema"

partnerLinkType="ns1:CentralDBServicePartnerlink"

roleName="CentralDBServicePartnerlinkRole">

<operation

opName="readOperation"

file="readOperationRequest.xsl"

transformJBI="false">

<invokes

xmlns:ns1="urn:serviceschema"

partnerLinkType="ns1:DBServicePartnerLink"

roleName="DBServicePartnerlinkRole"

opName="readOperation"

file="readOperationResponse.xsl"

transformJBI="false"/>

</operation>

<operation

opName="modifyOperation"

file="modifyOperationRequest.xsl"

transformJBI="false">

<invokes

xmlns:ns1="urn:serviceschema"

partnerLinkType="ns1:DBServicePartnerLink"

roleName="DBServicePartnerlinkRole"

opName="modifyOperation"

file="modifyOperationResponse.xsl"

transformJBI="false"/>

</operation>

</service>

</transformmap>

(note, this is edited to fit example)

So, way I would want to call readOperation on the XSLT , the first transformation would already use the xsl file of the modifyOperation operation (modifyOperationResponse.xsl), this will do nasty things to our databaseservice, in return that XSLT is unable to complete the request-response operation, and timing out the request.

The only way i could see to go around this is to define seperate WSDLs for each operation, both for the centralizedserivce, as for each operation in the dbservice, but I doubt that would work well (more WSDL's binding to same address), not too mention that is just ...not very easy to maintain in a larger environment.

I hope this describes the situation Im in, and the problems Im having. Any help as to if this is a bug or not, or a solution, would be, as always, greatly appreciated.

[4904 byte] By [corstijanka] at [2007-11-27 4:34:07]
# 1
It is not clear to me whether it is a bug or not, but for tracking purposes, please do file a bug on this in open-jbi-components at https://open-jbi-components.dev.java.net/issues/enter_bug.cgi(You need to login to java.net to enter a new bug)Suresh
Suresh-JBIa at 2007-7-12 9:44:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 2

The XSLT SE endpoints as you've defined them will resolve to a single entry in the JBI descriptor, which does not contain the operation name. One entry, one service endpoint. The single entry resolves to the last operation in the XSLT config file.

Create a unique partnerLinkRole in the WSDL for the 2nd operation. Update the XSLT config file by adding the operation with the new role. This should cause a 2nd JBI descriptor entry to be created.

Alternatively, I believe the CASA editor addresses this exact issue when 2 operations share the same partnerLinkType, role, and portType.

Regards,

Kevan

Kevan.Simpsona at 2007-7-12 9:44:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 3
BTW, CASA Editor mentioned by Kevan is available in Open ESB full bundle that includes tools. You can launch it by selecting the service assembly and choosing edit configuration menu.
Suresh-JBIa at 2007-7-12 9:44:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 4

Thanks everyone, I figured it out now :-)

Indeed, as kevan suggested, adding another role for each operation worked well; the CASA editor picked the changes up automatically.

Its still not ideal as my 'centralized' service now actually has several http locations (one for each operation), but at least it works, and it is manageable.

Again, Thanks for the help guys. Definately not a bug..more like lack of knowledge :-)

corstijanka at 2007-7-12 9:44:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...