Unknown Service name

[magick93]

Hi

I have what should be a very simple usecase:

A request is routed to one of two bean services. Both services use the same interface, but different implementations.

However, SY can only find one of the services - and continues to say the BService is 'unknown'. Both the Service name and Component name are 'BService' This is the same pattern in the BrokerSelectorService.

Can anyone tell me what the problem is?

Thanks

[rcernich]

Hey Anton,

I think the issue is with the @Service annotation on BService.  I think you need to specify the name "BService" explicitly, e.g. @Service(value=BrokerSelectorService.class, name="BService").  I think that should fix you up.

Hope that helps,

Rob

[jorgemoralespou_2]

Hi,

I haven't looked at the attachment as I'm on my phone, but my guess is that your services, as both have the same interface needs the name value in the @Service annotation, to distinguish between both implementations.

[magick93]

Jorge Morales wrote:

Hi,

I haven't looked at the attachment as I'm on my phone, but my guess is that your services, as both have the same interface needs the name value in the @Service annotation, to distinguish between both implementations.

Hi Jorge

I would expect, having set the interface and implementation in the switchyard.xml - that this would be enough to bind the interface and implementation.

Bob

Thanks - this did work - but, as mentioned above - why is this needed after I have already specified in the xml. Also, your solution isnt really type safe. And type satefy is one of the more innovative improvements that CDI brings - this seems like a bit of a step backwards. Also, it means - as I found out - refactoring  is a manual process.

So, if specifying the contract and the implementation specified in the xml, like so:

<sca:component name="BService">

      <bean:implementation.bean class="broker.selector.BService"/>

      <sca:service name="BService">

        <sca:interface.java interface="broker.selector.BrokerSelectorService"/>

      </sca:service>

    </sca:component>

Does not actually tell Switchyard what the implementation for the contract is - then why is this needed? Do we even need the xml?

[rcernich]

Hey Anton,

Unfortunately, the issue here is that the CDI integration relies on the annotation, while the SwitchYard deployment itself is configured using the file.  Given that, there is an obvious disconnect between the two and that's probably an area that should be improved (i.e. the CDI integration should rely on the switchyard.xml too).

That said, the default hame attached to the service is the simple name for the service interface type (e.g. BrokerSelectorService), so in your case, you had two services with the same name, at least as far as the CDI integration was concerned.

switchyard.xml is needed to configure items which can't be configured using annotations (e.g. application namespace).  There are scanners which can be configured on the switchyard-plugin, which will populate portions of the switchyard.xml during the build process (e.g. the transformer scanner).  That said, it's a bit tricky getting the editor to display the generated components/services (i.e. your mileage may vary).  If you want, you can enable the bean scanner, but you may end up with multiple component definitions if you're creating components through editor.  (I don't think the editor populates the name or component name attributes on @Service and given the defaults used in the UI, you'll end up with two components: SomeServiceBean (created by the tooling) and SomeService (created by the scanner).  If you simply rely on the scanner, you shouldn't have any problem, but YMMV.)

Hope that helps clarify things a bit.

Sorry for the inconvenience.

Rob

[magick93]

Hi Rob

Thanks for responding on this.

I must say, I am still rather confused. I have read a lot about switchyard, and watched all the videos that Keith has put together - and the general idea seems to be that the switchyard.xml is the glue that brings all the elements together, and its also - with the help of the SY editor - makes rapid application development possible.

Rob Cernich wrote:

... in your case, you had two services with the same name, at least as far as the CDI integration was concerned.

So, when I use the SY editor, and double, triple and quadruple check that yes, I do have different names for the services - because I can see, and edit in the UI in the box that says Service Name - and I can confirm that in the xml. And now I learn that that name is not important.

You say the xml is needed for deployment and setting the application namespace. If that is the case - why make it a key feature in the UI editor? Why even provide ways to set and change Service Names in the UI if this name is not acknowledged?

