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 (http://incubator.apache.org/ip-clearance/) 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.
thanks,
dims
On 5/8/06, Daniel Jemiolo <[EMAIL PROTECTED]> 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:
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
