- ogsa-wg - lists.ogf.org

Teleconference minutes - 19 January 2005
by Andreas Savva 24 Jan '05

24 Jan '05

Minutes attached. Gridforge location: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050119/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 19 January 2005 ===================================== * Participants Abdeslem Djaoui (RL) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Steve Newhouse (OMII) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Latha Srinivasan (HP) Ravi Subramaniam (Intel) Jem Treadwell (HP) Minutes: Andreas Savva * Jan 10 and 12 minutes approved with no changes * F2F logistics - Place is Westin at O'Hare airport. - Logistics are not completely worked through yet. Action: Andrew to - Book conference room for the OGSA-WG meeting (3 days: Feb 14-16) - [And an additional one day for the non-OGSA meeting] - And let the group know of the room rate (for staying at the hotel) Action: Hiro will update F2F agenda, etc to reflect discussions and re-post. * GGF13 preparation - Hiro added InfoD to the RM session (now a shared session) and submitted the OGSA scheduling requests to Stacey. - There is a plan to do an EM-related BoF. Stacey should know about it but it is not the job of the OGSA-WG to tell her---the proposed-chairs should do it. Preparation has not progressed to that point yet so Andrew as Area Director will take care of it. Action: Andrew as Area director to send an email to the directors of the relevant Area (SRM: Bill, Stephen) to let them know of the proposed BoF; also to Stacey to reserve a slot. - Andrew mentioned that on the Data call there was a discussion for a similar BoF for Data. * Basic profile review Reference: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… ** Introduction/Front matter - Many changes since the last review. Because the document was still taking form these were not change tracked. The authors will do change tracking for future versions. - Ian re-wrote the Introduction. - Security section by Dave S. - Basic security addition is not reflected in the front matter yet. - Tom fleshed out many compliance statements. - Agreed to track issues via trackers. All comments should be deleted for the next version: either address in the text or move to the tracker, if substantial enough. Action: Andreas to create issues tracker. [Done. https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…] - Submit issues to the tracker directly or to the ogsa-wg list (and someone (probably Andreas) will put in the tracker.) The tracker is set to send mail to the list on addition of new artifacts only. ** Profile Conformance - Conformance targets need update. Probably some of these will be deleted. - Conformance Claim URI: Not defined yet. Reuse the WS-I approach. - There are two different types of statements marked with different prefix letters: {R, E} - [R]: Requirements statement. These are fairly consise. They may restrict but not extend an existing specification. (They should not be used to try and write new specifications.) - [E]: Extensibility points. Call out points where extensions may be made. E.g., where open content might be required. These highlight areas where behaviour may vary. (In a sense these are "warning flags.") ** Addressing - Using submission drafts as base; not trying to actively follow the latest ones. - R1002: Highlights an issue with the current spec.; the use of policy elements. Needs follow up. - R1003: It might be the case that the URL contains the ServiceName but this is not required. This statement is trying to codify the desired behaviour. *** 3.1.5 Resilient References - The intention is to describe ogsi-similar renewable references. - Focus is on capturing the renewable reference aspect and NOT on how to register a name so that it can be resolved. - 'Speculative' addition of rns:resolve since the RNS spec. may provide this operation. - There was a proposal for standardization of renewable references (RR). But it seems to be falling between the cracks of various groups: W3C Addressing group has placed it out of scope; WSRF does not seem to be the right place for it. *** 3.1.6 Reference properties - R1005: This statement will probably disappear into a tracker artifact. It is not easy to test or check. - In terms of terminology note that the profile deals with a particular message exchange. So terms like SENDER and CONSUMER are used instead of CLIENT/SERVER since the latter would describe a relation beyond a specific message exchange. - "Encoding scheme" might be work for a higher level profile. ("Correlateable properties?") *** 3.2 Addressing MIH Includes just boilerplate text for now. Need to think about it and revisit as WS-Addressing progresses. (It is expected that by March the W3C Addressing WG wil have a committee draft for this.) ** Resource embodiment - One major issue here is how far Data requirements can be accomodated while promoting interoperability. It might be good idea to schedule a joint-session with DAIS on this topic at GGF13. *** Resource properties **** 5.1.1 Property names - Qnames to point to the type of a resource property. And assume that the entity retrieving that information knows or can find out what they mean. - (There was a side-argument on why type information cannot be returned in general. Many implications if dynamic resource property elements are allowed and how they should be supported. Might want to record this as an issue but it is not likely to be something that can be solved in this profile.) - (DTDs were also mentioned as an alternative.) **** 5.1.2 Metadata descriptor WSRF has made this optional so it should not be made mandatory here. But it is probably a good idea to make it a separate section to draw out the relevant issues. *** 5.3 Query resource properties - (Issue) Requires XPath 1.0; but there is no standard serialization for an XPath response; so it ends up being implementation dependent. (XPath 2.0 on the other hand defines the response as well.) *** 5.4 ResourceProperty change notification - Might not want to require Topics. (Make no statements about their usage.) - Then they could not be used in a manner compliant to this profile but people could still experiment with them. And the profile could be kept simple for now. - Adding them in a later version would not affect other parts. *** 5.5 Set resource property - Another problematic function. Ordering issues are one typical issue (but there are other related issues discussed in the WSRF TC). - Revisit after checking with likely users: WSDM and possibly GT - Proposal at the moment is to give them the same treatement as Topics: say nothing about them and leave the field open for experimentation. ** 6 Resource lifetime - Not sure how far to mandate support for immediate destruction. - Proposal: A resource that can be created by message exchange should support immediate destruction - Might want to require response by all (even if a resource was statically created). - The semantics are defined by WSRF; not in the profile. In particular there was some discussion on what a destruction message means (in particular a successful reply). - A long discussion on whether to allow other behaviours, e.g., not mandate that a resource has to support this behaviour. It seemed to be due to a misunderstanding and it was agreed that the discussion should be taken offline; revisit in a later call if still an issue. *** 6.4 Notification of pending destruction - Might be something to propose to the WSRF group since it requires functionality not currently specified. ** Security - A first attempt to do a security profile segment. It uses the WS-I basic security profile, HTTP over TLS, and TLS - Note terminology: SENDER/RECEIVER not CLIENT/SERVER since the statements are with respect to message exchange roles as noted earlier. - It is transport-based security: not necessarily session-based--- it could be message-based. This seemed not to come out clearly enough from the text. - Contrast with WS-I basic security profile - WS-I profile statements are that "if something needs to be secured this is how it should be done" while this profile makes statemens on what functionality is required - Restricted authentication to just x509 certs. (And therefore disallowing username/passwd authentication.) This should probably be stated more clearly. ** Other business - Tom has the pen and will produce the next version of the basic profile document.