Question - is it possible to write a SY application, and not need the SY xml, or just have a bare minimum xml file? Now I dont feel I can trust the UI or the xml

Please have a read of how the homepage for Switchyard describes itself:

SwitchYard is a component-based development framework focused on building structured, maintainable services and applications using the concepts and best practices of SOA. It works with Apache Camel to provide a fast, simple, flexible integration runtime with comprehensive connectivity and transports. A uniform application model augments Apache Camel, joining Java EE, BPM, rules, orchestration, and routing into a cohesive development model and runtime. Common functionality and cross-cutting concerns - validation, transformation and policy - are isolated from business logic and handled declaratively. This ensures consistency and eliminates duplication, offering developers a clear view of the structure and relationships of services in an integration application.

As we have seen, services are not maintainable - manual refactor is need.

The model is not uniform - there is a disconnect between the SY approach and CDI.

There is inconsistency between what is named in the SY xml, and what SY thinks is a service name. And this results in duplication. There are at least 3 places I have to name a service - in the class, the component, and the service (now I'm not sure what a service is??).

Apologies for having such rant on a Friday night - but I and my team have invested heavily in this technology.

I was under the impression that the SY.xml was akin to the blueprint xml, or the spring xml. Now, Im not so clear on it.

[rcernich]

Anton Hughes wrote:

Rob Cernich wrote:

... in your case, you had two services with the same name, at least as far as the CDI integration was concerned.

So, when I use the SY editor, and double, triple and quadruple check that yes, I do have different names for the services - because I can see, and edit in the UI in the box that says Service Name - and I can confirm that in the xml. And now I learn that that name is not important.

The name is important.  In this case the name in the xml did not match the name in the @Service annotation.  I think the tooling will highlight this as an error.  There is certainly room for improvement, especially where refactoring is concerned.  Please feel free to open a JIRA for this issue.

Anton Hughes wrote:

Question - is it possible to write a SY application, and not need the SY xml, or just have a bare minimum xml file? Now I dont feel I can trust the UI or the xml

You need the switchyard.xml.  As I stated earlier, there is only a limited amount of configuration supported through annotations, and it is recommended not to use them in conjunction with the editor (synchronization issues between source and generated models).  The screenshot you provided shows that there were problems with the configuration.  If the error messages or problem descriptions did not allow you to easily identify the issues, then that is something that should be addressed in the tooling.  Feedback is welcome.

Anton Hughes wrote:

Apologies for having such rant on a Friday night - but I and my team have invested heavily in this technology.

No worries.  Sorry you wasted time on this.

[kcbabo]

One thing to recognize here is that SY brings together a lot of independent implementation technologies under a single application model.  We try to make it as smooth and uniform as we can, but you are always going to have to deal with the capabilities/restrictions/oddities of a given implementation technology.  CDI sets up wiring for injection points based on type.  We can't change that in SwitchYard.  What we can do is provide a way to affect that wiring by providing additional metadata (in the form of the 'name' annotation element) in the CDI bean which corresponds to configuration in switchyard.xml.  Yes, the name has to "sync up" between the two, and it would be nice if this only had to be specified once.  Recognizing this could be a problem, the editor provides built in validation to make sure that potential errors are caught early in the development process.  There's no need to double-check everything when the editor is validating the model and associated implementation artifacts for you.  It sounds like the main problem here is that we don't have adequate documentation on how to resolve validation errors that are reported by the tooling.  That's definitely something we can improve on.

[magick93]

Hi Keith

Yes, documentation would help.

I was also thinking - and tried to look into this over the weekend - if the Impl of the org.switchyard.component.bean.Service annotation could somehow read the SY.xml file.

[kcbabo]

Could be possible.  I haven't looked at this closely, but I suspect you might be able to wire this in ClientProxyBean from BeanComponentActivator.activateService.  Note that the ServiceReference is set here:

components/BeanComponentActivator.java at master · jboss-switchyard/components · GitHub