[prev in list] [next in list] [prev in thread] [next in thread]
List: muse-dev
Subject: Re: Follow up: Muse++ and IBM
From: Daniel Jemiolo <danjemiolo () us ! ibm ! com>
Date: 2006-05-10 15:32:56
Message-ID: OF6F18DE9B.812A6899-ON8725716A.0054AF6B-8525716A.00554524 () us ! ibm ! com
[Download RAW message or body]
--=_alternative 005545218525716A_=
Content-Type: text/plain; charset="US-ASCII"
My iCLA, CCLA, and the software grant have been sent in (perhaps not
processed, though). If it's acceptable to you, I can start
checking/recording the items on the IP clearance form (let me know if
there is a conflict-of-interest here).
Dan
"Davanum Srinivas" <davanum@gmail.com>
05/10/2006 11:01 AM
Please respond to
muse-dev@ws.apache.org
To
muse-dev@ws.apache.org, "Campana Jr., Salvatore J" <sal.campana@hp.com>,
pmc@ws.apache.org
cc
Andrew Eberbach/Durham/IBM@IBMUS, Mark D Weitzel/Raleigh/IBM@IBMUS, James
R Cybrynski/Raleigh/IBM@IBMUS
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&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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
--=_alternative 005545218525716A_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">My iCLA, CCLA, and the software grant
have been sent in (perhaps not processed, though). If it's acceptable to
you, I can start checking/recording the items on the IP clearance form
(let me know if there is a conflict-of-interest here).</font>
<br>
<br><font size=2 face="sans-serif">Dan<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Davanum Srinivas"
<davanum@gmail.com></b> </font>
<p><font size=1 face="sans-serif">05/10/2006 11:01 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
muse-dev@ws.apache.org</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">muse-dev@ws.apache.org, "Campana
Jr., Salvatore J" <sal.campana@hp.com>, pmc@ws.apache.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Andrew Eberbach/Durham/IBM@IBMUS, Mark
D Weitzel/Raleigh/IBM@IBMUS, James R Cybrynski/Raleigh/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: Follow up: Muse++ and IBM</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Sal, Dan,<br>
<br>
We need to make sure that iCLA, CCLA and Software grants are filed.<br>
takes a week for the fax to actually get recorded). Let's also file a<br>
IP Clearance document (http://incubator.apache.org/ip-clearance/) as<br>
well. Once all this is in, you can import the code in SVN.<br>
<br>
w.r.t karma, the usual apache processes apply for voting in new committers.<br>
<br>
thanks,<br>
dims<br>
<br>
<br>
On 5/8/06, Daniel Jemiolo <danjemiolo@us.ibm.com> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> I'm a developer on IBM's Autonomic Computing team, and this is a follow-up<br>
> to the email Sal sent about two months ago with respect to the future
of<br>
> Muse [1]. In that email, Sal alluded to some of the work my team has
been<br>
> doing over the last two years as part of our WSDM enablement strategy;
the<br>
> first thing I'd like to do is provide some background for that:<br>
><br>
> The job of the AC development team is to create reference implementations<br>
> and tools that help partners and customers apply the AC architecture.
The<br>
> most important thing to know about the AC architecture is that it's
based on<br>
> web services standards, the same ones IBM helps to author in OASIS:
WSRF,<br>
> WSN, WSDM, etc. As these specs came closer to ratification, we focused<br>
> increasingly on providing Java implementations of them and Eclipse
tooling<br>
> to help people apply them without being spec experts. The results
of those<br>
> efforts are here:<br>
><br>
><br>
> http://www.alphaworks.ibm.com/tech/aide<br>
><br>
><br>
> The part that would be of interest to the Muse project is what we
call "the<br>
> runtime" - the spec implementations and the core engine that
drives the<br>
> deployment and configuration of WS-resources. Our tooling generates
code and<br>
> artifacts that build on the runtime APIs to create Axis-based web
apps or<br>
> OSGi bundles for WS-resources. Currently we have implemented WSRF
1.2, WSDM<br>
> 1.1, WSN 1.2, WS-MetadataExchange, and WS-A 1.0. We're working on
converting<br>
> to WSN 1.3 CD, upon which WSDM 1.1 is dependent. We've also implemented<br>
> WSDM-for-{JSR-77, JMX, CIM} as part of our product enablement (also
on the<br>
> alphaWorks site).<br>
><br>
> Of course, WSRF/Pubscribe/Muse have been doing similar work, in the
same<br>
> timeframe - why didn't we join these projects before?<br>
><br>
> Unfortunately, I can't say what the answer is. Not because of my NDA,
but<br>
> because I really don't know. It's a big company - sometimes opportunities<br>
> get lost in the shuffle. The AC team, which has put forth the most
effort in<br>
> terms of WSDM implementation and adoption, didn't find out about HP's
plans<br>
> for Muse until the summer of 2005, and by then we were already quite
far<br>
> along in our own runtime/tooling.<br>
><br>
> Despite the parallel effort, one of primary goals has always been
to<br>
> contribute our work to OSS and help grow the WSDM community. When
we were<br>
> far enough along that we felt we had something valuable to contribute,
we<br>
> knew that we didn't want to start off by fracturing the WSDM community,
and<br>
> we wanted the help and experience of other people that had worked
to<br>
> understand and implement the specs over the years. This led to the
talks<br>
> between our team and HP, followed by Sal's email to muse-dev.<br>
><br>
> IBM has now dedicated programmers to contribute to Muse with the hope
that<br>
> it will become the defacto implementation of WS-*, something that
our<br>
> partners, customers, and product teams can rely on. I am one of those<br>
> programmers. Andrew Eberbach (cc'd) is part-time - he also works on
our<br>
> tooling at Eclipse.org. Mark Weitzel (cc'd) is our tooling architect,
which<br>
> means he cares deeply about the direction of Muse but won't do any
actual<br>
> work. ;-) In addition, there are a number of programmers
and architects on<br>
> product teams using our work today and hoping to use Muse in the future.
You<br>
> can expect more support from IBM as products ship with the Muse code.<br>
><br>
> Now for the contributions:<br>
><br>
> I have uploaded our core engine, addressing, utilities, WSRF 1.2,
and WEF<br>
> 1.1 implementations to JIRA. WSDM MUWS 1.1 is also complete (with
a lot of<br>
> helper classes), but because some parts (i.e. Advertisement) depend
on WSN,<br>
> and our WSN 1.3 impl is not stable, we'd prefer to wait a week on
review.<br>
> Also, we will be scrapping our WS-A code in favor of the WS-A module
in<br>
> Axis2.<br>
><br>
> All of the code has been Apache-fied, with the appropriate package
names and<br>
> code scrubbed for IBM/AC names and concepts; if we've missed any,
rest<br>
> assured we'll get to them soon.<br>
><br>
> The code contributions URLs are compiled here:<br>
><br>
><br>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide \
&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10614&component=-1<br>
><br>
><br>
> (If you're not logged in, log in and go to the issues for Muse - ours
are<br>
> under "No Component". There are eight of them so far, with
three more coming<br>
> within two weeks.)<br>
><br>
> A basic design document can be found in doc-design/overview-core.html.
This<br>
> is meant to be a draft based on what we have today; it is NOT meant
to imply<br>
> that we expect everything to just be accepted as-is. We simply modified
a<br>
> current overview doc to use the appropriate Apache names. The WSRF
design<br>
> document has not been Apache-fied yet, so I don't think it would be
terribly<br>
> helpful; I'll be posting that as soon as possible.<br>
><br>
> As far as direction, our chief goals in the past two years have been:<br>
><br>
><br>
> 1. Providing a consistent programming model that works for Axis and
OSGi.<br>
> This will now extend to Axis2, which is the future of SOAP in OSS
(and<br>
> IBM!). We expect our current programming model to change once we start<br>
> working outside closed doors!<br>
><br>
> 2. Automate the enforcement of the spec semantics - assume users don't
read<br>
> specs.<br>
><br>
> 3. Allow shipping products to do WSDM enablement with as minimal intrusion<br>
> as possible. Our team has helped a couple of IBM products create WSDM<br>
> interfaces, so we've also vetted a number of issues related to product<br>
> enablement.<br>
><br>
> 4. Avoid dragging "enterprise" cruft into the WS-* implementation.<br>
><br>
> 5. Encourage users to define resources by aggregating "capabilities";
let a<br>
> "capability" be a POJO (see #4).<br>
><br>
> 6. Allow for disparate state models - make it easy for users to split<br>
> properties between in-memory structures, databases, and { JMX | JSR-77
> CIM<br>
> | SDO } without writing lots of hacks.<br>
><br>
> 7. Provide tooling, but don't *require* tooling.<br>
><br>
> 8. Think about the future - the reconciliation whitepaper that<br>
> HP/IBM/Intel/Microsoft published in March has influenced our design<br>
> significantly.<br>
><br>
><br>
> We'd like to use our overview doc and the above design goals as a
starting<br>
> point for discussions about what's good and what's bad about the code
we've<br>
> contributed. I don't know what the process is for such a review, or
if there<br>
> are other, more basic steps that we have to take before that can happen.<br>
> I'll look to Sal, Bill, dims, and the rest of the Muse devs to point
us in<br>
> the right direction.<br>
><br>
> Thanks for taking the time to wade through this long introductory
email and<br>
> consider our contributions. Our team is really looking forward to
working on<br>
> Muse starting TODAY!<br>
><br>
> Dan<br>
><br>
><br>
> [1]<br>
> http://marc.theaimsgroup.com/?l=muse-dev&m=114123941009921&w=2<br>
><br>
><br>
><br>
> Dan Jemiolo<br>
> IBM Corporation<br>
> Research Triangle Park, NC<br>
><br>
><br>
> +++ I'm an engineer. I make slides that people can't read. Sometimes
I eat<br>
> donuts. +++<br>
><br>
><br>
<br>
<br>
--<br>
Davanum Srinivas : http://wso2.com/blogs/<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org<br>
For additional commands, e-mail: muse-dev-help@ws.apache.org<br>
<br>
</font></tt>
<br>
--=_alternative 005545218525716A_=--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic