Face 2 Face Meeting, September 17th 2003
Roll Call 13:50
Agenda 13:55
Sattish: propose rearranging second day schedule: move BTM to 15:30, move other things up.
Choreology group: agreed provided BTM discussion actually starts at 15:30.
Disembodied voice on phone: audio is bad, people on conference can’t hear.
Workplan
d: propose goal of establishing game plan and milestone for V1 committee draft. Propose that spec is updated iteratively. First pass document would not be a committee draft, just a first cut draft with some issues addressed. No answers as to what exactly should be addressed. One proposal is to address core BPEL, whatever the core is. Other thought is to prioritize issues. More ad-hoc way is to set a date, and let whoever feels strongly about issues to work those issues (prioritization by amount of energy committee wants to devote).
Chris K.: Should we look at use cases?
d: We may not want to wait for the use cases, we may be waiting a while.
d: In relation to starting with limited scope and growing, current thinking at OASIS is scope should be precise; if it expands there should be a call for membership. OASIS says TCs can add to deliverables. We need to focus on fundamentals. BPEL needs to be made whole and then enhancements should be identifier. We shouldn’t try to put it all together.
??: It’s important to understand what core functions are. Number of ways to look at it: BPEL 1.1 is the core, subset of BPEL 1.1 is core (implementers know what it is), or something more than 1.1.
Steve RT: One proposal, ask implementers which features are important. Then, have a bum fight [an English project management technique].
Jeff M.: The only way this will work is every time we vote on issue editors apply changes to document, then we vote on whether they did their job correctly.
Sid: Certain key issues have impact on document and implementations. One issue is to talk about feature requests, and the other is fundamental, like are we using WSDL 1.1 or WSDL 1.2? We need mechanism for organizing and prioritizing issues.
Jeff M.: At the end of the day you have to change the words of the document, even if it’s a lot words.
Sattish: Because many people work on document, loose ends are bound to occur, lets not make ourselves look like idiots and get a milestone where we can check if the document is consistent and makes sense.
Danny: I’m hearing: question Jeff is asking is how frequently do we adopt changes to the document, every issue, or every 3 months.
Peter F: Non-core is a euphemism for not-in-this-version.
Chris K: The definition of the core is the problem.
Sid: Basic engineering requires we address the foundation.
Harvey: Suggest we revisit this Friday.
Roll Call
Use Cases 15:20
John: Goal is to define scenarios where BPEL would be used in real world (a business-oriented view of BPEL). Method is to identify specific use cases. Looking at other organizations working on use-cases: W3C Choreography WG, CEFACT, JSR208.
Martin: WSI is also relevant.
John: Non-normative deliverables include descriptions of actors, processes, use-case diagrams, scenario developments (instances of a use case e.g. order process), sample BPEL representations. This will assist in the identification of issues in the spec. Identified supply chain usage scenario, and created is a use case catalogue.
Harvey: Focus of the catalogue is a place to capture: method of collecting and tracking, guidance for a minimum set of use cases, business context, use-case template, and catalogue. Scenarios are going to be driven by experts from business, not invented.
The method for managing this process includes collecting (from use case group, TC, and industry), synthesizing, tracking, and reporting. Reporting is important to satisfy potential user’s need to feel confident about the thought put into the use of the standard.
Business context, it’s like a sim-city for use cases, who owns what service who they talk to etc…The section includes actors, business flows, XML schemas.
The use case template defines what a particular use case looks like (see use-case document), includes various fields including id, name, description, submitter, champion, status, related issues, disposition, related business flows (see the business flows section; a BPEL use case would be within a business flow), actors (WSDLs), preconditions (boolean expressions), post conditions (boolean expressions), and an activity diagram.
The initial intent is to say this use case catalogue is used to produce complete BPEL for some part of the flow. The BPEL is complete but it is not all-encompassing (e.g. BPEL for some segment of the supply chain).
Chris K: A concern is that this might slow down the issue resolution process.
Harvey: This should not slow the issue resolution process; it will be a tool to help with the process. We’re hoping people resolving issues could make use of the use case catalogue.
John: There may be some dependencies between issues, use cases, and implementation.
We’re interested in feedback; take a look at the document on the OASIS site.
We’re starting small with simple-eb, this is a simple process with one buyer, one seller. We’re populating the use-case catalogue, started building BPEL representations for order handling. The template and the catalogue is a living document, please join us at conference calls on Monday.
Discussion of Goals Document
Paco: Idea was to model business processes in terms of web services: business processes use and are web-services. Base on WSDL 1.1, with an eye on developments in WSDL 1.2. Interactions are abstract, BPEL uses portTypes not ports, binding is not important.
Satish: Binding is not irrelevant though; we may rely on a reliable messaging as a transport in the process.
Paco: Goal #2 in this document was to base it on XML. BPEL is not concerned with graphical representation or any particular design methodology.
….
Paco: Also wanted to define a set of concepts that common to both internal (execution) and external (abstract) behavior. Common core means eventually we’ll be able to consume processes defined by other parties. Why common core for both abstract and executable? When attempting to describe system you end up modeling behavior of individual actors, many of the same concepts are relevant in both abstract and executable, and makes things simple for conformance verification, top-down development scenarios.
Nicholas: Conformance how is it defined?
Tony: The implementation should be less non-deterministic than the abstract.
Steve RT: When dealing with conformance, model checking, bi-simulation, there are issues of computational complexity.
Paco: There are algorithms..
Tony: Conformance is a refinement relation, less strict than bi-simulation. Weakest end of spectrum is simulation, which is too weak for conformance checking.
Steve RT: Please provide URIs.
Tony: We’ll dig those up.
Paco: Continuing… BPEL was to blend hierarchal and graph-like control regimes to reduce fragmentation of the process modeling space.
Steve Brown: Was this political?
Paco: Sure, but it makes sense.
Satish: This is not a vendor thing; it is an issue of trends.
Satish: Hierarchal is structured, like a structured programming language.
Danny: What about provability? With the combination of structured and flow are we loosing the ability to prove things we could prove in the flow-only world.
Dieter et al: No… couldn’t prove much in WSFL.
Steve RT: What about the request for some formalism in BPEL? What are the formal underpinnings?
Satish: If we go formal we will spend a lot of time with not too much benefit.
Nicholas: Can combo of flow and structure be modeled with pi-calc?
Satish: Sure, its Turing-complete, you could model integers with it.
Sid: There is room for clarification and through formalism we could discover issues.
Chris K: We should at least map the functionality of BPEL to the workflow patterns identified by the ….
…
Sid: Operational semantics would be useful.
Nicholas: We talked about conformance, this is something from process calculus, but we won’t define the semantics in terms of a process calculus.
Tony: You don’t have to use pi-calculus to talk about conformance.
Paco: BPEL wanted to take a pragmatic approach, didn’t want to get into wars about which formalism to use.
Danny: Is it correct to say that it would be harder to define formalism for this composite block, flow model than for either block or flow alone?
[consensus]
Diane: Motion to bless graduate students who work on this problem.
Paco: Continuing… we wanted to provide for only limited data manipulation necessary for data and control flow. Assumptions are that process variables do not constitute a general data store, most complex data manipulation occurs in WS invoked by process, and it is enough to provide basic data extraction for us in flow control and simple.
Peter: Rearranging message pieces can get arbitrarily complex, leads to utility web services used only to transform data.
Yaron: BPEL is inherently static, can’t go dynamic.
Chris: We don’t want to get to the point where we’re creating web services just to enable the process to call another operation (with a different message format).
Satish: That’s why we have issue 11, etc..
Yaron: No one believes that the spec is done.
Danny: Where is the line, should we even have <assign>?
Satish: I’m not uncomfortable with 11, but I’m uncomfortable with some of the fully generalized data manipulation.
Harvey: Seems like there’s some tension between providing LRT functionality versus building a general programming language.
Steve Brown: Why not delegate all non-critical functionality to javascript or something.
Tony: You’d have to be careful about maintaining the ability to do refinement, model checking…
Chris K: There is lots of overhead introduced when you export too much out of BPEL.
Peter F: You could supply XSLT in a <invoke> wrapper, ends up being the same thing.
Danny: Market will drive a lot of this.
[ended on a very pessimistic note, with all vendors implementing a bastard standard].
Paco: Continuing…. Wanted to support identification mechanism for process instances that allow the definition of instance identifier at the application message level. Instance identifier should be partner defined and could change over time.
Wanted to support implicit creation and termination of process instances as the life-cycle mechanism. Some talk of advanced lifecycle operation in later version (suspend/resume). This was to keep it simple, didn’t have to build anything on top of basic WSDL model. This does not preclude using a factory pattern.
Also wanted to define a long-running transaction model that is based on practically proven techniques like compensation.
[some discussion on the implication of replacing saga-like compensated transaction with coordinated two-phase transactions, and how this has to be deliberate]
Paco: Continuing, Web-services were to be the model for process decomposition and assembly.
BPEL should also build on compatible web services standards where possible.