Specification of 'ping' type service task

tstephen commented 10 years ago

Background

This is an attempt to merge #181 and #182 including feedback thus far received into a single problem definition and alternative possible solutions.

A 'ping' type service arose in discussions of serviceTask interchange in an attempt to simplify the many challenges to just those where no data is involved.

In common with the wider approach of the working group we also want to start from simple examples to maximise the amount of interchange that can be achieved and then use that as a beach-head from which to build.

Relevant references to the spec

From p213 (PDF p243):

    [An ioSpec contains] An optional reference to 
    the Data Inputs of the InputOutputSpecification. If the 
    InputOutputSpecification defines no Data Input, it means no 
    data is REQUIRED to start the Activity. This is an ordered set.

This statement is made for service tasks on p158 (PDF p.188):

    In addition the following constraints are introduced 
    when the Service Task references an Operation: The Service Task has 
    exactly one inputSet and at most one outputSet. It has a single Data 
    Input with an ItemDefinition equivalent to the one defined by the 
    Message referenced by the inMessageRef attribute of the associated 
    Operation. If the Operation defines output Messages, the Service Task 
    has a single Data Output that has an ItemDefinition equivalent to the 
    one defined by the Message referenced by the outMessageRef attribute 
    of the associated Operation.

Summary of discussion

The first quote suggested that it would be possible to fully specify the serviceTask in A.1.1 by the following snippet. Note that it omits not only the current ioSpecification/inputset/dataInputRefs that repeat the dataInput but the ioSpecification in its entirety:

        <semantic:serviceTask implementation="##WebService" completionQuantity="1" isForCompensation="false" startQuantity="1" name="Task 2" id="task2" operationRef="operation1">
            <semantic:incoming>_1a66ccd9-a80c-44bc-a06f-a684b8370443</semantic:incoming>
            <semantic:outgoing>_725826e9-0e8b-4cb4-842b-e0279515d821</semantic:outgoing>
        </semantic:serviceTask>

However the second quote appears to block that approach, but thus far no one has spoken in defence of the constraint. Therefore the proposal is to 'correct' (relax) this constraint in some way.
Possible solutions

The following alternatives are offered for discussion with the view that one be selected as the proposal of the group:

Do nothing, the constraint is needed (presumably by some fact not yet raised).
Make the constraint apply only to ##WebServices.
Remove the constraint altogether for all values of the implementation attribute since currently legitimate web services cannot be called (both the ping-type and also Out-Only message exchange patterns).

apupier commented 10 years ago

I vote for the solution #3 Until no one raised a constraint needed, we should not keep 1 For ##webservices, I'm not an expert but some guys in the group says that it is possible to have a "ping" webservice (and personally I don't see why we couldn't). so it make sno sense to keep it for ##webservices.

falko commented 10 years ago

Out-Only message exchange patterns can be realized with a Send Task, which has a similar constraint.

ehelmste commented 10 years ago

I vote for 1. As a constraint : an Operation (referenced by a ServiceTask) must define one input message, when executing the data of this message must come from somewhere, if the ServiceTask does not define a DataInput, where will the data come from ?

SimonRinguette commented 10 years ago

During the June 18th 2014 webmeeting, this issue was discussed and a 4th possible solution was put forward:

4- The constraint should be rewritten to say that inputSet and outputSet cardinality should match the referenced Operation. The operation input/output parameter current cardinality (1 to many) should be changed to 0 to many. While it may be required to have parameters (input/output) for web services, many other implementations (java/rest/etc...) are valid use cases where they have operations that do not require parameters.

falko commented 10 years ago

I vote for 4.

A very simple example that shows, that BPMN 2.0 is not as technology-agnostic as intended, is invoking the GET operation on a REST resource: The resource URL (interface endpoint) and the HTTP verb (operation name) are enough to have a meaningful service invocation that is much more than just a ping. In fact GET is the most widely used HTTP operation.

