ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Fwd: Follow up: Muse++ and IBM
Date Mon, 08 May 2006 15:52:01 GMT
FYI

---------- Forwarded message ----------
From: Daniel Jemiolo <danjemiolo@us.ibm.com>
Date: May 8, 2006 11:19 AM
Subject: Follow up: Muse++ and IBM
To: muse-dev@ws.apache.org
Cc: Andrew Eberbach <aeberbac@us.ibm.com>, Mark D Weitzel
<weitzelm@us.ibm.com>, James R Cybrynski <cybrynsk@us.ibm.com>



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. +++



--
Davanum Srinivas : http://wso2.com/blogs/

Mime
View raw message