October 2005 - ogsa-wg - lists.ogf.org

Proposed agenda for Oct. 12th call
by Hiro Kishimoto 12 Oct '05

12 Oct '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Oct. 12th Wednesday from 5pm to 7pm (CDT). 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: 1012 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Agenda bashing 2) GGF15 and F2F evaluation (20 min) Upsides and downsides Minutes approval (if available) Meeting materials are uploaded to GridForge https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… 3) EMS architecture discussion (30 min) "EMS Architecture Composition Roadmap" by Steven https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap Draft sequence diagram #1 (2.1) and #2 (2.2) https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-EMS-Sequence-di… https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-EMS-Sequence-di… https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-EMS-Sequence-di… https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-EMS-Sequence-di… 4) information model discussion (30 min if available) BES container profile 5) Wrap up (10 min) AOB <NEXT CALL> Oct. 17 (Mon) Basic Security Profile, Architecture & glossary 1.5 Oct. 19 (Wed) EMS architecture, information model -- Hiro Kishimoto

1 0

CDDLM meeting tomorrow, Wed 10/12/2006, at 6am PST
by Milojicic, Dejan S 12 Oct '05

12 Oct '05

Hi, At the F2F meeting with OGSA, CDDLM had a couple of homework assignments. The first one was to sort out how does CDDLM interact with ACS. We had some preliminary hallway discussions between CDDLM people, Mike Behrens and Sachiko, but they suggested that they would like to sync up with Keisuke prior to making any decision. The options have been documented in a presentation that Stuart prepared and gave at the F2F meeting (either direct CDDLM-ACS interactions; through data services; or through information services. I expect that someone from ACS-WG can join us either tomorrow at our meeting or at some other meeting in the near future. The second task item we had from the F2F was how can we help provisioning services by providing an estimate of the deployment time. The third task assignment was where do we stop in expanding the tree (e.g. at the OS provisioning?) and how do we mark this. The last assignment was to see how we fit into Andrew Grimshaw's view of provisioning. Andrew promised that he will write-up a paragraph or so on his view and we will use that to answer his concerns. I expect to make progress on the first three topics tomorrow morning PST (as well as the fourth if we receive Andrew's paragraph in a timely fashion) and if we get some opportunity we can present the outcome at the OGSA meeting tomorrow afternoon (PST) or we can communicate the outcomes by email. As usual, we shall use the following conference number: +1 866-639-4732 (toll free while in US) Code 2362906 (followed by a '#' sign) +1 574-948-0379 (toll & international) Thanks, Dejan.

2 1

RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
by Maguire_Tom＠emc.com 11 Oct '05

11 Oct '05

