RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit additionof intents based on a service or reference's @requires list]

[Mike Edwards <mike_edwards@uk.ibm.com>]

Michael,

Regarding the delivery of emails - I
think the OASIS email lists are set up in a way that the "ReplyTo"
field is set to
the originator of the message, not to
the list itself (I think this is odd, since replies by default dont go
to the list, which is
not expected behaviour as far as I am
concerned).  Anyway, I've assured that this reply DOES go to the list.

OK, I've put comments inline as <mje>
 </mje>

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

"Poulin, Michael" <Michael.Poulin@uk.fid-intl.com>

30/10/2007 14:18

To	Mike Edwards/UK/IBM@IBMGB
cc
Subject	RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit addition of intents based on a service or reference's @requires list]

Michael,
 thanks for the response
my message is not delivered to the OASIS side somehow...
 
I do not think we have a terminology
problem here but dealing a lot with people in SOA RM and RA TCs, I used
to separate information positioned in/for the service interface (including
binding and end-points in this cases) and the service body/implementation.
Plus, the major source of the service, as a whole, characteristics come
from the Service Description document rather than from its interface.

<mje>But there is
no such thing as a "Service Description document" in SCA.  This
may be a fault in SCA, but it is not surprising that SCA does not describe
things in those terms. </mje>
 
I accept that these specs are
at very high level of abstraction while SCA should be concrete. Nevertheless,
described approach dictates that any information (mandatory of optional
to the service users) attached to the service interface has to be about
interface, related communication channel and invocation aspects - policies,
in particular, -  not more. Everything else - execution context (business
and technical), execution policies, business affecting service intermediary
results and others belong to the Service Description and outlined in the
Service Contract documents. That is, not everything may be a subject for
service developers an/or programmatically accessible.

<mje>I tend to agree
with the concept that the interface should only include intents that affect
the interaction between client and provider of the service using the interface.
</mje>
 
Saying this, let me elaborate
a little on my questions:
1) are you in vision that intents
in the interface should be applicable to ALL interface users and never
would have a 'variable' part specific to one user and not applicable to
another one?  <mje>Yes
</mje> 
2) this is a reaction to the words
"service characteristics" which I explained already
3) this relates to 2) and proposes
the use of "service interface characteristics" in the
intents used in the interface code.
<mje>I think I'm OK with this refinement of words  </mje>
 
About service instance, I do not
consider Web Service a service because it does not govern anything behind
the interface, i.e. it is rather an interface to a SOA service which may
have multiple interfaces, each of which may have multiple communication
protocols/bindings and end-points depending on execution context.
 
About "In SCA, things
are built up in stages", this is OK to me when is applicable to
the service body implementation ( which ma be very complex or simple) but
not acceptable for the service interface design. This one must be thought
through as far as possible, it has to be based on the business modelling
and not on the Agile Methodology (which is suicidal for interfaces in big
corporations). So, if an intent is in the interface, it is for long time
to be there.

<mje>I disagree on
this point.  Let me explain the stages I see.  A service may
certainly start with the (business) interface definition, which describes
operations and the messages related to those operations.  However,
once you want to make the service concrete, other information is added
to the basic interface definition.  In SCA, this includes information
such as the Binding to use, endpoint information and so on.  Requirements
"or characteristics" can be applied in different places within
SCA.  The requirement for confidentiality can be applied to the interface
- meaning that encryption is required for all uses of a service using the
interface.  However, SCA allows for confidentiality to be applied
selectively to a particular service or to a particular binding of a service
(assuming it is not already applied to the interface) - for example, confidentiality
may be applied to a Web service binding (for reason that communication
may go outside the company...) while not being applied to a JMS binding
(since messages only flow within the company infrastructure...).  
These are the layers in SCA to which I refer.

Which approach is used
depends on the nature of the service.  Either approach may be valid
in different circumstances.  </mje>
 
Finally, since an intent is a
restriction, I do not see much sense in the restriction like "service
has to be compliant with MiFID" (or SOX - in the US) attached to the
interface because compliance may be achieved in the service implementation
only. At the same time, such restriction in the Service Description/Contract
is quite valid. Again - things in the interface are for the interface.

