[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 Hi 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 hierarchy 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 = domainContext.getComponentContext(componentUri); 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. Thoughts? Jim > 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]