Frank, I do not disagree that if profile the <wsa:address> as an abstract name then it must have the properties of an abstract name (whatever they may be). Further I would assume the we would have claims on the WSDL that it returns abstract name profiled EPRs. Tom -----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: Tuesday, October 11, 2005 1:58 PM To: Maguire, Tom Cc: ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com; David.Snelling(a)uk.fujitsu.com Subject: Re: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding I'd like to go back to the start of your discussion and talk about the required properties of the Address. The assumptions for the AbstractName are: * The name MUST be globally unique in both space and time. * The name conforms to URI syntax ("Uniform Resource Identifiers (IRI): Generic Syntax", RFC 3987). I believe that we need more assumptions on the binding properties itself, and an example may help. Suppose we have: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing" xmlns:name="http://ggf.org/name"> <wsa:Address> http://tempuri.org/example?Id=3 </wsa:Address> <name:AbstractName> urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388 </name:AbstractName> </wsa:EndpointReference> As you can see, we have an AbstractName that clearly looks unique in space and time, and an Address that seems to have a service/resource identifier (Id=3) that doesn't look that strong. Now suppose that this service application is implemented such that after the hosting environment is recycled/restarted, the following EPR is valid: <wsa:EndpointReference> <wsa:Address> http://tempuri.org/example?Id=4 </wsa:Address> <name:AbstractName> urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388 </name:AbstractName> </wsa:EndpointReference> (I've removed the name space identifiers for clarity) As you can see, the implementation has assigned a different Address to the same AbstractName, and we can guess that the Id=4 is the changed distinguishing parameter value used for dispatching to the same service/resource. Now suppose that this same implementation will reuse the previous Id=3 for a different service/resource, like: <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing" xmlns:name="http://ggf.org/name"> <wsa:Address> http://tempuri.org/example?Id=3 </wsa:Address> <name:AbstractName> urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B77777 </name:AbstractName> </wsa:EndpointReference> So now the service implementation has reused the old Address with Id=3 for a new, different service/resource that is uniquely identified with a new guid that ends with 77777 instead of 54388: we have two different AbstractNames for two different services/resources that are bound to the same Address, which could cause some confusion... One could claim that this is a "bad" implementation and that the EPR-minter should *ensure* that this should not happen. However, this application could work perfectly correct for the things that it's supposed to do, and it is the mismatch in assumptions that causes the problem. I believe that if we have a strong uniqueness claim for the AbstractName, then the binding to an Address is only meaningful if that Address (or the binding) has an equivalent strong uniqueness property. In other words, the binding of the AbstractName that is "globally unique in both space and time" to an Address, only makes sense if that Address has the exact same property. Now the only one that can ensure that the Address is also "globally unique in both space and time", is the implementation, i.e. the EPR-minter, and those implementations that could be identified through a profile for EPR-minters: the globally-unique-Address-in-both-space-and-time EPR profile. So, binding a "globally unique in both space and time" AbstractName would only make sense if one is assured that the implementation conforms to the globally-unique-Address-in-both-space-and-time EPR profile. One could relax this requirement a little by considering the complete binding instead of the Address only, and we could for example consider a validity time-interval and a binding issuer. This would allow you to localize the uniqueness requirement of the Address to the time-interval or/and issuer. But so far we have punted the idea of dealing with an EPR as a true assertion, which leaves us only the Address to play with. Summary: I believe that the "globally unique in both space and time" requirement for the AbstractName MUST hold true also for the Address to which it is bound, and that EPRs with such an Address constitute a globally-unique-Address-in-both-space-and-time EPR-minter profile. One can only bind AbstractNames to EPRs that adhere to the globally-unique-Address-in-both-space-and-time EPR-minter profile. Note that if this all holds, then the Address of an EPR that conforms to the globally-unique-Address-in-both-space-and-time profile, could also be used as an AbstractName, which would be great as it would give us an identifier that we could use to bind (authorization-) policy to and as a side-benefit would also be available on the wire. Regards, Frank. Maguire_Tom(a)emc.com wrote: > > As promised at the F2F in Boston I have started a thread of discussion > on the subject line. I have reposted the thread to the this mailing > list > (ogsa-wg) in the hope that broader distribution will spur debate and > discussion. > > Tom > > -----Original Message----- > From: Maguire, Tom > Sent: Sunday, October 09, 2005 4:51 PM > To: Maguire, Tom; David.Snelling(a)UK.Fujitsu.com > Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com > Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding > > Dave you mentioned in one of your question: > > >>> It appears that in the example that either the was:Address and the >>> soap:address must be the same or that the wsa:Addess is irrelevant. >>> I can't really believe the former so let's assume the later. >>> > > It's not that the wsa:adddress is irrelevant it is that the > wsa:address is logical as opposed to physical. This is precisely why > I think we can use it.... > > Tom > > -----Original Message----- > From: owner-ogsa-naming-wg(a)ggf.org > [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Maguire, Tom > Sent: Sunday, October 09, 2005 8:35 AM > To: David.Snelling(a)UK.Fujitsu.com > Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com > Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding > > Dave, > > I'll do my best to answer your questions inline below. Let me caution > this thread a bit. The WSDL Binding specification is not complete and > is clearly still evolving... > > >>> It appears that in the example that either the was:Address and the >>> > soap:address must > >>> be the same or that the wsa:Addess is irrelevant. I can't really >>> believe >>> > the > >>> former so let's assume the later. >>> > > Yes, I believe that is the intent. As I mentioned in my note it is > 'interesting' that they are the same. My guess is that makes > implementations that are not <wsa:metadata> aware able to cope. I > would expect that would be a 'best practice'. Not sure what the > implications would be for us if that were the case... > > >>> With a wsdl11:definitions section present, the wsa:Address field >>> must be >>> > superseded > >>> by the soap:address chosen by the client. I assume that the >>> soap:address gets copied to the was:To field in the soap header. >>> > > Ultimately you are correct however I expect that the specification of that > linkage would not be quite as explicit as that. > > >>> There is no linkage in the wsdl11:definitions to connect the >>> wsa:Address >>> > to it. > > No > > >>> Q1) What happens with more than one wsdl11:definitions section in >>> the was:Metadata? >>> > > I have no idea what that would even mean. I presume they would limit > that in the spec. As I said it is still evolving. > > >>> Q2) In this case can we put any old junk in the wsa:Address? >>> i.e. leave it out (except that the scheme saus [1..]. >>> > > <wsa:address> is required and I would assume that at a minimum there > would be a statement of 'best practice' where the <wsa:address> is the 'default' > address. > > >>> Q3) If we use the wsa:Address as an Abstract Name, how do we know >>> that is >>> > what > >>> we are doing? We could subtype the EPR to create a WS-Name as we do >>> now, and bind the usage of the was:Address to type of the WS-Name. >>> > > I would use a wsi conformance claim on both the wsdl and the EPR. The > wsdl claim would be that the service is capable of generating > WS-Names. The EPR claim would be that this EPR adheres to the > additional semantics of a WS-Name. > > >>> Q4) I thought WS-Addressing was NOT about naming or identity. >>> How will this use (abuse) of the wsa:Address go down with the W3C folks? >>> > > I think this is a misread on your part W3C objected to identity being > encoded in something OTHER than a URI (IRI); in the WS-Addressing case > they objected to ReferenceProperties. Ultimately ReferenceProperties > were merged with ReferenceParameters which weakened (removed) the > identity semantic. I think they would be extremely happy with the use > of a URI as an identifier :-). > > > Tom > > > On 7 Oct 2005, at 12:41, Maguire_Tom(a)emc.com wrote: > > >> This will be a fairly long note to discuss the current incarnation of >> WS-Naming Abstract Names. An Abstract Name has the following >> properties: >> >> * The name MUST be globally unique in both space and time. >> * The name conforms to URI syntax ("Uniform Resource Identifiers >> (IRI): Generic Syntax", RFC 3987). >> >> Let's leave aside the first point, for the time being, and focus on >> the second point. The abstract name is an IRI which is an >> internationalized URI. Currently this means that a WS-Name abstract >> name would look like >> this: >> >> <wsa:EndpointReference >> xmlns:wsa="http://www.w3.org/2005/03/addressing" >> xmlns:name="http://ggf.org/name"> >> <wsa:Address>http://tempuri.org/example</wsa:Address> >> >> <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</ >> name:Abstr >> actName> >> </wsa:EndpointReference> >> >> There are several built in assumptions in this particular rendering >> of an >> abstract name. First, there is an assumption that the <wsa:Address> >> is the >> [destination] MAP of the EPR. Second, the AbstractName does not need >> to flow on the wire when 'dereferencing' this EPR. >> >> It may be ok for the AbstractName to not flow on the wire. I will >> leave that discussion to others. Let's focus on the first >> assumption... >> If you assume that the <wsa:Address> is NOT necessarily a physical >> address >> (URL) then it is essentially the same as an AbstractName minus the >> "MUST be globally unique in both space and time" property described >> above. >> >> This is essentially how 'Web Services Addressing 1.0 - WSDL Binding' >> defines >> a <wsa:Address>. An example from that specfication: >> >> <wsa:EndpointReference >> xmlns:wsa="http://www.w3.org/2005/03/addressing"> >> <wsa:Address>http://example.com/fabrikam/acct</wsa:Address> >> <wsa:Metadata> >> <wsdl11:definitions targetNamespace="http://example.com/fabrikam" >> xmlns:fabrikam="http://example.com/fabrikam" >> xmlns:abc="http://www.abccorp.com/" >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" >> xmlns:iiop="http://www.iiop.org/" >> xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/"> >> <wsdl11:import namespace="http://example.com/fabrikam" >> location="http://example.com/fabrikam/fabrikam.wsdl"/> >> <wsdl11:import namespace="http://www.abccorp.com/" >> location="http://www.abccorp.com/abc.wsdl"/> >> <wsdl11:service name="InventoryService"> >> <wsdl11:port name="ep1" binding="abc:soap-http-binding"> >> <soap:address location="http://example.com/fabrikam/acct"/> >> </wsdl11:port> >> <wsdl11:port name="ep2" binding="abc:iiop"> >> <iiop:address location="..."/> >> </wsdl11:port> >> </wsdl11:service> >> </wsdl11:definitions> >> </wsa:Metadata> >> </wsd:EndpointReference> >> >> And also from 'Web Services Addressing 1.0 - WSDL Binding' >> >> In particular, embedding a WSDL service component description MAY be >> > > >> used by EPR issuers to indicate the presence of alternative addresses >> and protocol bindings to access the referenced endpoint. The >> alternatives are provided by the different endpoints of the embedded >> service. >> >> It is interesting to note that in the above example that the >> <wsa:address> matches the soap:address location. >> So this says to me that the <wsa:address> is essentially equivalent >> (or at least could be) to an abstract name. >> >> Thoughts? >> >> >> Thanks, >> Tom >> >> Senior Technologist, CTO Office >> EMC²|SMARTS >> 44 South Broadway >> 7th Floor >> White Plains, NY 10601 >> Office: +1-914-508-3477 >> Mobile: +1-845-729-4806 >> Email: maguire_tom(a)emc.com <mailto:maguire_tom@emc.com> >> >> If you want to build a ship, don't drum up people to collect wood and >> don't assign them tasks and work, but rather teach them to long for >> the endless immensity of the sea. >> >> Antoine de Saint-Exupery >> >> >> -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
by Maguire_Tom＠emc.com 11 Oct '05