<mje>Well, whether
a particular restriction makes sense on an interface is a good point of
debate.  Some certainly do apply to the interface.  Others don't.
 Again, I ask whether the concept of a Service Description/Contract
needs to be introduced into SCA.  IF it affects the potential behaviour
of a client, then it may need to be introduced.  However, it's not
a concept that I am familiar with, so I'll  leave it up to yourself
and other experts to make the case, or not. </mje>
 
Since service owns its interfaces,
intents in the interfaces relate to the service, of cause, but it has to
be clear articulated that they describe service interface characteristics,
I believe.

<mje>"a service
owns its interfaces" is a curious phrase.  It may be that the
interface is "owned" elsewhere and simply used or referenced
by a particular service.  Examples may include industry-standard interfaces
used to ensure interoperable trading, for example.</mje>
 
Thank you again,
- Michael Poulin

---

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: 30 October 2007 13:11
To: Poulin, Michael
Subject: RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit
addition of intents based on a service or reference's @requires list]


Michael, 

Is there a terminology problem going on here? 

I've tried to tease out the issues inline..... 

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

"Poulin, Michael" <Michael.Poulin@uk.fid-intl.com>

30/10/2007 11:38

To	Mike Edwards/UK/IBM@IBMGB, <sca-policy@lists.oasis-open.org>
cc
Subject	RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit addition of intents based on a service or reference's @requires list]

Folks, 
  
How these intents will work in reuse - provider developers have no clue
who will be using this interface? 

<mje> By attaching intents to an interface it implies that the characteristics
required by the intents must apply to *ALL* usages of the interface.
Sure, the provider developer has no clue about who will use the interface,
but the interface designer is saying that WHOEVER the client is,
they must accept the characteristics implied by the intent.  An interface
marked "conversational" has relationships between one invocation
and the next - it is no use the client trying to treat all invocations
as stateless, since that will likely produce the wrong results</mje>
  
How these intents will work in SOA Service Contract document - provider
agrees with individual consumer on service features available to particular
consumer only? 

<mje> No, the intents are going to affect the bindings that are used
for invoking the service.  Some intents will force the use of bindings
in a particular way - eg "confidential" implies the use of some
form of encryption, so eg HTTPS must be used, not HTTP, or Web Services
with some level of WS-Security applied....</mje>
  
I think that words have to be more accurate in "it
is appropriate to use them to specify characteristics of the service that
both the developers of provider and the client need to know":
 SOA service may have characteristics useful to the consumer but not
visible through the interface ( SOA RM and RA draft), i.e. an interface
is not necessary the right place for the "characteristics
of the service ".

<mje> Here is the terminology problem.  What do you mean by
"characteristics of the service"?  Does this mean a given
instance of the service, with a particular binding applied?  I agree
that the concrete service, with binding resolved, may have more information
about it than is specified in the interface.  The binding (and indeed
the service implementation) may choose to add arbitrary metadata that the
client configuration must be aware of (clearly, the binding type, endpoint
address, plus features implied by applied policies such as security).  However,
this does not invalidate the idea that some characteristics are inherent
in the interface itself - and apply to ANY use of the interface, whether
on a service or on a reference.  It is these characteristics that
are validly attached to the interface itself.  In SCA, things are
built up in stages and it is not necessary that all metadata is lumped
into one place (indeed, it is intentionally added in a number of places
to provide useful and needed flexibility). 
</mje> 
  
I would say that these intents are fine for description of the characteristics
of the INTERFACE, not the service per se. 

<mje> Given that the interface has no existence outside of its use
to describe a service or a reference, I argue that the intents on the interface
contribute to the eventual set of intents on the service / reference and
contribute to the selection of bindings and associated policies.  Remember
that intents express restrictions, which can accumulate in layers.  It
is acceptable for an interface to say that it requires confidentiality
for messages sent through the interface - and for a service that uses the
interface to then add a further restriction that a client must authenticate
itself in order to use the service.  Both sets of intents apply to
that service's use of the interface....  Ultimately, all the intents
become a characteristic of the service (or reference).</mje>

  
- Michael Poulin

