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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

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

Subject: WG: implementation.client quick writeup

Sending this conversation to the wider group...

-----Ursprüngliche Nachricht-----
Von: Barack, Ron 
Gesendet: Donnerstag, 3. April 2008 18:54
An: 'Jim Marino'; Peshev, Peter
Cc: Michael Rowley
Betreff: AW: implementation.client quick writeup


Here is a presentation, that shows at least my views on the subject.

-----Ursprüngliche Nachricht-----
Von: Jim Marino [mailto:jim.marino@gmail.com] 
Gesendet: Donnerstag, 3. April 2008 18:46
An: Peshev, Peter
Cc: Barack, Ron; Michael Rowley
Betreff: Re: implementation.client quick writeup

On Apr 3, 2008, at 1:45 AM, Peshev, Peter wrote:

> Hi Michael and Jim,
> Just a few clarifications of the use case. The current "locateService"
> in our view doesn't bring anything into the picture. Technically it's
> not that different than a JNDI. The application developer has to  
> lookup
> something, cast it to an interface (or supply the interface in the
> lookup) and afterwards there is a call.
> If all we want to achieve is - client developer must not use the  
> binding
> specific API, but instead they should use SCA API locateService,  
> that's
> not a  big achievement.

> What's the difference between calling something exposed as binding.ejb
> and something exposed on the domain for the end user ?
> Context initialContext = new InitialContext(env);
> MyInterface interface = (MyInteface) initialContext.lookup(myString);
> interface.doSomething()
> DomainCompositeContext context == //obtain it somehow
> MyInterface interface = context.getService(MyInterface.class,  
> myString)
> interface.doSomething()
I sympathize with this view although I do see some value in  
locateService which most JNDI solutions don't provide, namely protocol  
transparency. With locateService, the client is not tied to a  
communication protocol. With WebLogic (and most app servers I'm aware  
of), proxies bound in the JNDI tree are usually restricted to a  
proprietary remote communications protocol. The locateService API  
would allow people to use protocols such as web services or JMS in a  
standard and transparent way. The advantage here is that a service  
could be bound with binding.ws, which would allow access from clients  
using locateService as well as something like JAX-WS. Also, the  
protocol could be switch, whereas most JNDI solutions I am aware of  
either do not allow this or restrict choices to a few binary protocols.

One other advantage is an implementation could potentially negotiate  
and set up policy transparently. However, once we get into this,  
implementation.client is likely a better choice.

That said, I think we may be able to obtain those advantages using  
implementation.client as opposed to locateService.

> With the implementation.client proposal it should be possible for the
> app. developer to reuse a lot of the "good SCA features"  - ability to
> configure what exactly client will call what (working with domain
> visibility reminds me of global variables), ability to configure
> something, all the tooling visualisation, concepts of promotion &
> recursive assembly, properties usage, callbacks, conversations, etc.
> Well the callbacks and conversations are not that useful, since they  
> are
> somewhat messy at the moment, but anyway ... ;)
I agree on the modeling. I disagree on callbacks on conversations  
being messy, but that's a different topic :-)
> How should we proceed, should we prepare a powerpoint presentation of
> the proposal for today's meeting ?
I spoke with Mike a bit yesterday, and I think we should work through  
a couple more issues. Before presenting something, I think we need to  
clarify the relationship between implementation.client and  
locteService. One thing that did come up is DomainContext is probably  
not the right name for the class that has locateService. Rather, it is  
more appropriate for implementation.client. That said, I would like to  
explore using implementation.client as a solution for what  
locateService is trying to do as well.

A big difference between the two approaches is that  
implementation.client says clients only talk to a domain at the  
protocol level; SCA facilities are only available to components. The  
locateService API, in contrast, provides some SCA facilities such as  
protocol transparency to clients that are not components.

A couple of use cases that have been brought up include:

1. Code that connects to domain level services (or services offered by  
domain-level componens)
2. Code that connects to services lower down in the domain composite  
3. Web application code, e.g. JSPs, that connect to services at an  
arbitrary level in the domain hierarchy

The locateService API right now is restricted to 1.  
Implementation.client offers a solution to 1 and 2 but models things  
in a fundamentally different way (the code is an implementation  
instance, not an unmanaged client). For #3, I think that is best done  
using implementation.web and autowire (or explicit wiring if people  
don't mind writing a lot more XML), not implementation.client or  
locate service.

I wonder if we could start by saying: what's wrong with  
implementation.client for cases 1-2?

The API would look something like this:

DomainContext domainContext = DomainFactory.connect(domainUri);
ComponentContext context =  

For the domain composite, we could have a rule that if  
implementation.client is not specified, one is synthesized containing  
references to all services offered by domain-level components, as well  
as properties (which locateService does not allow).

One of the big downsides to this is conceptually it is more confusing  
than just telling people code connects to the domain and looks  
services up. One way to deal with this may be to hide complexity by  
defaulting this behavior where people do not need to really understand  
what is going on under the covers.



> Best Regards
> Peter
> -----Original Message-----
> From: Jim Marino [mailto:jim.marino@gmail.com]
> Sent: Wednesday, 2. April 2008 00:54
> To: Peshev, Peter; Barack, Ron; Michael Rowley
> Subject: implementation.client quick writeup
> Peter and Ron,
> I'm copying Mike on this to see what he thinks since he has been
> working on the locateService proposal. Mike, I mentioned this to you
> in passing earlier...
> Target
> ---------
> I'm not sure if this is Java or Java and Assembly (I think it is both)
> Description
> -------------------------------------
> Currently, there is no specified way to support non-container managed
> component implementation instances in SCA. Specifically, the ability
> to configure a component and have implementation instances created by
> mechanisms other than the SCA runtime.
> The primary use case is as follows:
> 1. Assembler defines a composite.
> 2. As part of that composite, the assembler defines a component with
> properties and references (which are wired). The assembler declares
> the implementation to be "implementation.client" (or a better name) in
> the component configuration.
> 3. Composite is deployed
> 4. At some later point, existing code (i.e. code instantiated using
> mechanisms other than by an SCA runtime) "declares" itself to be a
> component implementation instance.
> 5. At this point, the code can access a ComponentContext, including
> the configured references and properties
> Proposal
> ------------------------------------------
> 1. Provide the ability to configure a component  using
> implementation.client. One restriction is these implementations do not
> offer services.
> 2. Provide an API for code to declare itself a component and access
> its ComponentContext. This can be done by adding a method to the
> DomainContext:
> DomainContext.getComponentContext(String uri);
> Notes and Issues
> -----------------------------------------
> - Implementation.client can be used at any level in the hierarchy
> - Should callbacks be allowed?
> - DomainContext.locateService could potentially be defined in terms of
> this mechanism. For example, implementation.client can be explicitly
> declared as a domain level component. Or, if none is explicitly
> declared, the domain could synthesize one containing references to all
> services offered by domain-level components and domain-level
> properties. This would change the semantic of locateService since all
> code would be treated as a component. A slight advantage to this is
> that an assembler can control what references (services) are visible
> at the domain level.
> - A disadvantage to this proposal is it breaks the dictum that SCA
> runtimes are in control of component lifecycle.
> I have a feeling this proposal may open up a can of worms...
> Jim


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