11 Oct '05

Pardon my english s/the thread to the/this thread to /g -----Original Message----- From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Maguire, Tom Sent: Tuesday, October 11, 2005 12:49 PM To: ogsa-wg(a)ggf.org Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com; David.Snelling(a)uk.fujitsu.com Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding As promised at the F2F in Boston I have started a thread of discussion on the subject line. I have reposted the thread to the this mailing list (ogsa-wg) in the hope that broader distribution will spur debate and discussion. Tom -----Original Message----- From: Maguire, Tom Sent: Sunday, October 09, 2005 4:51 PM To: Maguire, Tom; David.Snelling(a)UK.Fujitsu.com Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding Dave you mentioned in one of your question: >>It appears that in the example that either the was:Address and the >>soap:address must be the same or that the wsa:Addess is irrelevant. >> I can't really believe the former so let's assume the later. It's not that the wsa:adddress is irrelevant it is that the wsa:address is logical as opposed to physical. This is precisely why I think we can use it.... Tom -----Original Message----- From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Maguire, Tom Sent: Sunday, October 09, 2005 8:35 AM To: David.Snelling(a)UK.Fujitsu.com Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding Dave, I'll do my best to answer your questions inline below. Let me caution this thread a bit. The WSDL Binding specification is not complete and is clearly still evolving... >>It appears that in the example that either the was:Address and the soap:address must >>be the same or that the wsa:Addess is irrelevant. I can't really >>believe the >>former so let's assume the later. Yes, I believe that is the intent. As I mentioned in my note it is 'interesting' that they are the same. My guess is that makes implementations that are not <wsa:metadata> aware able to cope. I would expect that would be a 'best practice'. Not sure what the implications would be for us if that were the case... >>With a wsdl11:definitions section present, the wsa:Address field must >>be superseded >>by the soap:address chosen by the client. I assume that the >>soap:address gets copied to the was:To field in the soap header. Ultimately you are correct however I expect that the specification of that linkage would not be quite as explicit as that. >>There is no linkage in the wsdl11:definitions to connect the >>wsa:Address to it. No >>Q1) What happens with more than one wsdl11:definitions section in the >>was:Metadata? I have no idea what that would even mean. I presume they would limit that in the spec. As I said it is still evolving. >>Q2) In this case can we put any old junk in the wsa:Address? >>i.e. leave it out (except that the scheme saus [1..]. <wsa:address> is required and I would assume that at a minimum there would be a statement of 'best practice' where the <wsa:address> is the 'default' address. >>Q3) If we use the wsa:Address as an Abstract Name, how do we know that >>is what >>we are doing? We could subtype the EPR to create a WS-Name as we do >>now, and bind the usage of the was:Address to type of the WS-Name. I would use a wsi conformance claim on both the wsdl and the EPR. The wsdl claim would be that the service is capable of generating WS-Names. The EPR claim would be that this EPR adheres to the additional semantics of a WS-Name. >>Q4) I thought WS-Addressing was NOT about naming or identity. >>How will this use (abuse) of the wsa:Address go down with the W3C folks? I think this is a misread on your part W3C objected to identity being encoded in something OTHER than a URI (IRI); in the WS-Addressing case they objected to ReferenceProperties. Ultimately ReferenceProperties were merged with ReferenceParameters which weakened (removed) the identity semantic. I think they would be extremely happy with the use of a URI as an identifier :-). Tom On 7 Oct 2005, at 12:41, Maguire_Tom(a)emc.com wrote: > This will be a fairly long note to discuss the current incarnation of > WS-Naming Abstract Names. An Abstract Name has the following > properties: > > * The name MUST be globally unique in both space and time. > * The name conforms to URI syntax ("Uniform Resource Identifiers > (IRI): Generic Syntax", RFC 3987). > > Let's leave aside the first point, for the time being, and focus on > the second point. The abstract name is an IRI which is an > internationalized URI. Currently this means that a WS-Name abstract > name would look like > this: > > <wsa:EndpointReference > xmlns:wsa="http://www.w3.org/2005/03/addressing" > xmlns:name="http://ggf.org/name"> > <wsa:Address>http://tempuri.org/example</wsa:Address> > > <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</ > name:Abstr > actName> > </wsa:EndpointReference> > > There are several built in assumptions in this particular rendering of > an > abstract name. First, there is an assumption that the <wsa:Address> > is the > [destination] MAP of the EPR. Second, the AbstractName does not need > to flow on the wire when 'dereferencing' this EPR. > > It may be ok for the AbstractName to not flow on the wire. I will > leave that discussion to others. Let's focus on the first > assumption... > If you assume that the <wsa:Address> is NOT necessarily a physical > address > (URL) then it is essentially the same as an AbstractName minus the > "MUST be globally unique in both space and time" property described > above. > > This is essentially how 'Web Services Addressing 1.0 - WSDL Binding' > defines > a <wsa:Address>. An example from that specfication: > > <wsa:EndpointReference > xmlns:wsa="http://www.w3.org/2005/03/addressing"> > <wsa:Address>http://example.com/fabrikam/acct</wsa:Address> > <wsa:Metadata> > <wsdl11:definitions targetNamespace="http://example.com/fabrikam" > xmlns:fabrikam="http://example.com/fabrikam" > xmlns:abc="http://www.abccorp.com/" > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > xmlns:iiop="http://www.iiop.org/" > xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/"> > <wsdl11:import namespace="http://example.com/fabrikam" > location="http://example.com/fabrikam/fabrikam.wsdl"/> > <wsdl11:import namespace="http://www.abccorp.com/" > location="http://www.abccorp.com/abc.wsdl"/> > <wsdl11:service name="InventoryService"> > <wsdl11:port name="ep1" binding="abc:soap-http-binding"> > <soap:address location="http://example.com/fabrikam/acct"/> > </wsdl11:port> > <wsdl11:port name="ep2" binding="abc:iiop"> > <iiop:address location="..."/> > </wsdl11:port> > </wsdl11:service> > </wsdl11:definitions> > </wsa:Metadata> > </wsd:EndpointReference> > > And also from 'Web Services Addressing 1.0 - WSDL Binding' > > In particular, embedding a WSDL service component description MAY be > used by EPR issuers to indicate the presence of alternative addresses > and protocol bindings to access the referenced endpoint. The > alternatives are provided by the different endpoints of the embedded > service. > > It is interesting to note that in the above example that the > <wsa:address> matches the soap:address location. > So this says to me that the <wsa:address> is essentially equivalent > (or at least could be) to an abstract name. > > Thoughts? > > > Thanks, > Tom > > Senior Technologist, CTO Office > EMC²|SMARTS > 44 South Broadway > 7th Floor > White Plains, NY 10601 > Office: +1-914-508-3477 > Mobile: +1-845-729-4806 > Email: maguire_tom(a)emc.com <mailto:maguire_tom@emc.com> > > If you want to build a ship, don't drum up people to collect wood and > don't assign them tasks and work, but rather teach them to long for > the endless immensity of the sea. > > Antoine de Saint-Exupery > > -- 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)