1 0

[ogsa-wg | Basic Profile - 1211] What must a service satisfy before it can be called an "OGSA service?"
by Sourceforge Tracker Monitor 24 Jan '05

24 Jan '05

A new artifact has been added: 1211 Submitted by: Andreas Savva Submitted date: 2005-01-24 14:39:38 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1211&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1211&group_id…) Summary: What must a service satisfy before it can be called an "OGSA service?" Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1211 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Last Modified: 2005-01-24 14:39:38 Submitted By: Andreas Savva Submit Date: 2005-01-24 14:39:38 Assigned To: David Snelling File(s): <None> Description: [Original slightly edited.] On 11 Jan 2005, at 20:01, Dave Berry wrote: >> The following two statements were made (as >> recorded in the minutes [Jan 10, 2005]): >> >> - An 'ogsa service' must be one that implements the >> profile (or parts of the profile) in the defined >> manner. >> >> - Note that there is no a requirement to implement >> everything in the profile. Often the statements >> are of the in form: >> "if something is done it must be done this >> way" so if something is not implemented all >> the related statements do not apply. >> >> It's not clear from this what constraints MUST be >> satisfied for a service to be called an "OGSA service" - >> can the profile define a minimum set of elements that a >> service MUST implement? >> >> Dave. On 15 Jan 2005, at 07:37, Dave Snelling wrote: > Make sure this gets set as an issue, e.g. tell > Andreas. This is an aspect of Profile that the WS-I > community accept as read, but that we need to spell out. > > Well caught Dave. > View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

RE: [ogsa-wg] FW: Issue #1 proposed resolution
by Savas Parastatidis 23 Jan '05

23 Jan '05

