OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with no binding to a service with a binding


Hi Simon,

Since we are owning both SAP SCA & SAP JMS , I assure you it's not that
hard :).

Btw, the point about the classloaders and parameters brings interesting
discussion,  it's connected with  usage of SDO, XML, serialized
bytecode, maybe we could discuss in more details on some of the incoming
F2F meetings if we have the chance.

Back to the "party spoiling", I would say that in order to have "JMS
observable semantics" there should be JMS intent.

At least to me that is as result of Mike E.'s writings which I am very
happy with  - 

If the reference or the service requires a particular protocol for some
reason, then that need 
should be expressed via an intent and the presence of the intent would
then limit the range of 
protocols that can be used. 

Best Regards
Peter

-----Original Message-----
From: Simon Nash [mailto:NASH@uk.ibm.com] 
Sent: Thursday, 6. December 2007 22:59
To: Peshev, Peter
Cc: OASIS Assembly
Subject: RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference
with no binding to a service with a binding

Peter,
I'll admit that I know very little about JMS (though I intend to learn 
much more).  I used JMS as an example to make a point, and from your
reply 
I believe that I have made it reasonably effectively.  If these are the 
semantics of using "real JMS" to make a call, then any optimization must

preserve the same semantics.  This does not look very simple!

I do have some relevant experience, though not for JMS.  In a past life,
I 
implemented local calling optimizations for RMI-IIOP, and there were
some 
"interesting" wrinkles including very careful attention to cases
involving 
different classloaders at the source and target ends.  In that case, 
correct semantics could only be preserved by baking this optimization
into 
the RMI-IIOP runtime.  I think the same is likely to be the case for
JMS. 
Replacing the JMS invocation by some other kind of "optimized" local
call 
doesn't seem likely to preserve all of the expected semantics.

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



"Peshev, Peter" <peter.peshev@sap.com> 
06/12/2007 17:36

To
Simon Nash/UK/IBM@IBMGB, "OASIS Assembly" 
<sca-assembly@lists.oasis-open.org>
cc

Subject
RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with no 
binding to a service with a binding






Hi Simon,

can we clarify first the "observable JMS semantics" .

 For queues it is guaranteed that there will be exactly once delivery,
there will be no side effect. (Assuming the local call deals with
crashes and provides the quality of service required by the intents)

For JMS topics it is  quite different,  where as side effect of a call
to a service, a message should be sent, and another service from another
component on the same topic could be invoked. Such usage of topics
coincides pretty much to some pub/sub messaging model that let's say is
in scope of this TC to discuss.


Is this your understanding as well ?

Best Regards
Peter


-----Original Message-----
From: Simon Nash [mailto:NASH@uk.ibm.com] 
Sent: Thursday, 6. December 2007 17:55
To: OASIS Assembly
Subject: RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference
with no binding to a service with a binding

I don't want to spoil the party, but...

It's clearly fine to do this local optimization for <binding.sca>.  But
it 
is OK to do this for <binding.jms>?  To make this safe, it would be 
necessary to ensure that all observable JMS semantics are preserved.
Are 
we agreed that any local optimization would need to do this?

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



"Peshev, Peter" <peter.peshev@sap.com> 
06/12/2007 14:03

To
Mike Edwards/UK/IBM@IBMGB, "OASIS Assembly" 
<sca-assembly@lists.oasis-open.org>
cc

Subject
RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with no 
binding to a service with a binding






Hi Mike,
 
At least to me that's very good model and clear description that solves 
nicely  ASSEMBLY-1 & 31 as long the last paragraph is kept.
 
Best Regards
Peter
From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] 
Sent: Thursday, 6. December 2007 11:36
To: OASIS Assembly
Subject: RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference
with 
no binding to a service with a binding


Peter, 

After some private discussions of the issues with Dave, I now believe
that 
Dave's proposal is 
the right one.  The treatment of services should not be exactly the same

as the treatment of 
references. 

Creating a proxy object for a reference is a very different process from

the business of 
creating an endpoint for a service. 

It is reasonable for an SCA runtime to know in advance what endpoints it

has to create for 
the services present in the domain - and that the idea that new
endpoints 
have to be created 
merely to satisfy a new client reference turning up somewhere in the 
domain is not reasonable. 

So, I think that the principle for a service needs to be that there will

be an endpoint created 
for each binding explicitly declared for the service, with the existence

of a binding.sca 
endpoint IF no explicit binding is specified. 

The point you make in the last paragraph below, I believe DOES apply to 
references.  So, for 
a reference, a "binding.sca" (either implicit or explicit) can be taken
to 
mean "give me a connection 
to the target service(s), using whatever communication means are 
available".  In this case, 
I think that the proxies given to the component for the reference could 
each deal with a separate 
protocol and that the protocol used simply "matches" the target
service's 
protocol. 

I agree - in these cases the protocol used by the proxy is irrelevant to

the implementation code. 

IF the reference or the service requires a particular protocol for some 
reason, then that need 
should be expressed via an intent and the presence of the intent would 
then limit the range of 
protocols that can be used. 

So, I think it gives us a clean model where: 

a) For services, you get endpoints for each explicitly declared binding,

with the default of 
binding.sca if there is no explicit binding.  Multiple bindings imply 
multiple endpoints. 

b) For references, you get proxies using any of the declared bindings, 
with the default of 
binding.sca if there is no explicit binding.  The binding actually used 
for a given wire depends 
on the binding(s) attached to the target service, where the principle is

to select compatible 
bindings (for the moment, I take that to mean the binding types must be 
the same). 
In addition, binding.sca is "flexible" for the purposes of wiring and
will 
match ANY binding 
on the target service(s). 

I think that this is the simplest model and avoids the problem
associated 
with the model which 
you have proposed, that binding.sca may or may not be present depending
on 
whether it 
can or cannot satisfy the intents attached to the reference. 

I think that the model I propose has the merit of simplicity and 
encourages the creation of 
simple compositions, where most references to targets within the domain 
either have no 
explicit binding at all (the 80% case) or have binding.sca attached,
while 
any service endpoints 
which need an explicit binding attached in order to be available outside

the domain don't 
have to be concerned about additional endpoints being necessary for 
clients within the 
domain. 

I note that the principle of "optimised communication" between clients
and 
providers that 
run on the same machine or within the same process, is not affected by 
this model.  The 
runtime is ALWAYS free to optimise communications, as long as the 
interfaces to both 
client and provider code are honoured. 



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 

"Peshev, Peter" <peter.peshev@sap.com> wrote on 06/12/2007 08:51:22:

> Hi Mike,
> 
> OK, I understand we have different opinion between me and you + Dave
> 
> But can you help me understand why ? I guess you are afraid that the
> component may break without binding.xyz in the scenario below. However
> the contract between the SCA assembly and the programming technology
is
> the interface that is on the service. If the SCA runtime can construct
> objects fulfilling the interface, then what is the problem ?
> 
> I.e. does it makes a difference for a component with interface.wsdl
> whether its XML-ish  data objects in the interface were received via
> HTTP POST operation, via SOAP over JMS, or by direct local call ?
> 
> Best Regards
> Peter





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







---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 








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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]