A runtime mapping should suffice for 2.x, when the specs aren't ratified 
(so no one should be using it in production). I don't think the OASIS 
vendors want to push a "conversion", just upgrades - the OASIS specs will 
still be valid and supported, but future WS-* development will be done on 
the RS. We don't want to force people to "migrate" if the WSRF/WSDM 
interfaces are working for them - we only want to add the RS in the case 
where they want to interop with new software from, say, Microsoft or other 
vendors. For the next major version, we should aim to have no runtime 
mappings, giving clear distinction between the use of 2.x vs. 3.x.

Dan




Balan Subramanian/Raleigh/[EMAIL PROTECTED] wrote on 07/10/2006 04:51:16 PM:

> 
> The mapping from RS to WSRP/WSDM: would it be a runtime mapping ? Is a 
> conversion utility possible / needed? 
> 
> Balan Subramanian 
> Autonomic Computing, IBM, RTP, NC
> 919.543.0197 | [EMAIL PROTECTED]
> 
> 
> 
> 

> 
> Daniel Jemiolo/Durham/[EMAIL PROTECTED] 
> 07/10/2006 03:55 PM 
> 
> Please respond to
> [email protected]
> 
> To
> 
> [email protected] 
> 
> cc
> 
> Subject
> 
> roadmap for reconcilation specs and WS-*
> 
> 
> 
> 
> In our last call, I said I would start a discussion thread on how Muse 
> will handle the "reconcilation specs" that are being authored by 
Microsoft 
> and OASIS supporters. These specs are supposed to allow WSRF/WSDM users 
> and WST/WS-Man users to live in harmony and interoperate and all of that 

> fun stuff. And while many of today's WSRF/WSDM adopters will not need to 

> move to these new specs (at least not right away), they will have 
support 
> of Microsoft and OASIS vendors, and we should not ignore them if we want 

> Muse to be relevant to web services developers after 2007 or so. What 
> follows is my initial proposal for how Muse's development plan should 
> reflect the publication of the reconciliation specs ("RS"):
> 
> In Muse 2.x, we will ship an implementation of the RS as a "feature 
> preview" (or whatever people want to call it). The code will be 
> continually updated as new drafts of the specs are published. We will 
make 
> it clear that until ratification of the RS, the WSRF/WSDM APIs and 
> implementations are the only things we support full-time. The 
development 
> strategy for the RS implementation should be a mapping of RS to 
WSRF/WSDM; 
> assuming the authoring companies are correct in their assertion that the 

> RS will be feature-compatible with the OASIS specs, this should not be a 

> major problem (albeit challenging at times). This will allow WSRF/WSDM 
> users to augment their applications with the RS interfaces without 
> breaking interop with existing clients. It will also allow mean that the 

> majority of the RS implementation is a previously-tested WSRF/WSDM 
> codebase rather than completely new code.
> 
> We continue to ship the feature preview and Muse 2.x until the 
> reconcilation specs are a) in a standards body and b) reasonably close 
to 
> ratification. The last release of Muse 2.x should include an 
> implementation of the RS that is compliant with the ratified specs. We 
can 
> deprecate the WSRF/WSDM APIs in this last version of 2.x to indicate the 

> changes that are coming in Muse 3.x.
> 
> In Muse 3.x, we provide only the RS implementation, without the 
underlying 
> mapping to WSRF/WSDM. This will require that we repackage/rename some 
old 
> code to fit with the RS interfaces we have developed. The implementation 

> will now be "clean", without any trace of old WSRF/WSDM conventions or 
> inefficient mapping strategies. Users who have no need for the RS or who 

> need to support both worlds can stay happily on Muse 2.x. Users who only 

> want to support the RS can use Muse 3.x. This should allow us to meet 
the 
> needs of all users that are implementing WS-* over the next 2-3 years.
> 
> Obviously, it is hard to make a concrete roadmap without knowing all of 
> the spec publication dates. However, I think it's a good idea to start 
> discussing this now so that our project can remain relevant even as 
> standards bodies and vendors change direction.
> 
> Dan
> 
> 
> 
> Dan Jemiolo
> IBM Corporation
> Research Triangle Park, NC
> 
> 
> +++ I'm an engineer. I make slides that people can't read. Sometimes I 
eat 
> donuts. +++
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to