axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gee Chia <geec...@us.ibm.com>
Subject Re: [axis2] AXIS2-2120 Metadata Exchange support [Moved discussion to dev list as requested]"
Date Fri, 16 Feb 2007 14:15:18 GMT
Dims, Sanka, everybody:
Just want to confirm if  you ok with NOT adding Transfer-GET to metadata 
exchange module? (Please see my previous note for why metadata exchange 
module should not support Transfer-GET)

Also, regarding the  "dataretrieval" package qualifier, I think to just 
keep "dataretrieval" because it is more general for grouping data 
retrieval implementation for now and future. Please let me know if you 
have better naming soon as I would like to change the current 
"dataRetrieval" to all lower case convention.

Thanks!

Regards, 

Gee Chia
Emerging Standards Development
geechia@us.ibm.com




"Sanka Samaranayake" <ssanka@gmail.com> 
02/15/2007 06:31 AM
Please respond to
axis-dev@ws.apache.org


To
axis-dev@ws.apache.org, dims@apache.org
cc

Subject
Re: [axis2] AXIS2-2120 Metadata Exchange support [Moved discussion to dev 
list as requested]"






+1 !!

I will do it shortly ..

Best,
Sanka

On 2/15/07, Davanum Srinivas <davanum@gmail.com> wrote:
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 




-- 
Sanka Samaranayake
WSO2 Inc.

http://sankas.blogspot.com/
http://www.wso2.org/ 

Mime
View raw message