3 Replies Latest reply on Aug 19, 2013 12:09 PM by kcbabo

    Redundancy in Framework

    tonyeverett

      I was wondering if someone could help me understand what on the surface at least appears to be a lot of redundancy:

       

      First there is this:

      @Service(MyService.class)

      public class MyServiceBean implements MyService {

       

      Then this:

      <bean:implementation.bean class="MyServiceBean" />

      <sca:service name="MyService">

      <sca:interface.java interface="MyService" />

       

      Say I have a service. I have to annotate it with @Service so that it can be found for the Switchyard context. That I understand and is no worse than @Stateless. But I am forced to create and implement an interface even when there is only one implementation. Why is that? And then I am forced to repeat myself in the annotion even though the Java class signature tells the world what I am implementing. Why is that? And then I end up repeating myself again in the switchyard.xml telling the world what is my implementation and what is my service name and what is my interface.

       

      Am I the only one who looks at that and says, "ugh"? Convention over configuration is nice if you can get it. Can we get it? Or am I missing something and is all of this a good thing?

       

      Thanks for any clarification.

        • 1. Re: Redundancy in Framework
          kcbabo

          But I am forced to create and implement an interface even when there is only one implementation. Why is that?

           

          All interactions in SwitchYard are based on contract, not implementation.  The chief benefit here is implementation hiding - consumers of your service do not have to know that your implementation is a Java bean, they can just interact based on the contract.  This also gives the service provider flexibility to change the implementation.  It could be Java bean today and BPM (or Drools, or BPEL, or Camel, ...) tomorrow - the consumer doesn't have to change at all.  Finally, the separate contract definition is picked up by our admin and governance tooling to provide nifty design-time governance integration.

           

          And then I am forced to repeat myself in the annotion even though the Java class signature tells the world what I am implementing. Why is that?

           

          Java beans can implement many interfaces (e.g. java.io.Serializable) and we need to know which one is the service contract.

           

          And then I end up repeating myself again in the switchyard.xml telling the world what is my implementation and what is my service name and what is my interface.

           

          You shouldn't have to hack on XML at all.  If you are using our tooling, all of the switchyard.xml is created for you.  If you're not using the tooling, then you can use a scanner (similar to this) in your pom configuration to generate the XML off of the annotated bean.

           

          Am I the only one who looks at that and says, "ugh"? Convention over configuration is nice if you can get it. Can we get it? Or am I missing something and is all of this a good thing?

           

          All services should have a contract.  A tremendous amount of what we do in SwitchYard and in governance depends on this best practice.  With that said, every Java bean doesn't have to be a service.  If you are just wiring together bits of Java-based logic and you don't feel the need to componentize each bean's logic as a service, then you can just use CDI beans and call them directly from a Camel routing service in SwitchYard.

          • 2. Re: Redundancy in Framework
            tadayosi

            Hello,

             

            I believe if this feature request https://issues.jboss.org/browse/SWITCHYARD-1190 is implemented, one of the redundancies Tony sees would be resolved.

             

            Keith, is there any reason this JIRA won't be dealt with soon?  Personally, I like this feature request too.

             

            Thanks.

            • 3. Re: Redundancy in Framework
              kcbabo

              This is certainly something we can look at, but it's not going to make it for 1.1.  Contributions are welcome. :-) 

               

              Aside from grabbing the interface from the class definition, the fix would also need to include additional validation checks. For example, requiring the interface to be specified when a class implements multiple interfaces.