Hi Jens,
Thank you very much for the very descriptive explanation. I am copying
the registry-dev list as well since this functionality has to go on to
the registry so that we can leverage that to support the Recipient List
extraction.
I think that your suggestion can be easily done by writing a WSDL media
type handler to handle the WSDLs inside registry in this manner.
Unfortunately I didn't have time to look in to the Atom mediator
extension, but I have done some researches on WS-Eventing and I think we
can use that as you once suggested in the Synapse list.... I will get
back to you on this.
Thanks,
Ruwan
as point out ealier I have some knowledge about the ibm websphere
registry and repository. There is a really nice feature in it- a
search function based on xpath to get e.g. several endpoints of
services which implement the same wsdl interface (porttype). This
function can be used dynamiccal inside the websphere esb to have an
endpoint lookup. To have a good performance in runtime, the
developers shredder the wsdl-file after uploading and hold all
artifacts in a database to get back results quickly.
I am sorry, can you please explain this a bit more in detail?
Ok, I think you are interested in the shreddering-part. As far as I
know, the uploaded wsdl-file will be parsed and all relevant metadata
like wsdl:types, wsdl:interfaces, wsdl:messages and so on will be
extracted from it, so that you have several database tables which hold
fragments of the wsdl-file . The developers have coded a complete
object hierachy where all entries in the registry are a baseObject and
become specific objects depending on their type (wsdl, xsd, policy
etc.). For more information look at :
http://publib.boulder.ibm.com/infocenter/sr/v6r1/index.jsp?topic=/com.ibm.sr.doc/programguide06.html
Code-sample of wsrr-api to query it:
graphQuery.setQueryExpression("/WSRR/[EMAIL PROTECTED]'http://com.ibm.wsrr.samples/']");
List results = serviceRegistry.executeQuery(graphQuery);
If you specifies the xpath-expression like
/WSRR/[EMAIL PROTECTED]"http://com.ibm.wsrr.samples";'], you
will get all wsdl documents which have this namespace. I don´t know
the implementation details, but I think, they will make a reference in
database which wsdl-documents have this certain namespace and you will
get a java list of objects which represent the wsdl documents.
I have following use case in my mind: You want to get all soap 1.1
endpoints which implemented a certain porttype to send them a copy via
the clone-mediator.
In WSRR you can get all wsdl services by typing
/WSRR/WSDLService[portType="StockQuotePortType"]... Maybe this can be
enhanced by having endpoint at the end of the xpath expression.
query:
#/WSRR/WSDLService[portType="StockQuotePortType"]/endpoint[type=soap1.1]#
and you will get a list of soap 1.1 endpoints which implement this
portType.
By having the possibility to import parts of a wsdl into another, you
can have an abstract wsdl-document with types, messages and portTypes
and two or more definite wsdl-document which import the abstract one
and provide different endpoints and bindings.
example:
*StockquoteInterface.wsdl:*
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://com.ibm.wsrr.samples/";
xmlns:tns="http://com.ibm.wsrr.samples/";
xmlns:xsd1="http://com.ibm.wsrr.samples/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
<types>
<schema targetNamespace="http://com.ibm.wsrr.samples/";
xmlns="http://www.w3.org/2001/XMLSchema";>
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
</definitions>
*StockQuoteBinding.wsdl:*
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://com.ibm.wsrr.samples/";
xmlns:tns="http://com.ibm.wsrr.samples/";
xmlns:xsd1="http://com.ibm.wsrr.samples/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
<import namespace="http://com.ibm.wsrr.samples/";
location="StockQuoteInterface.wsdl"/>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation
soapAction="http://com.ibm.serviceregisty.samples/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
</definitions>
*StockQuoteService.wsdl:*
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://com.ibm.wsrr.samples/";
xmlns:tns="http://com.ibm.wsrr.samples/";
xmlns:xsd1="http://com.ibm.wsrr.samples/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
<import namespace="http://com.ibm.wsrr.samples/";
location="StockQuoteBinding.wsdl"/>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address
location="http://com.ibm.wsrr.samples/stockquote"/>
</port>
</service>
</definitions>
In this case you can have several StockQuoteServices which only import
The StockQuoteBinding and provide different endpoints. Maybe this is
completly unnecessary because you can completly include this into one
wsdl-file. But you can insert more endpoints later without changing
something. In case you have one wsdl document you have to insert the
endpoint. The problem indeed is the same: How can I effiently search
in the wsdl-files to get several endpoints back depending on my needs?
I think, the wsrr makes this in a very good way. In Synapse you have
the wsdl-endpoint which parses the wsdl document and return an
endpoint for a certain port and servicename.
I think, a clone-mediator only makes sense to send messages to
endpoints which understand the soap message by implementing the same
wsdl interface (portType in 1.1). So I think the approach above would
scope that. This is only one side of having a dynamic recipient list.
Another point is to let the services register dynamically on the esb.
I have seen that in JBOSS Esb where started services register on the
esb with a config message after deploying them. Do you have any idea
to this? Does this makes sense? You have thought of extending the
atom-mediator. Any update for this?
I hope, my sentences are clearer now.
Your rest interface seems to be very good (I haven´t tested it yet),
but this implies to know the real url of a ressource, e.g. an
endpoint for a service and the numbers of endpoints. For a more
dynamic use I would prefer these search functions. Additionally,
this would help to implement the dynamic recipient list where
synapse can dynamically get the recipients for the clone-mediator....
This seems cool, actually we had a requirement on specifying the
targets for the clone mediator dynamically and I think this would
address that. Thanks for the information.
The user only provides the xpath-expression and Synapse takes the rest.
Again, are you referring to the clone mediator case here? if not can
you please explain what you exactly meant here?
Yes, I thought of the clone mediator.
Thanks,
Jens
Thanks,
Ruwan
Good idea or not?
Thanks,
Jens
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
