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

Paul Fremantle paul at wso2.com
Fri Mar 14 09:57:04 PDT 2008


FYI


-------- Original Message --------
Subject: Re: [esb-java-user] WSO2 Registry search-function / esb 
mediator	dynamic recipient list
Date: Fri, 14 Mar 2008 17:52:23 +0100
From: Jens Goldhammer <goldhammerdev at googlemail.com>
Reply-To: goldhammerdev at googlemail.com, esb-java-user at wso2.org
To: Ruwan Linton <ruwan at wso2.com>
CC: esb-java-user at wso2.org
References: <47DA8F2C.9 at googlemail.com> <47DA9C0C.5020302 at wso2.com>

Hello Ruwan,

see my comments inline.

Ruwan Linton schrieb:
> Jens,
>
> Jens Goldhammer wrote:
>> Hello,
>>
>> 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
>>
>

_______________________________________________
Esb-java-user mailing list
Esb-java-user at wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user


-- 
Paul Fremantle
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair
VP, Apache Synapse

Office: +44 844 484 8143
Cell: +44 798 447 4618

blog: http://pzf.fremantle.org
paul at wso2.com

"Oxygenating the Web Service Platform", www.wso2.com



More information about the Registry-dev mailing list