Dear all, I agree with some of what Steve said bellow :-)) The change does make a difference in implementations because if the information that was meant to be included in the Reference Properties is now encoded in the Address property of an EPR (the URI) it cannot be echoed back as SOAP headers. This was part of the semantics of Reference Properties. For a resource-oriented specification like WSRF, however, using URIs to identify resources is a good solution. On this I agree with Steve. The semantics of WSRF do not have to change even if it wasn't abstracted away from WS-Addressing. What is lost is the ability to echo back as SOAP headers any resource-specific information that may be required by a SOAP intermediary to identify the targeted resource. If having SOAP headers is a requirement, though, I don't see why Reference Parameters couldn't be used. So, while Reference Properties have been removed, Reference Parameters are still there and while I would personally like to see them go too, I don't think it'll happen. The semantics of Reference Parameters are slightly different but I don't see why WSRF couldn't use them, if it needed to, instead of Reference Properties to carry resource-specific information. Best regards, -- Savas Parastatidis http://savas.parastatidis.name > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of > Steve Tuecke > Sent: Friday, January 21, 2005 9:55 PM > To: Ian Foster > Cc: 'Stephen Pickles'; 'OGSA-WG'; Steve Tuecke; Djaoui, A (Abdeslem) > Subject: Re: [ogsa-wg] FW: Issue #1 proposed resolution > > As far as I can tell, this decision has basically no effect on WSRF. > The argument being made by some in the WS-A working group is that it is > equivalent and more true to the Web to carry a resource identifier as > part of the EPR address, rather than in a separate ResourceProperties > field -- that is, the resource reference should all be in the URI, > rather than split between a URI and separate resource properties. > Implementation-wise it certainly makes very little difference. And the > WSRF working group had already abstracted the WS-Resource reference and > access pattern, so that it is not tightly coupled to WS-A and reference > properties anyway, so WSRF specification-wise it makes no difference. > > -Steve > > On Jan 21, 2005, at 1:59 PM, Ian Foster wrote: > > > I think the technical term is "carefully architected set of > > specifications" not "house of cards" (-: > > > > Regards -- Ian. > > > > > > At 05:10 PM 1/21/2005 +0000, Djaoui, A (Abdeslem) wrote: > > > > Well, it probably doesn't, because WSRF is now decoupled from > > WS-Addressing > > through the definition of the "abstract" resource Access Pattern, > > which > > defines different embodiments for different ways of accessing state. > > > >

3 3

Last CFP: Workshop on Business Services Networks (BSN)
by Gagnon, Stephane 22 Jan '05

22 Jan '05

