RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
Hi Steven,
Try to steer the discusion past that one (or around it), so that we can get to the next problem:
The purpose of the BOF is to explore if there is interest in developing a second OGSA profile. I don't see this as a discussion point within the BoF unless their is overlap.. and isn't this what the GFSG examines?
- When I sent that e-mail the agenda was not that clear, and in fact it still isn't -- it's time for a formal agenda listing what is going to be discussed, and especially what is *not* going to be discussed. Notice that I posted that e-mail as an attempt to make things clearer, and I'm saying that this subject is improductive and worth avoiding. - The word "second" above is important, because that's when it stops being "only one". So if the session leaders don't take care the "(1) Are multiple base profiles OK to begin with?" subject will come up, directly or indirectly, and a lot of time will be wasted in religious discussions among people who disagree with the GFSG policy.
(3) What are the plans for the "WS-I-only" profile?
What is being proposed is not a WS-I only OGSA profile. WS-I (basic & security profiles) define a set of specifications and how
Just to clarify, the use of quotation marks above was intentional due to the lack of a name, and I agree with what you said.
I agree multiple basic profiles are bad idea wrt interoperability and architecture perspective.
But may be critical to wider grid adoption which is why I believe GGF accepts multiple approaches. IMHO it is a pity that this policy still seems to be resisted... may be we should drop the O in OGSA?
Recall, that the 'OGSI profile' did not gain wide adoption. Exploring different approaches can only help to improve understanding. What is important IMHO is to bring all approaches into a standards process so that whatever mechanisms that are used are defined. Once defined natural selection can drive their evolution.
I won't be able to go to the MWS-BOF (I'll be in the OGSA-EGA session), so I'll leave my opinion registered here, very briefly. The risk is that if we leave it for the market to decide, the market won't choose against one or another profile, but it will choose against OGSA as a whole. The people willing to pay for OGSA functionality won't be able to get different components from different parties to work together because they won't fit the same profile, won't speak the same protocols, etc.. The fact that the architecture is theoretically unified will mean nothing because, from their point of view, in practice things simply do not work, period. OGSA as a brand will be meaningless. Who wins then? I have a few guesses, but I am not stupid enough to list them in public forum. Being sarcastic, on the letter "O", perhaps the GGF was truly Open around GGF6, when OGSA was just an architecture among many, nothing special. But the GFSG chose it as the "flagship architecture" of the GGF, stating at least a preference. Allowing multiple profiles without preferences moves things back in the direction of GGF6, which for some people is wonderful, and for others, disastrous. (Again, I'm being sarcastic, don't waste your time taking this too seriously). Regards, Fred Maciel Consensus is the absence of leadership -- Margaret Thatcher
Fred Maciel wrote:
Being sarcastic, on the letter "O", perhaps the GGF was truly Open around GGF6, when OGSA was just an architecture among many, nothing special. But the GFSG chose it as the "flagship architecture" of the GGF, stating at least a preference. Allowing multiple profiles without preferences moves things back in the direction of GGF6, which for some people is wonderful, and for others, disastrous. (Again, I'm being sarcastic, don't waste your time taking this too seriously).
Isn't it obvious? Flagships are there for the enemy to shoot at. Speaking seriously, I would be interested to see some kind of strawman alternative architecture to the current "blessed" one; the differences would be most instructive[*]. On the other hand, I can say for sure that I won't be putting any effort into developing such a thing in the short term (few months) and probably not in the medium term (few years) either. But should this be done by a working group...? Donal. [* I suspect that the full sweet spot of the blessed version isn't there in this other combination, but would be happy to be proved wrong. ]
(3) What are the plans for the "WS-I-only" profile?
What is being proposed is not a WS-I only OGSA profile. WS-I (basic & security profiles) define a set of specifications and how
Just to clarify, the use of quotation marks above was intentional due to the lack of a name, and I agree with what you said.
I agree multiple basic profiles are bad idea wrt interoperability and architecture perspective.
But may be critical to wider grid adoption which is why I believe GGF accepts multiple approaches. IMHO it is a pity that this policy still seems to be resisted... may be we should drop the O in OGSA?
Recall, that the 'OGSI profile' did not gain wide adoption. Exploring different approaches can only help to improve understanding. What is important IMHO is to bring all approaches into a standards process so that whatever mechanisms that are used are defined. Once defined natural selection can drive their evolution.
I won't be able to go to the MWS-BOF (I'll be in the OGSA-EGA session), so I'll leave my opinion registered here, very briefly.
The risk is that if we leave it for the market to decide, the market won't choose against one or another profile, but it will choose against OGSA as a whole. The people willing to pay for OGSA functionality won't be able to get different components from different parties to work together because they won't fit the same profile, won't speak the same protocols, etc.. The fact that the architecture is theoretically unified will mean nothing because, from their point of view, in practice things simply do not work, period. OGSA as a brand will be meaningless. Who wins then? I have a few guesses, but I am not stupid enough to list them in public forum.
FACT: OGSA is predicated on Web services best practices, tooling, and infrastructure. FACT: Not everyone is enamored with WSRF, meaning that WSRF is unlikely to be "just there" in the tooling and infrastructure anytime soon. OGSA-WG can choose to stick its collective head in the sand and hope that this issue goes away, or it can attempt to address this problem head-on and come up with a solution. This is essentially what this BOF is about. I'll point out that I'll be happy either way: If we decide that it does not make sense to continue this non-WSRF profile, then my group has already produced a pretty high-quality implementation of WSRF on the .NET framework that we'll continue to refine and support. If we as a group decide to move forward with this non-WSRF profile, then we already have some results with an implementation of WS-Transfer we wrote and we'll hopefully have a larger community working on this effort. Finally, to twist things around, if this effort is squashed solely because WSRF is "first to market", then... to quote Fred: " Who wins then? I have a few guesses, but I am not stupid enough to list them in public forum." Again, to stress, I personally just want convergence. If the group decides that OGSA would better converge by focusing on WSRF, then I will happily support this decision (in fact, my research group's lives would probably be easier!) I just want this decision to be made based on realistic and technically sound evidence, not religion. -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia
participants (3)
-
Donal K. Fellows -
Fred Maciel -
Marty Humphrey