agree with bug, but some clarification since we wll not fix until next cycle.

I think variable is optional because BPEL 2.0 allows "toPart" and "fromPart" to
be specified instead of variables. However, since we don't yet support
"fromPart" or "toPart" , we should treat variable as required. However, by the
time we fix this, next release, we may support the fromPart and toPart. At that
point the rule should probably be that either "fromPart/toPart" OR variable are
required.



	<complexType name="tReceive">
		<complexContent>
			<extension base="bpws:tActivity">
				<sequence>
					<element name="correlations" type="bpws:tCorrelations" minOccurs="0"/>
					<element name="fromPart" type="bpws:tFromPart" minOccurs="0"
maxOccurs="unbounded"/>
				</sequence>
				<attribute name="partnerLink" type="NCName" use="required"/>
				<attribute name="portType" type="QName" use="optional"/>
				<attribute name="operation" type="NCName" use="required"/>
				<attribute name="variable" type="NCName" use="optional"/>
				<attribute name="createInstance" type="bpws:tBoolean" default="no"/>
				<attribute name="messageExchange" type="NCName" use="optional"/>
			</extension>
		</complexContent>
	</complexType>

Denis, please determine if final versions of BPEL XSD will automatically provide
validation for such cases. 

Specifically, we need to understand if the basic XML validation will be more
rigorous for executable BPEL processes than it is will be for abstract BPEL
processes. In EP 5.5 we only have one bpel xsd , but in EP 5.5.1 I believe there
will be a specific schema for executable BPEL. Perhaps that will have more
strict validation in such cases. 

Otherwise, if this is not handled by basic XML validation, we can investigate
whether static analysis rule exists or should exist.

I believe this situation is covered by SA00047 
(Note - This was previously called SA00048 in earlier version of spec)

One-way invocation requires only the inputVariable (or its equivalent <toPart>
elements) since a response is not expected as part of the operation (see section
10.4. Providing Web Service Operations – Receive and Reply ). Request-response
invocation requires both an inputVariable (or its equivalent <toPart> elements)
and an outputVariable (or its equivalent <fromPart> elements). If a WSDL message
definition does not contain any parts, then the associated attributes variable,
inputVariable or outputVariable, MAY be omitted,and the <fromParts> or <toParts>
construct MUST be omitted.

According to http://enterprise.netbeans.org/specs/bpel/StaticAnalysisRules.html
this was implemented by ads. So, perhaps there is some confusion over the
interpretation of this rule?  Denis? Do you agree that this rule should cover
the situation described by Sasha Pepin?

One thing I do not understand. I do not understand the error message from the
Composite App deploy. This error message does not seem to be consistent with
this use case. But, I think, that is a different issue. The primary issue for us
 is the validation rule not detect this use case.

Note to QE - the rule is quite complex and there are several variations that
need to be tested. For instance, IF a WS operation does not specifiy a message
(input or output) then the input or output variable / FromParts/ToParts are not
required. So these are NOT ALWAYS required - they are only required when WS
operation specifies a message type.

adding SA00047 to this but summary. Please note that in latest BPEL spec this is
now called SA00047. In previous version this was SA00048. We need to adjust our
static analysis document to be consistent with new spec. I will do so.

Mike's description is correct and incorrect.
Mentioned rules is implemented by me. And issue is about similar situation.
But not the same.
Mentioned rule is ONLY about invoke.
We need to handle situation with variable and "toPart" or "fromPart" elements
for Receive and Reply.

There is no static analysis rule for Receive and Reply elements.
So we don't have implemented rules for this issue.

I'm going to implement them, but here is a question:
is deploy action already changed in the way of checking presence "fromPart",
"toPart" elements in the case of absence "variable" attribute ?
Because otherwise we need to implement separate rule in RuntimeNotSupported 
validator for checking "variable" attribute presence in any case.

One more about Static analysis rules set:
THERE IS static analysis rule that handle this situation, but OUR static analysis
rule set ( in the netbeans site) doesn't contain it.
Mike is right it is SA00047 but it doesn't correspond any old number in curent
document.

One more time I want to point here this rule ( please note that it is not about
invoke ).

One-way invocation requires only the inputVariable (or its
equivalent <toPart> elements) since a response is not
expected as part of the operation (see section 10.4. Providing
Web Service Operations  Receive and Reply ). Requestresponse
invocation requires both an inputVariable (or its
equivalent <toPart> elements) and an outputVariable (or
its equivalent <fromPart> elements). If a WSDL message
definition does not contain any parts, then the associated
attributes variable, inputVariable or outputVariable,
MAY be omitted,and the <fromParts> or <toParts>
construct MUST be omitted.

Hi Murali, can you answer Denis' question regarding deploy ?

I added necessary logic for Receive and Reply.

Mikhail, please verify the issue was fixed

Verified: the requested checks are implemented for receive and reply, after
following the steps in description the process could not be validated.