Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (herse.apache.org: domain of davanum@gmail.com designates
 64.233.184.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=D+4nffBxj0GHWze7SNkWFIust1Ilb7qNiYbKx8zmsJgiVHkH2SHKJ3qJlEMku+x+fXCr5aFST+3+hvqUrA8/PsJwiSIugb/26qv29zuGuqaom5nGRXclwHbEidFkwKneqnOjih3hQMCufvZ6Gp3MgHUiRUEKV8C+e62VvI+ZFh4=
Message-ID: <19e0530f0702150313s7ef586e3w5b8685dd926d4785@mail.gmail.com>
Date: Thu, 15 Feb 2007 06:13:01 -0500
From: "Davanum Srinivas" <davanum@gmail.com>
Reply-To: dims@apache.org
To: axis-dev@ws.apache.org
Subject: Re: [axis2] AXIS2-2120 Metadata Exchange support [Moved discussion to
 dev list as requested]"
In-Reply-To: 
 <OF7083D839.015A997E-ON85257282.00643BB2-85257282.006490B9@us.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <19e0530f0702132321ka326648y90822ec4aae4848e@mail.gmail.com>
	 <OF7083D839.015A997E-ON85257282.00643BB2-85257282.006490B9@us.ibm.com>

Sanka,

As a practical matter, why dont you checkin the code and Gee can send
in patches  against the head?

thx,
dims

On 2/14/07, Gee Chia <geechia@us.ibm.com> wrote:
>
> Dims, Sanka, and Everybody:
>
> Thanks for your feedback! Also, thanks  Sanka for reviewing the code in depth and his suggestions!
>
> Regarding Data Locator examples, I have described three examples: Default Axis2 Data Locator Example, Plug-in Service Level Data Locator Example, and Plug-in Service Level WSDL-specific Locator Example in the Apache Metadata Exchange User's Guide, and the link is : http://wiki.apache.org/ws-data/attachments/Axis2(2f)metadataExchange/attachments/C__Development_EmergingTech_document_Axis2MEXUserGuide.htm
>
> Please check if the examples provided are sufficient? I look forward for your suggestions to make this clear and helpful for user
>
> About the package naming conventions .. Sorry, I missed the use of lower cases package naming, I will take care of this.
> About the "dataretrieval" package qualifier, how about change to "datalocator"? I am all for good naming convention. Please let me know if you have one.
>
> Concerning the metadataExchange module to support WS-Transfer Get operation issue, I would like to explain why MEX module is not  (and probably should not) supporting it, and how the MEX patch implementation can fulfill the metadata retrieval via Transfer-Get request requirement.
>
> As described in the WS-MetadataExchange Version 1.1 August 2006 specification @: http://schemas.xmlsoap.org/ws/2004/09/mex/), the Web service Metadata element is a collection of metadata units such as WSDL definitions, XML Schema document,  WS-Policy expressions, etc. The units within the collection are represented by MetadataSection elements. A unit of metadata i.e. a MetadataSection element may be included in-line, or may be included by reference, either as an endpoint reference  (MetadataReference element) or a URL (Location element).
>
> Here is the definition in the WS-MEX spec about MetadataReference:
>
> /mex:Metadata/mex:MetadataSection/mex:MetadataReference
> This is an endpoint reference to a metadata resource and is of type EndpointReferenceType as defined by [WS-Addressing 2004,] or EndpointReferenceType as defined by [WS-Addressing 1.0 Core]. The resource MUST support the GET operation [WS-Transfer] to allow the retrieval of the metadata unit for the Metadata Section's Dialect and Identifier (if any). When this element is present, it MUST have no element siblings.
>
> Basically, the MEX module is responsible to return MetadataReference that contains an endpoint reference to a metadata resource that support WS-Transfer Get operation. The metadata resource's  endpoint could be different from the Service that metadata is to be retrieved and MEX module should not be responsible to understood the Transfer-Get operation.The Metadata resource's endpoint could be any mechanism such as a Transfer-Get module or a Service that supports Transfer-Get operation.
>
> In the MEX patch, the plan is to support definition of EndpointReference in ServiceData.xml (definition of metadata associated to the service) for  the MetadataReference content, and it is the developer's  responsibility to define an metadata resource endpoint that supports the GET operation.
> Basically, supporting Transfer-Get is NOT MEX module's responsibility, but MEX is responsible to answer the MetadataReference that contains metadata resource endpoint that understood Transfer-Get operation.  We can discuss  about providing some mechanism such as a light weight module that understood Transfer-Get operation separately.
>
> I have looked at  the changes Sanka made in the MexMessageReceiver in handling of the Transfer-Get operation. My concern with this approach (in addition to what I said above) is also there is no way to specify a particular metadata type (@Dialect) and identifier (@idenfitier) to retrieve.
>
> Again, thanks and please let me know if you have questions. I appreciate and will consider your suggestion for a better MEX solution.
>
>
>  Regards,
>
>  Gee Chia
>  Emerging Standards Development
>  geechia@us.ibm.com
>
>
>
>
>  "Davanum Srinivas" <davanum@gmail.com>
>
> 02/14/2007 02:21 AM
>
> Please respond to
>  axis-dev@ws.apache.org
>
>
> To axis-dev@ws.apache.org
>
> cc
>
>
> Subject Re: [axis2] AXIS2-2120 Metadata Exchange support [Moved discussion to dev list as requested]"
>
>
>
>
>
>
>
>
> Gee,
>
>  Please review Sanka's changes and comment. If there is a good sample
>  and/or testcases for the DataLocator concept that will be very welcome
>  as well. One more thing to do would be to update our documentation
>  with the concepts and its application. Since Sanka is happy, i'm happy
>  :)
>
>  One small nit from me, please use all lowercase in the package name
>  ("dataRetrieval"). Is there a better name other than dataretrieval? Am
>  sure we will continue to tweak even after we check in the code :)
>
>  thanks,
>  dims
>
>
>
>  On 2/14/07, Sanka Samaranayke <ssanka@gmail.com> wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  >
>  > Hello Everyone,
>  >
>  > I've reviewed the uploaded patch and it looks good to me except for
>  > few minor errors. ( I've fixed them and uploaded the files to the JIRA).
>  >
>  > IMO, the DataLocator concept makes lot of senses. Perhaps Gee could
>  > provide few concrete scenario that demonstrate the use of
>  > DataLocators, to ensure we fully understand it before committing it to
>  > the codebase.
>  >
>  > However the MetadataExchange module has a limitation where it doesn't
>  > support WS-Transfer based metadata requests. However there is a
>  > workaround. Since the wsa:To of the WS-Transfer based metadata
>  > requests ends with '/metadata', you can rename the control operation
>  > of the module to 'metadata' s.t. any of those requests are dispatched
>  > to that operation via RequestURIBasedOperationDispatcher. Then you can
>  > check whether the soap action is equal to WS-Transfer-Get action and
>  > process appropriately.  (The MexMessageReceiver and module.xml with
>  > the suggested changes are also uploaded)
>  >
>  > Thanks,
>  > Sanka.
>  >
>  >
>  >
>  >
>  >
>  >
>  > Gee Chia wrote:
>  > >
>  > > Hi, All:
>  > > I moved the discussion in JIRA 2120 to dev list as requested by Dims.
>  > > Thanks in advance for your input and comment  for a better MEX
>  > > support on Axis2.
>  > >
>  > >
>  > > _Davanum Srinivas_
>  > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dims>
>  > > [07/Feb/07 06:28 AM]
>  > > Gee,
>  > >
>  > > Could you please check if you can avoid touching the kernel module.
>  > > We have some code here if you want to take a peek at.
>  > > _
>  > > __http://wso2.org/projects/commons/mex_
>  > >
>  > > thanks,
>  > > dims
>  > >
>  > >
>  > >
>  > > _Gee Chia_
>  > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=geechia>
>  > > [07/Feb/07 10:38 AM]
>  > > Dims:
>  > > I appreciate your reminder to consider different implementation
>  > > alternative.
>  > >
>  > > During the design and implementation of the metadata exchange
>  > > solution, I am trying to consider from different perspectives of how
>  > > Axis2 users/developers might be using the metadata exchange code,
>  > > and also how to fit the solution in the very robust Axis2
>  > > architecture - configurable and easily extensible for supporting
>  > > different data retrieval implementation, and future data retrieval
>  > > requirements. I am hoping to provide a more general data retrieval
>  > > (exchange) code base to address WS-MEX specification requirements as
>  > > well as longer-term needs.
>  > >
>  > > a. Supports extensible set of data i.e. not limited to only WSDL,
>  > > Policy, and Schema. See
>  > > _http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-rt/ws-rt-spec.pdf_
>  > > for an example.
>  > >
>  > > b. Provides hooks for other mechanisms to store/generate the
>  > > metadata i.e. allows Axis2 users to implement specialize data
>  > > retrieval logic instead of using the default Axis2 implementation.
>  > > The plug-in data locator is not MEX-specific. It is about how to
>  > > associate some extra data with a target web service. MEX is just one
>  > > way to access to the data locator to perform metadata exchange.
>  > >
>  > > The data retrieval extends in Axis2 kernel is to provide support for
>  > > data associated with a service, and to provide a way for people to
>  > > plug-in their own implementation for retrieving and/or generating data.
>  > >
>  > > Again, thanks for your attention.
>  > > Gee Chia
>  > >
>  > > _Davanum Srinivas_
>  > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dims>
>  > > [07/Feb/07 12:58 PM]
>  > > Gee,
>  > >
>  > > As a general rule, we *prefer* to talk about "design and
>  > > implementation" here on the axis-dev@ list :) Especially if it
>  > > affects the kernel module. Let me review this a bit more and get
>  > > back to you.
>  > >
>  > > thanks,
>  > > dims
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > Regards,
>  > >
>  > > Gee Chia
>  > > Emerging Standards Development
>  >
>  >
>  > - --
>  > Sanka Samaranayake
>  > WSO2 Inc.
>  >
>  > http://sankas.blogspot.com/
>  > http://www.wso2.org/
>  > -----BEGIN PGP SIGNATURE-----
>  > Version: GnuPG v1.4.2.1 (GNU/Linux)
>  >
>  > iD8DBQFF0q9R/Hd0ETKdgNIRAgwUAJwPp3kcb2yf7stPBz+Pi0t9nLxzjgCgmO/7
>  > rOYIFNw2JROHhlGIcDF3WY4=
>  > =brpE
>  > -----END PGP SIGNATURE-----
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>  > For additional commands, e-mail: axis-dev-help@ws.apache.org
>  >
>  >
>
>
>  --
>  Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>  For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
>
>
>


-- 
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org