ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: Follow up: Muse++ and IBM
Date Wed, 10 May 2006 15:01:40 GMT
Sal, Dan,

We need to make sure that iCLA, CCLA and Software grants are filed.
takes a week for the fax to actually get recorded). Let's also file a
IP Clearance document ( as
well. Once all this is in,  you can import the code in SVN.

w.r.t karma, the usual apache processes apply for voting in new committers.


On 5/8/06, Daniel Jemiolo <> wrote:
> Hi everyone,
> I'm a developer on IBM's Autonomic Computing team, and this is a follow-up
> to the email Sal sent about two months ago with respect to the future of
> Muse [1]. In that email, Sal alluded to some of the work my team has been
> doing over the last two years as part of our WSDM enablement strategy; the
> first thing I'd like to do is provide some background for that:
> The job of the AC development team is to create reference implementations
> and tools that help partners and customers apply the AC architecture. The
> most important thing to know about the AC architecture is that it's based on
> web services standards, the same ones IBM helps to author in OASIS: WSRF,
> WSN, WSDM, etc. As these specs came closer to ratification, we focused
> increasingly on providing Java implementations of them and Eclipse tooling
> to help people apply them without being spec experts. The results of those
> efforts are here:
> The part that would be of interest to the Muse project is what we call "the
> runtime" - the spec implementations and the core engine that drives the
> deployment and configuration of WS-resources. Our tooling generates code and
> artifacts that build on the runtime APIs to create Axis-based web apps or
> OSGi bundles for WS-resources. Currently we have implemented WSRF 1.2, WSDM
> 1.1, WSN 1.2, WS-MetadataExchange, and WS-A 1.0. We're working on converting
> to WSN 1.3 CD, upon which WSDM 1.1 is dependent. We've also implemented
> WSDM-for-{JSR-77, JMX, CIM} as part of our product enablement (also on the
> alphaWorks site).
> Of course, WSRF/Pubscribe/Muse have been doing similar work, in the same
> timeframe - why didn't we join these projects before?
> Unfortunately, I can't say what the answer is. Not because of my NDA, but
> because I really don't know. It's a big company - sometimes opportunities
> get lost in the shuffle. The AC team, which has put forth the most effort in
> terms of WSDM implementation and adoption, didn't find out about HP's plans
> for Muse until the summer of 2005, and by then we were already quite far
> along in our own runtime/tooling.
> Despite the parallel effort, one of primary goals has always been to
> contribute our work to OSS and help grow the WSDM community. When we were
> far enough along that we felt we had something valuable to contribute, we
> knew that we didn't want to start off by fracturing the WSDM community, and
> we wanted the help and experience of other people that had worked to
> understand and implement the specs over the years. This led to the talks
> between our team and HP, followed by Sal's email to muse-dev.
> IBM has now dedicated programmers to contribute to Muse with the hope that
> it will become the defacto implementation of WS-*, something that our
> partners, customers, and product teams can rely on. I am one of those
> programmers. Andrew Eberbach (cc'd) is part-time - he also works on our
> tooling at Mark Weitzel (cc'd) is our tooling architect, which
> means he cares deeply about the direction of Muse but won't do any actual
> work.  ;-)  In addition, there are a number of programmers and architects on
> product teams using our work today and hoping to use Muse in the future. You
> can expect more support from IBM as products ship with the Muse code.
> Now for the contributions:
> I have uploaded our core engine, addressing, utilities, WSRF 1.2, and WEF
> 1.1 implementations to JIRA. WSDM MUWS 1.1 is also complete (with a lot of
> helper classes), but because some parts (i.e. Advertisement) depend on WSN,
> and our WSN 1.3 impl is not stable, we'd prefer to wait a week on review.
> Also, we will be scrapping our WS-A code in favor of the WS-A module in
> Axis2.
> All of the code has been Apache-fied, with the appropriate package names and
> code scrubbed for IBM/AC names and concepts; if we've missed any, rest
> assured we'll get to them soon.
> The code contributions URLs are compiled here:
> (If you're not logged in, log in and go to the issues for Muse - ours are
> under "No Component". There are eight of them so far, with three more coming
> within two weeks.)
> A basic design document can be found in doc-design/overview-core.html. This
> is meant to be a draft based on what we have today; it is NOT meant to imply
> that we expect everything to just be accepted as-is. We simply modified a
> current overview doc to use the appropriate Apache names. The WSRF design
> document has not been Apache-fied yet, so I don't think it would be terribly
> helpful; I'll be posting that as soon as possible.
> As far as direction, our chief goals in the past two years have been:
> 1. Providing a consistent programming model that works for Axis and OSGi.
> This will now extend to Axis2, which is the future of SOAP in OSS (and
> IBM!). We expect our current programming model to change once we start
> working outside closed doors!
> 2. Automate the enforcement of the spec semantics - assume users don't read
> specs.
> 3. Allow shipping products to do WSDM enablement with as minimal intrusion
> as possible. Our team has helped a couple of IBM products create WSDM
> interfaces, so we've also vetted a number of issues related to product
> enablement.
> 4. Avoid dragging "enterprise" cruft into the WS-* implementation.
> 5. Encourage users to define resources by aggregating "capabilities"; let a
> "capability" be a POJO (see #4).
> 6. Allow for disparate state models - make it easy for users to split
> properties between in-memory structures, databases, and { JMX | JSR-77 | CIM
> | SDO } without writing lots of hacks.
> 7. Provide tooling, but don't *require* tooling.
> 8. Think about the future - the reconciliation whitepaper that
> HP/IBM/Intel/Microsoft published in March has influenced our design
> significantly.
> We'd like to use our overview doc and the above design goals as a starting
> point for discussions about what's good and what's bad about the code we've
> contributed. I don't know what the process is for such a review, or if there
> are other, more basic steps that we have to take before that can happen.
> I'll look to Sal, Bill, dims, and the rest of the Muse devs to point us in
> the right direction.
> Thanks for taking the time to wade through this long introductory email and
> consider our contributions. Our team is really looking forward to working on
> Muse starting TODAY!
> Dan
> [1]
>  Dan Jemiolo
>  IBM Corporation
>  Research Triangle Park, NC
>  +++ I'm an engineer. I make slides that people can't read. Sometimes I eat
> donuts. +++

Davanum Srinivas :

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message