1 0

NO CALL on Monday
by Hiro Kishimoto 09 Oct '05

09 Oct '05

Hi all, Thank you very much for all of you who came to GGF15 and F2F meeting. We had very lively and productive meetings in Boston. Since 10th is holiday in US and Japan, we have NO call on Monday. Our next call is on Wednesday Oct. 12th. Thanks again and enjoy your holiday, ---- Hiro Kishimoto

1 0

CFP: SOBPI'05 - Workshop on Service-Oriented Business Process Integration
by gagnon＠soa7.com 05 Oct '05

05 Oct '05

*********************************************************************** SOBPI'05 - Workshop on Service-Oriented Business Process Integration Apologies for cross-posting *********************************************************************** CALL FOR PAPERS International Workshop on SERVICE-ORIENTED BUSINESS PROCESSES INTEGRATION (SOBPI'05) http://elab.njit.edu/sobpi Held in conjunction with the 3rd International Conference on Service-Oriented Computing (ICSOC 2005) December 12, 2005 Amsterdam, the Netherlands http://www.icsoc.org *********************************************************************** --- IMPORTANT DATES --- Papers submission >>> Extended to October, 14, 2005 (was Sept.30, 2005) Notification >>> Extended to October 31, 2005 (was Oct.21, 2005) Camera ready >>> November 11, 2005 Workshop >>> December 12, 2005 --- MOTIVATIONS --- A widely recognized trend in business and markets is the push towards the idea of companies and enterprises as networked organizations, which can gain profit from collaborations in the net, improving their flexibility, and reducing operational costs. This transformation requires the adoption of more collaborative working practices based on the integration of business processes within a wide community of business partners, suppliers, vendors, and public bodies. In parallel to this trend, service oriented technologies are transforming the web from an infrastructure for sharing information to a place where the networked organizations can meet to integrate their business interests. Service Oriented Computing (SOC) is currently the most promising technology supporting the development and execution of business processes that are distributed among the most disparate entities, both within an organization and across organizational borders. However, a practical industry-wide adoption of web services, to support the collaboration among networked organizations and the integration of their business process, is still an open challenge. This challenge can be addressed only by a tight integration of service-oriented development within new business models and new ways of management that are able to exploit new technological solutions. Moreover, web service technology is still emerging, and therefore their industry-wide adoption requires to inject research results within real industry practices, but, even more important, to drive research activities and roadmaps according to industrial needs. The aim of this workshop is to bring together researchers, practitioners, and experts in business models and management and to promote cross-fertilization among their competencies, focusing on the usage of service oriented technologies to support the Business Processes Integration (BPI). The goal is to build bridges and convergences among the complementary views of experts in IT and service oriented technologies and experts in management, and the different approaches of academy and industry, to the problem of business processes integration. The emphasis of the workshop will be on the demonstration of the practical application of research results, and on the description of industrial case studies. --- FOCUS --- The workshop will seek contributions in the field of SOC for BPI. Papers can take the form of detailed case studies, technical white papers, new methodologies, new standard specifications, benchmarking models, or any other contributions demonstrating innovative applications of SOC for BPI. Topics may include, but are not limited to: 1. Development Methodologies and Tools: a. Service/Process Modeling, Deployment, and Testing b. Enterprise Architecture and Service/Process Definition c. Model Driven Architecture and Service/Process Reuse d. Process-Oriented Messaging Infrastructures e. Distributed Business Process Management 2. Adoption of Advanced Technologies: a. Intelligent Process Discovery and Integration b. Service/Process Composition c. Event Driven Architecture and Process Automation d. Integration of Services, Messaging, and Connectors e. Business Activity Monitoring and Quality of Service 3. Comparison of Implementation Platforms: a. Business Process Management b. Enterprise Service Bus c. Business Services Networks --- EVENT FORMAT --- The workshop will be highly interactive, and commentators will be exploited foster the discussion among participants with different backgrounds: each presentation will be followed by a short presentation of comments from a participant belonging to different areas of expertise, in order to bridge the ideas of the paper with a different viewpoint (e.g., each presentation on IT solutions will be followed by comments from industry experts and, vice-versa, presentations on case studies will be followed by comments on the research and technological challenges). --- PUBLICATIONS --- Proceedings will be published on the web while organizers make arrangements for both print and digital publication with a major publisher. In addition, best papers will be submitted for consideration as part of the Special Issue on Business Process Management: from Engineering to Execution, Guest Edi-tor: Prof. Angel Ortiz, Polytechnic niversity of Valencia, Spain, International Journal of Information Technology and Management (IJITM), http://www.inderscience.com/browse/callpaper.php?callID=255 --- IMPORTANT DATES --- Papers submission >>> Extended to October, 14, 2005 (was Sept.30, 2005) Notification >>> Extended to October 31, 2005 (was Oct.21, 2005) Camera ready >>> November 11, 2005 Workshop >>> December 12, 2005 --- SUBMISSIONS --- Authors are invited to submit original, previously unpublished contributions. Papers should be written in English using Springer's LNCS style (http://www.springer.de/comp/lncs/authors.html) and must not exceed 15 pages. Shorter papers, presenting preliminary results, are welcome. Please submit papers electronically, using the workshop Web site, at http://elab.njit.edu/sobpisubmit. --- REGISTRATION --- For accepted submissions, at least one author must register for the workshop in order for the paper to appear in the proceedings and to be scheduled in the workshop pro-gram. Please register for the workshop at the ICSOC conference website (http://www.icsoc.org) before November 5, 2005. --- CONTACT INFORMATION --- Please direct all inquiries to <sobpi(a)dit.unitn.it>. --- CO-CHAIRS --- * Stephane Gagnon, New Jersey Institute of Technology, USA * Heiko Ludwig, IBM Watson Research Center, USA * Marco Pistore, Univeristy of Trento, Italy * Wasim Sadiq, SAP Research Brisbane, Australia --- PROGRAM COMMITTEE --- * Morad Benyoucef, University of Ottawa, Canada * Antonio Brogi, University of Pisa, Italy * Jen-Yao Chung, IBM Watson Lab, USA * Marlon Dumas, Queensland University of Technology, Australia * Schahram Dustdar, Vienna University of Technology, Austria * Elena Ferrari, University of Insubria at Como, Italy * Oleg Gusikhin, Ford Research & Advanced Engineering, USA * Patrick Hung, University of Ontario Institute of Technology, Canada * Anup Kumar, University of Louisville, USA * Angel Ortiz, Polytechnic University of Valencia, Spain * Katia Passerini, New Jersey Institute of Technology, USA * Pascal Pecquet, University of Montpellier 1, France * Manfred Reichert, University of Twente, The Netherlands * Colette Rolland, University of Paris 1 Pantheon Sorbonne, France * Richard Soley, Object Management Group, USA * Cheickna Sylla, New Jersey Institute of Technology, USA * Vladimir Tosic, Lakehead University, Canada * Hannes Werthner, University of Innsbruck & EC3 Vienna, Austria * Andreas Wombacher, University of Twente, The Netherlands * Dan Zhang, University of Ontario Institute of Technology, Canada * Jia Zhang, Northern Illinois University, USA * Aoying Zhou, Fudan University, China