Apologies for cross-postings. Please send to interested colleagues and students Last Call for Papers IEEE EEE05 International Workshop on Business Services Networks (BSN) ===================================================================== Hong Kong - March 29, 2005 http://elab.njit.edu/bsn.html Sponsored by IEEE Computer Society Held in Conjunction With IEEE International Conference on e-Technology, e-Commerce and e- Service (EEE-05) ------------------------------------------------------------------ Hong Kong - March 29 to April 1, 2005 http://www.comp.hkbu.edu.hk/~eee05 & The IEEE EEE05 Workshop: Mobility, Agents, and Mobile Services (MAM) -------------------------------------------------------------------- Hong Kong - March 29, 2005 http://voip.csie.ntu.edu.tw/workshop/eee05 Organized by Management Development Center (MDC) Faculty of Business and Information Technology University of Ontario Institute of Technology (UOIT), Canada e-Business Laboratory (eLab) School of Management New Jersey Institute of Technology (NJIT), USA In Cooperation With Academic Partners: e-Centre for Infonomics http://www.infonomics.org.uk AIS SIGeBiz http://citebm.business.uiuc.edu/ebiz AIS SIGPAM http://www.sigpam.org AIS SIGSEMIS http://www.sigsemis.org Industry Partners: Integration Consortium http://www.integrationconsortium.org Object Management Group (OMG) http://www.omg.org Abstract: Business Services Networks (BSN's) are IT infrastructure intermediaries where Web Services can be securely published, reused, and invoked based on Service Oriented Architecture (SOA) standards. They allow vendors to sell their software as a service and offer business users a secure network to compose complex business processes. With proper permissions, users can automate several Business Process Management (BPM) functions such as: (1) analyze their requirements and match them to network resources, (2) model their business processes in a complete architecture, (3) define key operational conditions for processes, (4) execute their processes on the grid, and (5) monitor and manage processes in real-time. In addition, BSN's extend the Enterprise Service Bus (ESB) of each network participant by providing reliable Business to Business (B2B) transaction management and Service Level Agreements (SLA). They also offer exceptional profit opportunities to vendors based on Utility Computing, On Demand, or Pay-Per-Use business models. They effectively represent a new form of e-marketplace where IT resources and business services are the commodities exchanged. Scope: We invite papers that address both business and technical issues of BSN's from various perspectives, including BSN operators, software vendors, business adopters, developers, and end-users. We encourage contributions from both academia and industry. Topics of interest include, but are not limited to, the following: 1. BSN Operators: a. Business Models and Architectures b. Spin-Offs from Outsourcing Providers c. Mobile Operators and Grid Services d. Industry-Specific B2B Integration Alliances e. Inter-BSN Alliances and Interoperability 2. Software Vendors: a. Market Value for Software Vendors b. SOA-Enablement of Software Vendors c. Pricing and Marketing On Demand Software d. Service Level Agreements (SLA) e. Software Vendors from Developing Countries 3. Business Adopters: a. Comparing IT Sourcing Models (BSN, ASP, etc.) b. International Provisioning and Adoption Barriers c. Real-Time Transaction Monitoring d. Quality of Service (QoS) e. Accounting Systems for Utility Computing 4. Developers: a. Process Oriented and Model Driven Architectures (UML, BPMN, MDA, etc.) b. Synthesizing Process, Data, and Component Models (MOF, BPSM, etc.) c. Process Specifications and Execution (WS-CDL, BPEL4WS, etc.) d. Composite Processes with Messages, Documents, and Services e. ebSOA, Business Patterns, and Universal Business Language (UBL) 5. End-Users: a. Service and Process Oriented Application Development Methods b. Intelligent Automated Process Discovery and Composition c. Semantic Web, Ontology Applications, and Domain Specialization d. User Specialization and Automated Coordination e. Security, Privacy, and Trust Keynote Speaker: To be announced. Paper Submission: Please, limit your paper to 8 pages, following the IEEE Computer Society Press Proceedings Author Guidelines: http://www.computer.org/cspress/instruct.htm. We only accept paper submissions in PDF format through our review system: http://elab.njit.edu/bsn. The submission of an abstract is handled by the same system. This is optional and authors are free to submit either or both an abstract and their full paper anytime until January 24, 2005. While our system is a "double-blind" review process, we are happy to confirm that we also accept papers that are formatted for a "one- side-blind" review. In that case, while authors are asked to remove all author information in the paper and PDF file, it may be possible that their work and references clearly reveal the author's identity. We want to reassure authors of "one-side-blind" papers that their work is equally welcomed to the workshop. Our reviewers will be asked to reveal any potential conflict of interest, and in that case they will be assigned other papers. As well, all reviewers will be asked to review both types of papers equally without any discrimination. For any other questions regarding this workshop or its submission and review processes, please feel free to contact workshop chairs directly. Journal Publications: The enhanced version of the selected papers published in the workshop will be invited for publication in: - A special issue on "Business Services Networks" in the International Journal of Cases on Electronic Commerce (IJCEC), Information Resources Management Association (IRMA), USA. It is expected this special issue will be published in October-December 2005. ISSN (Online): 1548-0615 - ISSN (Paper): 1548-0623, http://www.idea-group.com/journals/details.asp?id=4285 - A special issue on "Web Services, Business Processes, and Services Science" in the International Journal of Web and Grid Services (IJWGS), Inderscience Publishers, USA. It is expected this special issue will be published in January-March 2006. ISSN (Online): 1741- 1114 - ISSN (Paper): 1741-1106, https://www.inderscience.com/browse/index.php?journalID=47 - A special issue on "Business Service Management and Service Level Agreement" in the International Journal of Internet and Enterprise Management (IJIEM), Vol. 5, No. 2, Inderscience Publishers, USA. It is expected this special issue will be published in April-June 2007. ISSN (Online): 1741-5330 - ISSN (Print): 1476-1300, http://www.inderscience.com/browse/index.php?journalID=39 Registration: Presenters and participants must register by February 28, 2005. Please use the registration instructions and fees provided on the EEE-05 web site: http://www.comp.hkbu.edu.hk/~eee05/registration. Deadlines: December 25, 2004 Abstract Submission Due (Optional) January 24, 2005 Full Paper Submission Due February 14, 2005 Paper Acceptance Notice Sent to Authors March 1, 2005 Camera-Ready Papers Due March 29, 2005 Workshop Workshop Chairs: Dr. Stephane Gagnon School of Management New Jersey Institute of Technology, USA E-mail: gagnon(a)njit.edu Dr. Patrick C. K. Hung Faculty of Business and Information Technology University of Ontario Institute of Technology (UOIT), Canada E-mail: patrick.hung(a)uoit.ca Steering Program Committee: Prof. Terry Wu Management Development Center (MDC) Faculty of Business and Information Technology University of Ontario Institute of Technology (UOIT), Canada Prof. Anup Kumar CECS Department University of Louisville, USA Prof. Elena Ferrari Dipartimento di Scienze della Cultura, Politiche e dell'Informazione University of Insubria at Como, Italy Prof. Barbara Carminati Dipartimento di Scienze della Cultura, Politiche e dell'Informazione University of Insubria at Como, Italy Dr. Kerry Taylor ICT Research Centre Commonwealth Scientific and Industrial Research Organization (CSIRO), Australia Dr. Casey K. Fung Mathematics and Computing Technology Boeing Phantom Works, USA Dr. Vladimir Tosic Department of Computer Science The University of Western Ontario, Canada Prof. Aoying Zhou Department of Computer Science and Engineering Fudan University, China Prof. Jia Zhang Department of Computer Science Northern Illinois University, USA Prof. Hannes Werthner Honorary President, IFITT University of Innsbruck & EC3 Vienna, Austria Dr. Ravi Bapna Department of Operations and Information Management University of Connecticut, USA Dr. Morad Benyoucef School of Management University of Ottawa, Canada Dr. Oleg Gusikhin Supply Chain Management Research Ford Research & Advanced Engineering, USA Dr. Michael zur Muehlen Wesley J. Howe School of Technology Management Stevens Institute of Technology, USA Prof. Dan Zhang Faculty of Engineering and Applied Science University of Ontario Institute of Technology (UOIT), Canada Dr. Jen-Yao Chung T. J. Watson Research Center IBM, USA Dr. Richard Soley Chairman and Chief Executive Officer Object Management Group (OMG), USA Prof. Pascal Pecquet Editor in Chief, http://www.cyber-gestion.com University of Montpellier I, France

