-
1. Re: Redundancy in Framework
kcbabo Aug 5, 2013 7:29 AM (in response to tonyeverett)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 Aug 11, 2013 10:57 PM (in response to kcbabo)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 Aug 19, 2013 12:09 PM (in response to tadayosi)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.