Important: Fidelity Investments International (Reg. No.1448245), Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity Pensions Management (Reg. No. 2015142) and Financial Administration Services Limited (Reg. No. 1629709, a Fidelity Group company) are all registered in England and Wales, are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity’s website - http://www.fidelity-international.com/world/index.html

---

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: 30 October 2007 10:38
To: sca-policy@lists.oasis-open.org
Subject: RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit
addition of intents based on a service or reference's @requires list]


Folks, 

Some suggested wordsmithing. 

Required Intents on Interfaces 
 
Intents can optionally be applied to interfaces. For WSDL Port Type elements
(WSDL 1.1) and for WSDL Interface elements (WSDL 2.0), the @requires attribute
can be applied that holds a list of intent names that are required for
the interface.  Other interface languages may define their own mechanism
for specifying a list of required intents.  Any service or reference
that uses an interface with required intents implicitly adds those intents
to its own @requires list. 
 
Because intents specified on interfaces can be seen by both the provider
and the client of a service, it is appropriate to use them to specify characteristics
of the service that both the developers of provider and the client need
to know.  For example, the fact that an interface is conversational
is such a characteristic, since both the client and the service provider
need to know about the conversational semantics. 


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

"Michael Rowley" <mrowley@bea.com>

29/10/2007 17:59

To	"Patil, Sanjay" <sanjay.patil@sap.com>, <sca-policy@lists.oasis-open.org>
cc
Subject	RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit addition of intents based on a service or reference's @requires list]

I took an action item to specify more specific text to add to the Policy
spec for resolution of issue 7. 
 
It was a real pain to avoid the word “should” when I was trying to describe
how the construct should be used.  I eventually succeeded, but as
I mentioned on the call, I’m not sure that it will be worth while to do
this throughout the spec.  Take a look at the Java EE spec (71 uses)
or the JPA spec (67 uses) and try to imagine getting rid of all those shoulds
and using other language instead.  Looking at WS-BPEL 2.0, you can
see that it uses both “SHOULD” and “should”, and has 24 uses of the
latter.  The capitalized form is used when describing what compliant
systems SHOULD do, while the latter is used to describe what people should
do. 
 
Now to the suggested new text... 
 
I would propose that a new section be added somewhere that the editors
think is appropriate (probably somewhere inside the section titled “Attaching
Intents and PolicySets to SCA Constructs”). 
 
Required Intents on Interfaces 
 
The @requires attribute can be applied to WSDL Port Type elements (WSDL
1.1) and to WSDL Interface elements (WSDL 2.0) that holds a list of intent
names that are required for the interface.  Other interface languages
may also define their own mechanism for specifying the list of required
intents.  Any service or reference that uses an interface with required
intents implicitly adds those intents to its own @requires list.
 
Because intents specified on interfaces can be seen by both the provider
and the client of a service, it is appropriate to use them to specify characteristics
of the service that both the developers of provider and the client need
to know.  For example, the fact that an interface is conversational
is such a characteristic, since both the client and the service provider
need to know about the conversational semantics. 
 
Michael

---

From: Michael Rowley [mailto:mrowley@bea.com] 
Sent: Thursday, October 25, 2007 10:54 AM
To: Patil, Sanjay; sca-policy@lists.oasis-open.org
Subject: RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit
addition of intents based on a service or reference's @requires list]
 
 
We don’t currently have an operational distinction between implementation
intents and interaction intents.  We define the terms, but none of
our mechanisms are tied to those terms. 
 
With the current definition of intents on interfaces, references that use
an interface implicitly require all intents specified on that interface.
 This certainly fits interface intents such as “conversational”
and “joinsTransaction” well.  If we changed the semantics, I’m
not sure what we would change them to. 
 
Michael

---

From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
Sent: Thursday, October 25, 2007 10:37 AM
To: Michael Rowley; sca-policy@lists.oasis-open.org
Subject: RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit
addition of intents based on a service or reference's @requires list]
 
 
Are we ruling out the possibility of annotating interfaces with intents
for any implementation policies? For example, an interface with operations
whose invocations should be audited may be annotated with @requires("auditing").
 In this example, the client does no have to be aware of the intents
on the interface, I believe. 
 
-- Sanjay

---