1 0

FW: Issue #1 proposed resolution
by Djaoui, A (Abdeslem) 22 Jan '05

22 Jan '05

Just in case you have not seen this, It appears RefProps will be removed from EPR's. Something we should discuss. Abdeslem ///////////////// -----Original Message----- From: public-ws-addressing-request(a)w3.org [mailto:public-ws-addressing-request@w3.org]On Behalf Of Ugo Corda Sent: 20 January 2005 01:33 To: Mark Little; Mark Baker Cc: public-ws-addressing(a)w3.org Subject: RE: Issue #1 proposed resolution Mark and Mark, It looks like RefProps are gone as of yesterday: see http://www.w3.org/2002/ws/addr/wd-issues/#i001 . Ugo > -----Original Message----- > From: public-ws-addressing-request(a)w3.org > [mailto:public-ws-addressing-request@w3.org] On Behalf Of Mark Little > Sent: Wednesday, January 19, 2005 5:26 PM > To: Mark Baker > Cc: public-ws-addressing(a)w3.org > Subject: Re: Issue #1 proposed resolution > > > > Mark, I have a distinct dislike for RefProps/RefParams, as > you're aware. However, putting my pragmatic hat on for a > moment, I don't see them vanishing in this release of the > specification. That doesn't prevent us from debating their > utility (or lack thereof), but I suspect it would be better > to take it off this mailing list if we're to try to maintain > the timeline that was proposed by the submitters and agreed > upon by the members of the group. Who knows, there may be a > change in a subsequent release? > > Also, I'm not sure why you moved my text around, but it could > change the context of what was originally intended. I didn't > mention the word "identification" at all in the proposed text I said. > > Mark. > > ---- > Mark Little, > Chief Architect, > Arjuna Technologies Ltd. > > www.arjuna.com > > > ----- Original Message ----- > From: "Mark Baker" <distobj(a)acm.org> > To: "Mark Little" <mark.little(a)arjuna.com> > Cc: <public-ws-addressing(a)w3.org> > Sent: Thursday, January 20, 2005 12:26 AM > Subject: Re: Issue #1 proposed resolution > > > > Mark, > > > > On Wed, Jan 19, 2005 at 10:41:53PM -0000, Mark Little wrote: > > > I think the pragmatic view on RefProps/RefParams has to > be that they > will > > > stay (rightly or wrongly, there are implementations and > > > specifications > out > > > there that now rely on them). > > > > This is a new spec we're working on, no? Those implementations can > > continue to depend upon whatever version of the spec they currently > > depend upon. Nothing we do here can break them, AFAICT. > > > > > I agree that the term "identifier" can be > > > contentious. However, so can the term "state". How about just > > > calling it/them "additional information that referencing > > > specifications [aka > using > > > specifications] or implementations need in order to ultimately > > > address > the > > > endpoint service"? > > > > >From my POV, there appears to be agreement to removing the part of > > >the > > spec that talks about using RefProps for identification. > Adding "in > > order to ultimately address" back in would be akin to undoing that > > change. The point of the change, as I see it, is to get > identifying > > information out of the RefPs, and into the URI, and I > consider that an > > enormous improvement over the WS-A submission. > > > > > That way we're not saying *what* goes in there, only > > > *why*. > > > > IMO, identification is a "what". > > > > Mark. > > -- > > Mark Baker. Ottawa, Ontario, CANADA. > http://www.markbaker.ca > > > > >

