2 Replies Latest reply on Nov 24, 2010 12:08 PM by Tom Fennelly Branched from an earlier discussion.

    CDI - @Service annotation

    Tom Fennelly Master

      Thanks Keith.


      Could you elaborate on the @Remote suggestion?


      Elaborating on the @Remote suggestion... At the moment, we have it such that the service consumer references (changing to use your terminology... might make it easier) we inject into service consumers/clients are always proxies that capture the invocation parameters, wrap them up in an exchange and send the exchange to the Service using the ESB Exchange mechanism.  What Pete was suggesting (and I agree) is that we should make this explicit, only using an ESB proxy when the injection point has an appropriate annotation.  If this annotation is not present, then a reference to the actual @ESBService impl bean is injected i.e. invocations on that reference would not use an ESB proxy bean and the ESB Exchange mechanism.  My first suggesting was that this annotation could be called something like @Remote, but then I was thinking that we could just the same annotation as we're using to define the service i.e. @ESBService.


      You are putting operation name in the message context, but this should be in the exchange context, no?


      Yep... should be on the Exchange context.


      We are using the same annotation for declaring that a bean  implementation is a service as we are for declaring an interface as a  consumer reference.  I haven't thought through the ins and out of this,  but that may end up being a problem later on.  Then again, maybe not.  :-)


      If I'm reading you correctly.. presently we're not using any annotation (aside from the standard @Inject) for declaring a consumer reference, but we are suggesting that we should and I'm currently suggesting that we use the same annotation (i.e. @ESBService).  I agree that this might cause isues down the road (not sure what), but would like to try it initially anyway just to see.  For obvious reasons, I think using the same annotation is easier for developers using this.


      How do we plan on dealing with non-object payloads (e.g. XML, JSON,  etc.)?  Obviously this can be handled through handlers or other  services, but my point is how would this be expressed easily by the  developer that is adding the @Service annotation to provide or consume a  service from a bean?


      Yeah... been wondering about this too.  To me, this is a more general transformation issue and so is probably part of a wider discussion.


      I don't think it makes sense to define transformation details on the @ESBService itself because that has implications all the way back.  I don't really like the idea of defining them on the Consumer class either because I think that's hardwiring details into the consumer + requires the consumer to have detailsed knowledge of the provider (tight coupling etc).


      Ideally, I think transformation details should be defined as part of each possible Exchange, so that different transformations can be defined, depending on the source/target details of the exchange.


      Some random use cases...


      1. CDI <-> CDI:  No transformation required, or a Java to Java transform (e.g. where the API changed in a new version).  Or perhaps you want Java <-> JSON <-> Java on the exchange, where JSON is what's sent between sender and receiver etc etc
      2. File Component <-> CDI:  Obviosuly depends on the file payload e.g. XML to Java.
      3. CDI <-> XML Consumer Service: Java to XML
      4. etc


      How will this work in an environment where Weld and SwitchYard are  deployed as indpedent services?  Lifecycle and classloading are two  sticky points that need to be resolved.


      Yeah... this is something that I'm wondering about too.  I'm going to start playing with some Seam and Weld+JSF examples.


      However, I have been thinking that the consumer side of the equation needs to be able to "see" @ESBService contracts (Java interface for now) without visibility on the actual @ESBService impls (as is now the case).  The @ESBService impl shouldn't even need to be deployed yet (or could be remote).  But this probably goes back to how the registry will be used.  Will Service registrations only be in the registry when the Service is actually deployed (as is the case in ESB4, which is a bit of a cocked up approach IMO).  If service registrations were separate from the lifecycle of a service deployment then we could obviously query the registry and get the service contract details (java interface for now) and create injectable client/proxy beans for invoking those services, without requiring access to the implementations (as is currently the case with how I've done it).

        • 1. Re: CDI - @Service annotation
          Keith Babo Master

          Crap.  I branched your reply in hopes that I could split the topics across multiple threads.  Guess I'm going to have to do it the old fashioned way.  In this thread, I want to chat a bit more about the annotation(s) we will be using, possible configuration, etc.


          In your prototype work, there are three distinct cases where annnotations are used with CDI integration:

          • To declare that a bean is providing a service that is invokable via the SwitchYard bus
          • To declare that an interface is available as a service on the SwitchYard bus
          • To inject a reference to a service into a bean


          The first case is straightforward and makes perfect sense to me.  The second two have some overlap, if I understand things correctly.  The purpose of annotating the interface as a SwitchYard service is so that our extension logic can recognize that an invocation on the interface needs to be proxied.  But we are also annotating with injection itself (with @Remote or @ESBService), which could serve the same purpose.  If I got that right, then I would prefer it if the service interface did not have to be annotated at all and the injection point could specify that that the invocation should be proxied.  If the interface must be annotated (e.g. for CDI bookkeeping purposes), then I'm not sure why we need to annotate the injection with additional info as well.


          I'm fine with holding off on introducing separate annotations for consuming a service vs. providing a service, but I'm pretty darn sure that this is going to be necessary.  We can explore this more in the CDI use cases discussion that I'm about to start. :-)


          BTW, let's go with @Service instead of @ESBService.  We may hit a headwind with @Service being used across other projects, but I would prefer to start there.

          • 2. Re: CDI - @Service annotation
            Tom Fennelly Master

            We're not yet annotating the injection points with any marker annotations (#3 above).  But when we do, yeah... we can turn the injection process around and drive it from the injection points Vs the Service definition (as it is now).  This also makes sense because it will allow us to inject a service consumer proxy based on multiple interfaces, if we wanted to.  So a single ESB Service could have multiple contracts/views.