ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Jemiolo <danjemi...@us.ibm.com>
Subject Follow up: Muse++ and IBM
Date Mon, 08 May 2006 15:19:05 GMT
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:


        http://www.alphaworks.ibm.com/tech/aide


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 Eclipse.org. 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:

 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10614&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 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] http://marc.theaimsgroup.com/?l=muse-dev&m=114123941009921&w=2



Dan Jemiolo
IBM Corporation
Research Triangle Park, NC


+++ I'm an engineer. I make slides that people can't read. Sometimes I eat 
donuts. +++


Mime
View raw message