3 2

RE: [ogsa-wg] FW: Issue #1 proposed resolution
by Djaoui, A (Abdeslem) 21 Jan '05

21 Jan '05

Well, it probably doesn't, because WSRF is now decoupled from WS-Addressing through the definition of the "abstract" resource Access Pattern, which defines different embodiments for different ways of accessing state. Abdeslem /////////////// -----Original Message----- From: Stephen Pickles [mailto:stephen.pickles@manchester.ac.uk] Sent: 21 January 2005 17:05 To: 'Djaoui, A (Abdeslem)'; 'OGSA-WG' Subject: RE: [ogsa-wg] FW: Issue #1 proposed resolution Doesn't this make the whole house of cards (WSRF and OGSA) come tumbling down? Please tell me I'm wrong! Stephen > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Djaoui, A (Abdeslem) > Sent: 21 January 2005 09:47 > To: 'OGSA-WG' > Subject: [ogsa-wg] FW: Issue #1 proposed resolution > > > Just in case you have not seen this, It appears RefProps will > be removed > from EPR's. Something we should discuss. > > Abdeslem > ///////////////// > > -----Original Message----- > From: public-ws-addressing-request(a)w3.org > [mailto:public-ws-addressing-request@w3.org]On Behalf Of Ugo Corda > Sent: 20 January 2005 01:33 > To: Mark Little; Mark Baker > Cc: public-ws-addressing(a)w3.org > Subject: RE: Issue #1 proposed resolution > > > > Mark and Mark, > It looks like RefProps are gone as of yesterday: see > http://www.w3.org/2002/ws/addr/wd-issues/#i001 . > > Ugo > > > -----Original Message----- > > From: public-ws-addressing-request(a)w3.org > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > Mark Little > > Sent: Wednesday, January 19, 2005 5:26 PM > > To: Mark Baker > > Cc: public-ws-addressing(a)w3.org > > Subject: Re: Issue #1 proposed resolution > > > > > > > > Mark, I have a distinct dislike for RefProps/RefParams, as > > you're aware. However, putting my pragmatic hat on for a > > moment, I don't see them vanishing in this release of the > > specification. That doesn't prevent us from debating their > > utility (or lack thereof), but I suspect it would be better > > to take it off this mailing list if we're to try to maintain > > the timeline that was proposed by the submitters and agreed > > upon by the members of the group. Who knows, there may be a > > change in a subsequent release? > > > > Also, I'm not sure why you moved my text around, but it could > > change the context of what was originally intended. I didn't > > mention the word "identification" at all in the proposed > text I said. > > > > Mark. > > > > ---- > > Mark Little, > > Chief Architect, > > Arjuna Technologies Ltd. > > > > www.arjuna.com > > > > > > ----- Original Message ----- > > From: "Mark Baker" <distobj(a)acm.org> > > To: "Mark Little" <mark.little(a)arjuna.com> > > Cc: <public-ws-addressing(a)w3.org> > > Sent: Thursday, January 20, 2005 12:26 AM > > Subject: Re: Issue #1 proposed resolution > > > > > > > Mark, > > > > > > On Wed, Jan 19, 2005 at 10:41:53PM -0000, Mark Little wrote: > > > > I think the pragmatic view on RefProps/RefParams has to > > be that they > > will > > > > stay (rightly or wrongly, there are implementations and > > > > specifications > > out > > > > there that now rely on them). > > > > > > This is a new spec we're working on, no? Those > implementations can > > > continue to depend upon whatever version of the spec they > currently > > > depend upon. Nothing we do here can break them, AFAICT. > > > > > > > I agree that the term "identifier" can be > > > > contentious. However, so can the term "state". How about just > > > > calling it/them "additional information that referencing > > > > specifications [aka > > using > > > > specifications] or implementations need in order to ultimately > > > > address > > the > > > > endpoint service"? > > > > > > >From my POV, there appears to be agreement to removing > the part of > > > >the > > > spec that talks about using RefProps for identification. > > Adding "in > > > order to ultimately address" back in would be akin to > undoing that > > > change. The point of the change, as I see it, is to get > > identifying > > > information out of the RefPs, and into the URI, and I > > consider that an > > > enormous improvement over the WS-A submission. > > > > > > > That way we're not saying *what* goes in there, only > > > > *why*. > > > > > > IMO, identification is a "what". > > > > > > Mark. > > > -- > > > Mark Baker. Ottawa, Ontario, CANADA. > > http://www.markbaker.ca > > > > > > > > > > >

