You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by Daniel Jemiolo <da...@us.ibm.com> on 2006/05/08 17:19:05 UTC
Follow up: Muse++ and IBM
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. +++
Re: Follow up: Muse++ and IBM
Posted by Davanum Srinivas <da...@gmail.com>.
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 <sa...@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 <da...@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
Re: Follow up: Muse++ and IBM
Posted by Daniel Jemiolo <da...@us.ibm.com>.
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" <da...@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" <sa...@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 <da...@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
RE: Follow up: Muse++ and IBM
Posted by "Campana Jr., Salvatore J" <sa...@hp.com>.
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 <da...@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
Re: Follow up: Muse++ and IBM
Posted by Davanum Srinivas <da...@gmail.com>.
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 <da...@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
Fwd: Follow up: Muse++ and IBM
Posted by Davanum Srinivas <da...@gmail.com>.
FYI
---------- Forwarded message ----------
From: Daniel Jemiolo <da...@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 <ae...@us.ibm.com>, Mark D Weitzel
<we...@us.ibm.com>, James R Cybrynski <cy...@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/