ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Follow up: Muse++ and IBM
Date Wed, 10 May 2006 15:30:21 GMT
No need to wait...if collectively (all the existing committers) you
think they are ready willing and able :) that's good enough.

On 5/10/06, Campana Jr., Salvatore J <sal.campana@hp.com> wrote:
> Dims,
>
> While we are awaiting the documentation coming in, can we initiate the
> voting on the lists (with the contingency that all paperwork is in
> order)?
>
> Or is it preferable to wait for the documentation first?
>
> -----Original Message-----
> From: Davanum Srinivas [mailto:davanum@gmail.com]
> Sent: Wednesday, May 10, 2006 11:02 AM
> To: muse-dev@ws.apache.org; Campana Jr., Salvatore J; pmc@ws.apache.org
> 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 (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 <danjemiolo@us.ibm.com> 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&mo
> > 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
> 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: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
>
>


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

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org


Mime
View raw message