1 0

Scoping for Job Creation and Management
by David Snelling 21 Jan '05

21 Jan '05

Folks, Thanks to Ian for the snippet of GRAM. I'll use it as a basis for my action item to start the scoping exercise for this proposed BoF. 1) I would exclude the delegation stuff. This seems to layer well with GRAM (e.g. it is optional) and therefore should be a separate specification. The combined GRAM and delegation usage pattern would be the subject of a Profile. 2) I believe that the ManagedJobFactory::createManagedJob concept is in scope. I think it should take an open content job description so that the current Globus XML description, JSDL, a "run BLAST" thing , and even run Unicore AJO would all work. The Profile might later mandate that for interoperability only JSDL applies. 3) Now that we have a manageable-job, we need operations on it. From Ian's list, I only have a problem with the implied linkage between release and something the the job description (this is an inhibitor to composition, but that discussion it for the new WG). Some might want other control functions: hold, abort (stops execution but doesn't destroy the resource). This specification should be interoperable from the outset, e.g. no extensibility elements. 4) I agree that the data transfer aspects are out of scope, as is provisioning. A JSDL document (as well as the GRAM equivalent) tells the job container where to get the input files, where to put the output files, and what the source for the executable is. How this happens is not the problem of this interface. 5) The specification should be a WSDL interface and associated semantic description. This doesn't mean that only WSDL based presentations are allowed at the BoF or at the WG, just that the eventual output would be a WSDL spec. 6) The new specification must align and compose with the OGSA Base Profile. There some interesting questions here. The GRAM and Unicore interfaces certainly assume the WSRF infrastructure, but it is clearly possible to build job management web services without WSRF. The WG should discuss the extent to which composition (as opposed to extension) it possible without duplication of function. [Just to clarify: We should not include a 'cancel' operation that does the same function as the Resource Lifetime 'destroy' operation, but if the interface makes sense without either, then the dependancy on lifetime could be relaxed.] It should come as no surprise that I would like to see the whole Basic Profile exploited as much as possible, but that's a discussion for later. 7) Job naming, job migration, job scheduling, scheduling candidates, job placement, job restart/recovery, are all out of scope. Thoughts? Do we have a volunteer to start drafting a BoF Call and Draft Charter? > (Need to verify operation names.)DelegationFactory::createDelegation > This (optional) step allows a client to delegate credentials that > will be required for correct operation of WS GRAM, RFT, or the user's > job process. Such credentials are only used when referenced in the > subsequent job request and under the condition that WS GRAM or RFT is > configured to make use of the DelegationFactory, respectively. > > Delegation::refresh > This (optional) step allows a client to update the credentials > already established for use with the previous createDelegation step. > > > ManagedJobFactory::createManagedJob > This required step establishes the stateful ManagedJob resource which > implements the job processing described in the input request. > > > ManagedJob::release > This (optional) step allows the ManagedJob to continue through a > state in its lifecycle where it was previously held or scheduled to be > held according to details of the original job request. It is a fault > to try to release a hold that was not set in the job request or that > was already released. > > > ManagedJob::setTerminationTime > This (optional) step allows the client to reschedule automatic > termination to be different than was originally set during creation of > the ManagedJob resource. > > > ManagedJob::destroy > This (optional) step allows the client to explicitly abort a job and > destroy the ManagedJob resource, in the event that the scheduled > automatic termination time is not adequate. > > ManagedJob::subscribe > This (optional) step allows a client to subscribe for notifications > of status (and particularly lifecycle status) of the ManagedJob > resource. For responsiveness, it is possible to establish an initial > subscription in the createJob() operation without an additional > round-trip communication to the newly created job. > > > ManagedJob::queryProperty and queryMultipleProperties > These (optional) steps allow a client to query the status (and > particularly lifecycle status) of the ManagedJob resource. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

2 4

Informal OGSA EMS & Data Architecture meetings
by Steven Newhouse 19 Jan '05

19 Jan '05

On the 1st & 2nd of February there will be informal meetings to discuss OGSA EMS and Data Architecture in London, UK. This is an opportunistic meeting due to the presence of various OGSA interested people in London for a meeting on 31/1/05. The meeting will take place at Imperial College in central London. The London e-Science Centre has kindly agreed to host the event in their access grid room - http://www.lesc.ic.ac.uk/resources/accessgrid.html. Some AG access may be available for some of the time. A tentative schedule has been defined: Feb 1st PM: EMS Discussion Feb 2nd AM: EMS Discussion Feb 2nd PM: Data Discussion Dave Berry is co-ordinating the data part of the meeting. I will be co-ordinating the EMS part. Please contact us directly for further information. The motivation behind these meetings are to advance the discussion in advance of the upcoming F2F meeting. Regards, Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