tstephen commented 10 years ago

+1

— Sent from Mailbox

On Thu, Jun 19, 2014 at 10:24 AM, Falko Menge notifications@github.com wrote:

I vote for 4.

A very simple example that shows, that BPMN 2.0 is not as technology-agnostic as intended, is invoking the GET operation on a REST resource: The resource URL (interface endpoint) and the HTTP verb (operation name) are enough to have a meaningful service invocation that is much more than just a ping. In fact GET is the most widely used HTTP operation.

Reply to this email directly or view it on GitHub: https://github.com/bpmn-miwg/bpmn-miwg-test-suite/issues/184#issuecomment-46539957

dgagne commented 10 years ago

Webmeeting 25 June 2014 o Option 4 will be written as formal proposal for RTF by Eric

ehelmste commented 10 years ago

My proposal below. The modified parts of replacement texts are in italic. I hope I do not miss some pages, if you find some I will look into it.

Page 105 (page 135 of the PDF)

Chapter "8.4.3 Operation"

Original text:

An Operation defines Messages that are consumed and, optionally, produced when the Operation is called. It can also define zero or more errors that are returned when operation fails. The Operation inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.66 below presents the additional attributes and model associations of the Operation.

Replacement text:

An Operation defines Messages that are consumed and produced when the Operation is called. It can also define zero or more errors that are returned when operation fails. The Operation inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.66 below presents the additional attributes and model associations of the Operation.

Page 106 (page 136 of the PDF)

In "Table 8.66 – Operation attributes and model associations": cardinality of inMessageRef and outMessageRef must be relaxed to match 0..*

In "Table 8.68 – Operation XML schema": minOccurs and maxOccurs attributes for inMessageRef and outMessageRef elements must be modified to match:

<xsd:element name="inMessageRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="outMessageRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/>

Page 158 (page 188 of the PDF)

At the bottom of the page in the Service Task chapter.

Original text:

The Service Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints are introduced when the Service Task references an Operation: The Service Task has exactly one inputSet and at most one outputSet. It has a single Data Input with an ItemDefinition equivalent to the one defined by the Message referenced by the inMessageRef attribute of the associated Operation. If the Operation defines output Messages, the Service Task has a single Data Output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated Operation.

Remplacement text:

The Service Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints are introduced when the Service Task references an Operation: The Service Task has exactly the same number of Data Inputs as the associated Operation has inMessageRef elements. These Data Inputs need to be defined in the same order as the inMessageRef elements they represent in the associated Operation. Each Data Input has an ItemDefinition equivalent to the one defined by the Message referenced by the inMessageRef element it represents. The Service Task has exactly the same number of Data Outputs as the associated Operation has outMessageRef elements. These Data Outputs need to be defined in the same order as the outMessageRef elements they represent in the associated Operation. Each Data Output has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef element it represents. If at least one Data Input or Data Output is defined, the Service Task has a single inputSet that references all Data Inputs and has a single outputSet that references all Data Outputs.

ehelmste commented 10 years ago

For the first sentence of

Chapter "8.4.3 Operation"

Original text: "An Operation defines Messages that are consumed and, optionally, produced when the Operation is called."

During the meeting,

some proposed: "An Operation MAY define Messages that are consumed and produced when the Operation is called."
others proposed: "An Operation defines Messages that are optionally consumed and/or produced when the Operation is called."

I vote for option 2.

dgagne commented 10 years ago

Webmeeting 2 July 2014 o Discussion on the first sentence of Operation. We decided that “An Operation MAY define Messages “ would be used. o Discussion on whether this issue improves interchange or is simply a work around for a simpler test case. This change would certainly make for a simpler test case of service task in A.1.1 o The argument was made that a test case based on this proposed change would not be compliant with the current spec o It was then decided that this change would be proposed to the RTF but that the test case A.1.1 would only have User Tasks.

bpmn-miwg / bpmn-miwg-test-suite