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]