1 0

F2F EMS session material
by Hiro Kishimoto 05 Oct '05

05 Oct '05

Hi all, Based on the OGSA-WG EMS discussion and RSS-WG discussion. I've written up EMS session material (proposal) for EMS sessions Thursday morning. https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-F2F-EMS-draft/ Please have a look and let's review it at agenda bashing tomorrow. Thanks -- Hiro Kishimoto

1 0

RE: [ogsa-wg] Draft new charter document (new draft uploaded)
by Treadwell, Jem 05 Oct '05

05 Oct '05

Hi, at Hiro's request I took an editing pass at the document, and uploaded a new version. Version 2 includes all the markup, but for easier reviewing I accepted all the changes, added a draft date and uploaded the result as v3. The current draft (v3) is at: https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-new-charte r-draft/en/3 - Jem > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Hiro Kishimoto > Sent: Tuesday, October 04, 2005 10:08 AM > To: ogsa-wg(a)ggf.org > Subject: [ogsa-wg] Draft new charter document > > Hi all, > > Based on the August F2F meeting discussion, I wrote up new > charter draft and upload it to GridForge. > > https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG- > new-charter-draft > > Please have a look in advance, we will review it at F2F > meeting on Thursday 5-6pm. > > Thanks, > -- > Hiro Kishimoto > >

1 0

Draft new charter document
by Hiro Kishimoto 04 Oct '05

04 Oct '05

Hi all, Based on the August F2F meeting discussion, I wrote up new charter draft and upload it to GridForge. https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-new-charter-d… Please have a look in advance, we will review it at F2F meeting on Thursday 5-6pm. Thanks, -- Hiro Kishimoto

1 0

Dial-in info for OGSA-WG session #2
by Hiro Kishimoto 03 Oct '05

03 Oct '05

Hi all, Dial-in information for GGF15 OGSA-WG session #2: Toll number: +1 718 3541071 (New York) +1 408 9616509 (San Jose) The pass code: 4371991 Screen share service MAY be provided. URL: http://ogsa.glance.net Session key: 1003 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html > OGSA EMS architecture > (OGSA-WG) Group Discussion > 4-5:30pm (EDT), Monday > > This is working session to discuss high level OGSA EMS architecture among fellow WGs, including OGSA-BES, OGSA-RSS, JSDL, GRAAP, CDDLM, ACS, and etc. By means of a couple of scenarios walk through, we will explore interactions between these services. > > Agenda: > Scenario walk through > - BLAST application > - 3-tier application > - Consolidation services > > > Location: Stuart Thanks, -- Hiro Kishimoto

1 0