From: Michael Rowley [mailto:mrowley@bea.com] 
Sent: Tuesday, Oct 23, 2007 8:04 AM
To: Patil, Sanjay; sca-policy@lists.oasis-open.org
Subject: RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit
addition of intents based on a service or reference's @requires list]
 
I don’t think it is possible to have an intent on an interface and _not_
have the client see it, since the client sees the interface.  E.g.:
 
@requires(“confidentiality”) 
interface Foo { 
  ... 
} 
 
 
Michael

---

From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
Sent: Monday, October 22, 2007 6:51 PM
To: Michael Rowley; sca-policy@lists.oasis-open.org
Subject: RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit
addition of intents based on a service or reference's @requires list]
 
 
Do we need to limit the use of intents on interfaces to cases where the
intents are part of the contract between the provider and the contract?
Why shouldn't we leave the door open for allowing interfaces to declare
requirements for implementation policies (that are not necessarily visible
to the clients)? 
 
I think it may be enough description to say that - "Intents may also
be specified on an interface and when present, they apply to the Services
and Reference using that interface". 
 
Rest of the proposal looks good to me. 
 
-- Sanjay

---

From: Michael Rowley [mailto:mrowley@bea.com] 
Sent: Monday, Oct 22, 2007 14:56 PM
To: sca-policy@lists.oasis-open.org
Subject: RE: [sca-policy] ISSUE 7: Required intents on interfaces [Implicit
addition of intents based on a service or reference's @requires list]
The policy spec should also describe why an intent should be placed on
an interface.  I would propose something like the following:
 
“Intents should be specified on interfaces when they should be seen by
both the provider and the client of the service and should be treated as
part of the contract between provider and the client.”
 
I believe that the policy set selection algorithm also needs to be modified
to reflect these semantics.  We could do this by adding a step between
step A2 and A3 which says: 
A 2.5.  If the target element is a binding, include all required intents
defined on the interface that provides the type for the service or reference
that the binding is on (i.e. follow this path: binding->service->interface->@required).
 
Michael

---

From: Joshi, Kaanu [mailto:Kaanu.Joshi@patni.com] 
Sent: Wednesday, October 17, 2007 2:04 AM
To: sca-policy@lists.oasis-open.org
Subject: [sca-policy] ISSUE POLICY-7: Required intents on interfaces
[Implicit addition of intents based on a service or reference's @requires
list] 
 
Hi, 
 
Please find the link to the JIRA system: http://www.osoa.org/jira/browse/POLICY-7
 
The subject has been modified to: Implicit addition of intents based
on a service or reference's @requires list 
 
Regards, 
Kaanu Joshi 
 
PS: In conformance with newly adopted issues process.

---

From: Michael Rowley [mailto:mrowley@bea.com] 
Sent: Monday, October 08, 2007 9:12 PM
To: sca-policy@lists.oasis-open.org
Subject: [sca-policy] NEW ISSUE: Required intents on interfaces
 
 
TARGET: SCA Policy Framework Specification 
 
DESCRIPTION: 
The input specification to the SCA Assembly TC has the following paragraph
starting at line 900: 
 
The @requires attribute can be applied to WSDL Port Type elements (WSDL
1.1) and to WSDL Interface elements (WSDL 2.0).  The attribute contains
one or more intent names, as defined by the
Policy Framework specification [10].
Any service or reference that uses an interface with required intents implicitly
adds those intents to its own @requires list. 
 
However, the policy framework specification has no description of what
it means for a policy intent to be required by an interface.  I believe
this definition belongs in the policy framework specification.
 
PROPOSAL 
 
Add this paragraph (or something similar) to the policy framework specification.
 

http://www.patni.com
World-Wide Partnerships. World-Class Solutions. 
_____________________________________________________________________ 

This e-mail message may contain proprietary, confidential or legally privileged
information for the sole use of the person or entity to whom this message
was originally addressed. Any review, e-transmission dissemination or other
use of or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited. If you have
received this e-mail in error kindly delete this e-mail from your records.
If it appears that this mail has been forwarded to you without proper authority,
please notify us immediately at netadmin@patni.com and delete this mail.
_____________________________________________________________________

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU