|
Chairs: |
|
|
Oracle Corporation (Apologies) | |
|
Enigmatec Corporation | |
|
|
|
|
W3C Staff Contacts |
|
|
(Apologies) | |
|
|
|
W. W. Grainger, Inc. | |
|
W. W. Grainger, Inc. | |
|
TIBCO Software | |
|
Sun Microsystems, Inc. | |
|
Sun Microsystems, Inc. | |
|
SeeBeyond Technology Corporation | |
|
Oracle Corporation | |
|
Novell | |
|
Intalio Inc. | |
|
Fujitsu Ltd | |
|
Enigmatec Corporation | |
|
Commerce One | |
|
Cisco Systems Inc | |
|
Choreology Ltd | |
|
BEA Systems | |
|
Eigner |
Francis MacCabe, Mike Champion, Abbie Barbir, David Burdett, John Dart, Carol MacDonald, Yaron Goland, Daniel Austin, Jim Hendler, Peter Furniss, Ed Peters, Greg Ritzinger, Leonard Greski
Mayilraj Krishnan confirmed as scribe
No issues raised.
ACTION: Yves@W3C should ensure a registration page for f2f
<Yves> Received details. Will do it shortly. Before the end of the week.
In progress
ACTION: Daniel to post logistics information
<DA> Did respond to Yves on the logistics.
In progress
ACTION: Daniel to kick off discussion on mission statement
Done.
ACTION: John Dart to summarize WSA position on choreography wrt mission statement and goal
<JD> Discussed in the list
Done.(waiting comments)
ACTION: Summarize use cases from privacy discussions (unassigned)
<SRT>No body got assigned
Unassigned
ACTION: Carol to look into WSCI and to pester Assaf
Carol's summary thus far
<CM>Carol submitted the presentation.
In progress
ACTION: SRT will capture requirements, referring to last discussion in conference call
Done
ACTION: SRT to capture reqs from minutes
<FM> If we follow CSF methodology requirements will come out.
<DA> Better to do the hybrid from Use cases & CSF
<LG> CSF will help to find the performance requirements. why we are doing what we are doing, basic behavior etc
<DA> These things captured in the requirements document as 2 paragraphs. Hybrid is better approach. SRT is doing the magnificent job by tracking all the use cases.
No progress.
ACTION: Resolve the ISSUE of dynamic choreographies
<SRT> Could not be resolved by anybody. This issue will come out. It will become an agenda item. Need for changing roles, it is about changing roles in dynamic choreographies.
Recorded as potential requirement: (Need for dynamic choreographies within a single roll)
ACTION: All: alternate formal models other than the pi-calculus
Open Item. <FM> Possible agenda item for F2F
ACTION: SRT to publish a pi-calculus reading list
<SRT>The material from the University of Texas is easy reading one. Nick. Do you have any suggestions?
<JD> Do we have a link in the harvested summary.
<SRT> it is all there in the summary.
Done
ACTION: SRT to dig up more references for use cases
Done
ACTION: Collect list of technologies we should harvest (Open)
Done
Future ACTION: Yves to setup reading list page. SRT will work with Yves.
ACTION: JJD to provide summary on BPSS
Done (Waiting Comments)
ACTION: Monica to provide summary Ð inclusive of comments on glossary
Done (Waiting Comments)
<SRT> Nick provided some suggestions. Daniel How are we doing?
<DA> We are doing well. Need more people to comment on this. Initial mail was sent on Friday. People knocked down and one alternate proposal from Nick. We can mix both and come up with the proposal agreeable by everybody. People discussed which version of WSDL and I am suggesting not to have particular technology, version etc. Should focus on particular problem to solve. Just keep it in a higher level. I will try some wordsmith by getting the input from the group..
<LG> Additional text to be documented: No single service should be the control of whole process has to be added in the mission statement. We had some discussion on central coordination, orchestration etc.
<SRT> It brings peer to peer issue.
<LG> No centralized control is there in what we want to do with the choreography. If it does or does not.. we have to put in the mission.
<DA> I thought we discussed these issues. Agreed we follow both?
<SRT> In this group we banned orchestration. If we can do small P2P, ability to have central controller is a special case.
<FM> Analysis I had sent out contained discussion around orchestration and choreography definitions.
<JD> No consensus built around those
<JD> Need to be discussed further
<DA> LG will send the email to DA and DA will put together and resend the email.
<SRT> MM can raise any issue (with respect to wordsmith) whatever we defined the terms in the glossary.. Any ideas to make it smaller (mission statement)?
<DA> we should have some business process centered definition?
<Nick> ÒGlobal view of long lived transactionÓ makes sense about business statement. Not sure about the business process.
<DA> NickÕs suggestions are good.
<JD> Both are good. Only objection to the original was ÒexternalÓ. Only objection to Nick is ÒCommon view should not be implied to central coordinatorÓ
<DA> Suggestion on ÒexternalÓ is good.
<Nick> I agree with JJ comment on common and global view.
<SRT> any other comments?
<DA> Should we have to wait? I donÕt want to just give the false impression. Just go ahead with what we are doing.
ACTION: DA will do the wordsmith, summarize and put together revised statement. Once again it is not final.
<DJW> Better not to throw away the next details rather than one line statement.
<SRT> We will capture in the requirements document.
<SRT> This issue first started with mission stmt. Our charter says we have to bind WSDL 1.2. I would be interested to listen from W3C in WSDL
<Yves> What is the basis?
<LG> Does the charter say we should not bind to anything
<SRT> Charter says ÒShould built upon WSDL 1.2Ó
<Yves> WSDL1.2 is open and built upon abstraction layer. WSDL1.2 is ok.
<SRT> I have few questions. Should we have to stick with charter or does not have to be
<JD> There is a desire to future proof choreography spec with other specs. I am not convinced with that. I am not worried about other spec alignment.
<LG> Develop with binding-less manner. Later bind it.
<JD> One of the way is to use the metadata approach
<YG> There are many problems. What about interoperability? There are two orgs about interoperable. Reality nothing works with these abstract. Easy and obvious approach is to use WSDL 1.2. No need for more abstract. More abstract does not work much for interoperability and we should tie with WSDL 1.2
<DB> choreography definitions must be reusable
<YG> Where
<DB> In High tech industry business use Rosettanet. Some sort of abstraction is necessary.
<YG> we are not here to create universal choreography language. We are here to create WS choreography language.
<DB> If we want to get to widespread use, general agreement is needed for messages, exchaage patterns.(Ex) Telecom service industry choreography will work only in US and not work in Europe. That is the reason we need abstraction.
<YG> We had same discussion in the previous call. We came to the same conclusion. Only the different format of the message. But the choreography is same. Just tie to WSDL 1.2 and have some nice way to deal way . use some sort of templates and make it reusable.
<DB> I agree.
<MM> Just take one concept, ebxml loosely coupled, give us some flexibility and the choreography with it may not be automatable but we can define it.
<DA> Really reluctant to bind to WSDL1.2É
<YG> Form a another workgroup to create ÒUniversal choreography groupÓ
<DB> We need to work out WSDL 1.2. Should do know what we want to do of WSDL1.2? Find out what we do want to and donÕt want to do from WSDL1.2
<JD> I am concerned the charter is ambiguous and subject to interpretations.. We have to clarify with W3C. WSDL dependency is not specific language binding..
<SRT> should not bind to any programming language.
<JD> Loose and tight coupling is fine. Uncoupling is bad idea. (Personal opinion)
<JJ> I donÕ think web services will be not enabled in the couple of years. Just to do choreography we donÕt need web services between systems. If we donÕt constrain the people to do the web services for choreography, then within internal organization we are helping to jump start for business. I donÕt think it is necessarily bad idea having the door open .
<YG> I need to know ÒWS WG? Or as far as I am ware WS is WSDL. I need to know from the group ÒWhat is the charterÓ> I thought it isWSDL 1.2? Extending to work with ebXML etc will be too much.. Just we(BEA) need to know what are we going to do? We need to resolve this ASAP.
<JD> I thought we resolved this.. WSDL1.2 is easily extensible. I am very sympathetic about web services integration. I thought it should be for more web service.
<FM> WSA discussed fairly. Web service is not confined to WSDL. Not accurate to say Web service = WSDL + SOAP
<MM> I agree with JJ. About ÒMigration PathÓ
<DB> Understand BEA point and we have to investigate more about business process around all these.
<SRT> if WSDL is not perfect then we have to find out what is not there in WSDL 1.2?
<YG> Excellent question.. What are the things we expect them from WSDL? Then liaison with them to do what it has to do? I agree that WSDL is not a sophisticated one. Need to be dealt with issue by issue.
<JJ> Need some level of abstraction directly by WSDL (Wrapping technology?) Why do we need the door closed? (Question to YG). Other things can be attatched. Could you clarify to shut the door for open binding framework even if it is simple enough?
<YG> Could be extensible. Issue is ÒWatched over the last couple of years about XML, web services . In the case of web services, all extensibility (whatever we are discussing) leads to confusion. ???Passionatted??? with extensible. Violates fundamental rules of interoperability. Extensible is not losing options. Let us begin with WSDL 1.2 and see what are the extensible.
<JJ> Agree with you
<DB> We need to have some abstraction with variability. I agree with JJ. Let us start with WSDL1.2 and find out what is there. See what do we need..?
<YG> What level of variability? Web Service is far behind compared to EDI. BEA does not care about EDI (here).. Just we care about Web Service
<DB> I am talking about generic approach on choreography.. Message actual content sent need not be on SOAP. But we could map it to SOAP.
<SRT> Let me summarize:
YG is talking about template, DB is talking about abstraction. You need abstraction is for reuseÉ Template and abstraction? Common requirement is for choreography reuse. On what context? If we find a way by templating or abstraction, does not blow out WSDL1.2 .. then we all agreeing?
<AA> If we want to use EDI or something, let us go to WSDL 1.2 WG and ask them how to do with WSDL?? They will come up with some easy solutions. Let us start from WSDL1.2..
< DJW> Lot of conversations are abstract. I would say let us start with some concrete goals. Better to get the use cases. Otherwise we have lot of risk.(for this working group).
<DA>. Probably better to start some sub groups.. Make sense to use cases, another group for other abstracts of our work. Some point we have to split up. May be now it is the time.
<SRT> May be this is the time. Hold off month.. Having F2F is good idea for subgroup formation.
<SRT> Three volunteers:
ACTION: YG to email what is meant by ÒTemplatingÓ and the benefits thereof
ACTION: DB to email is meant by ÒabstractionÓ and the benefits thereof
ACTION: GR to email an independent view of what these terms might mean and the benefits thereof
All these emails need not more than one paragraph.
ACTION: Yves@W3C should ensure a registration page for f2f
In progress
ACTION: Daniel to post logistics information .
In progress
ACTION: John Dart to summarize WSA position on choreography wrt mission statement and goal
Done.(waiting comments)
ACTION: Summarize use cases from privacy discussions (unassigned)
Unassigned
ACTION: Carol to look into WSCI summary
In progress
ACTION: SRT to capture reqs from minutes
No progress.
ACTION: All: alternate formal models other than the pi-calculus
Open Item. <FM> make this an agenda item for F2F
ACTION: Yves to setup reading list page. SRT will work with Yves.
ACTION: JJD to provide summary on BPSS
Done (Waiting Comments)
ACTION: Monica to provide summary Ð inclusive of comments on glossary
Done (Waiting Comments)
ACTION: DA will do the wordsmith, summarize and put together revised statement. Once again it is not final.
ACTION: YG to email what is meant by ÒTemplatingÓ and the benefits thereof
ACTION: DB to email is meant by ÒabstractionÓ and the benefits thereof
ACTION: GR to email an independent view of what these terms might mean and the benefits thereof