Proposed agenda for Jan. 19th call
by Hiro Kishimoto 19 Jan '05

19 Jan '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on January 19th Wednesday from 5pm to 7pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0119 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval * Jan 10th and 12th calls: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050110/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050112/en/1 Agenda bashing 2) Feb F2F meeting and GGF13 update (10 min) Hiro will submit revised F2F meeting agenda before the call. Andrew will submit F2F logistics if available. Hiro will submit revised GGF13 session plan before the call. 4) Basic profile discussion (90 min) > The latest draft of the OGSA BP has been uploaded to the > 'working drafts/basic profile' folder. > This will be the draft that we will be discussing on the Wednesday > 1/19/05 telecon. After Tom's edit, Dave Snelling added security section and Hiro has made this doc publicly accessible. https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Basic_Profile_dr… n/2 5) Wrap up (10 min) AOB Jan. 24 (5pm-7pm CDT) OGSA v1 and glossary final call & Basic profile discussion Jan. 26 (10am-noon CDT) Data design team Jan. 26 (5pm-7pm CDT) basic EM profile discussion Jan. 31 (5pm-7pm CDT) Basic profile discussion ---- Hiro Kishimoto

1 1

GT4 GRAM Design Details
by Ian Foster 18 Jan '05

18 Jan '05

Dear All: I promised on today's call to send some information on the GT4 GRAM design. Here it is. I'm sure it's not the ultimate answer, but a lot of thought and experience have gone into defining this set of WSRF/WSN-compliant portTypes for job submission and management. Comments and questions would be appreciated. Regards -- Ian. GT4 GRAM The GRAM documentation is at: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/ Architecture and concepts are described at: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/key/WS_… In brief, a "GRAM server" is implemented by a "managed job factory", which responds to requests to create managed jobs, and a "delegation factory", which responds to requests to create delegated credentials. Internally, its implementation uses an RFT server to manage staging of input, executables, and output, including streaming output. The interfaces for the managed job factory and managed job are described here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/… The delegation interfaces are described here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/security/delegati… The only really complex operation is ManagedJobFactory::createManagedJob, which takes as an argument a job description in an XML-format job description language described at http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/…. This language can describe arguments, executables, staging requirements, resource requirements, etc. I also enclose a draft document that may be of interest. This is a very early draft of a GT4 Primer that I'm working on. Pages 29-43 provide a tutorial introduction to GT4 GRAM components from the client perspective. [BTW Any comments would be of great interest!!] Finally, the following (from the "Architecture and Concepts" page referenced above) describes the protocol: Protocol Overview As depicted above, the WS GRAM protocol is centered around the creation of a stateful ManagedJob resource using the ManagedJobFactory createJob() operation. A simple batch job may involve nothing more than this initial client creation step, with all other job lifecycle steps occuring automatically in the server. A number of optional protocol elements are available for more complex scenarios. (Need to verify operation names.)DelegationFactory::createDelegation This (optional) step allows a client to delegate credentials that will be required for correct operation of WS GRAM, RFT, or the user's job process. Such credentials are only used when referenced in the subsequent job request and under the condition that WS GRAM or RFT is configured to make use of the DelegationFactory, respectively. Delegation::refresh This (optional) step allows a client to update the credentials already established for use with the previous createDelegation step. ManagedJobFactory::createManagedJob This required step establishes the stateful ManagedJob resource which implements the job processing described in the input request. ManagedJob::release This (optional) step allows the ManagedJob to continue through a state in its lifecycle where it was previously held or scheduled to be held according to details of the original job request. It is a fault to try to release a hold that was not set in the job request or that was already released. ManagedJob::setTerminationTime This (optional) step allows the client to reschedule automatic termination to be different than was originally set during creation of the ManagedJob resource. ManagedJob::destroy This (optional) step allows the client to explicitly abort a job and destroy the ManagedJob resource, in the event that the scheduled automatic termination time is not adequate. ManagedJob::subscribe This (optional) step allows a client to subscribe for notifications of status (and particularly lifecycle status) of the ManagedJob resource. For responsiveness, it is possible to establish an initial subscription in the createJob() operation without an additional round-trip communication to the newly created job. ManagedJob::queryProperty and queryMultipleProperties These (optional) steps allow a client to query the status (and particularly lifecycle status) of the ManagedJob resource.

1 0