[Registry-dev] Re: [esb-java-user] WSO2 Registry search-function / esb mediator dynamic recipient list

Ruwan Linton ruwan at wso2.com
Fri Mar 14 11:10:10 PDT 2008


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/WSDLDocument[@namespace='http://com.ibm.wsrr.samples/']"); 
>
>        List results = serviceRegistry.executeQuery(graphQuery);
>
> If you specifies the xpath-expression like 
> /WSRR/WSDLDocument[@namespace="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
>>> Esb-java-user at wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
>>>
>>
>




More information about the Registry-dev mailing list