ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Campana Jr., Salvatore J" <>
Subject RE: Follow up: Muse++ and IBM
Date Wed, 10 May 2006 15:21:39 GMT

While we are awaiting the documentation coming in, can we initiate the
voting on the lists (with the contingency that all paperwork is in

Or is it preferable to wait for the documentation first? 

-----Original Message-----
From: Davanum Srinivas [] 
Sent: Wednesday, May 10, 2006 11:02 AM
To:; Campana Jr., Salvatore J;
Cc: Andrew Eberbach; Mark D Weitzel; James R Cybrynski
Subject: Re: Follow up: Muse++ and IBM

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


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
> 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 
> 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:
> de=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=1061
> 4&component=-1
> (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
> 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