Topic
  • 12 replies
  • Latest Post - ‏2011-08-09T18:30:56Z by izhd
izhd
izhd
27 Posts

Pinned topic implementation.osgiapp and interfaces

‏2011-07-12T21:22:14Z |
I have created OSGi application that has a bunch of interfaces.
Four of them are exported to be used as services in SCA.
Now if in SCA application I don't have actual copies of those interfaces(and their dependencies) in src folder with @Remotable annotation, application deploys w/o errors but any call to the SCA service returns NullPointerException (however no records in SystemOut)
If interfaces are copied to src of SCA application and @Remotable annotations added - everything works fine
The sample provided with RAD for OSGi & SCA has copies of interfaces, and I believe tutorial call for the same. However, here http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.soafep.multiplatform.doc/info/ae/htmlnav_fepnew.html it says following

When an OSGi application is used as an SCA component, its service and reference interfaces are automatically treated as remotable. The @Remotable annotation is not required. However, if you want to use the same Java source interface in other contexts, it might need to contain the @Remotable annotation:

If you copy the interface to the SCA asset and specify it in an interface.java element for an implementation.osgiapp service or reference, the interface must contain the @Remotable annotation. Otherwise, an interface incompatibility error occurs.
If you wire implementation.java and implementation.osgiapp components to each other, the interface must contain the @Remotable annotation. Otherwise, the implementation.java component considers the interface to be local and an interface incompatibility error occurs.

Do I have a problem with configuration or that's how it is implemented right now?

I'm using RAD 8.0.2 and WAS 7.0.0.11 test environment, plan to upgrade to RAD 8.0.3 and WAS 7.0.15
Updated on 2011-08-09T18:30:56Z at 2011-08-09T18:30:56Z by izhd
  • SystemAdmin
    SystemAdmin
    126 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-13T14:52:25Z  
    Hi izhd.

    You are right about the assumption that @Remotable annotation is not necessary, but this is only true if you are using those interfaces inside the OSGi component/application.

    If you want to use those interfaces to offer a service in the SCA component which is implementing the OSGi app to other SCA artifacts, then you need to copy the source file into src and add the @Remotable annotation. This is documented in this link:
    http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.jpafep.multiplatform.doc/info/ae/ae/csca_osgi_overview.html#csca_osgi_overview__annot

    Check the Annotations section.
    "Software development has been, is, and will remain fundamentally hard"
    - Grady Booch
  • izhd
    izhd
    27 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-13T15:27:45Z  
    Hi izhd.

    You are right about the assumption that @Remotable annotation is not necessary, but this is only true if you are using those interfaces inside the OSGi component/application.

    If you want to use those interfaces to offer a service in the SCA component which is implementing the OSGi app to other SCA artifacts, then you need to copy the source file into src and add the @Remotable annotation. This is documented in this link:
    http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.jpafep.multiplatform.doc/info/ae/ae/csca_osgi_overview.html#csca_osgi_overview__annot

    Check the Annotations section.
    "Software development has been, is, and will remain fundamentally hard"
    - Grady Booch
    Hi VictorSosa,

    Thank you for the reply. I actually quoted text from the link you referred in my original post.
    It says "When an OSGi application is used as an SCA component, its service and reference interfaces are automatically treated as remotable. The @Remotable annotation is not required. However, if you want to use the same Java source interface in other contexts, it might need to contain the @Remotable annotation:" So i read it as if I use OSGi app as SCA component, @Remotable is not needed.
  • SystemAdmin
    SystemAdmin
    126 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-13T15:52:38Z  
    • izhd
    • ‏2011-07-13T15:27:45Z
    Hi VictorSosa,

    Thank you for the reply. I actually quoted text from the link you referred in my original post.
    It says "When an OSGi application is used as an SCA component, its service and reference interfaces are automatically treated as remotable. The @Remotable annotation is not required. However, if you want to use the same Java source interface in other contexts, it might need to contain the @Remotable annotation:" So i read it as if I use OSGi app as SCA component, @Remotable is not needed.
    Hi izhd,

    It seems that it is the RAD SCA tools function which requires you to include the @Remotable annotation on the interface.

    So while the bottom-line is to follow Victor's instructions, I can explain the reason in a bit more detail.

    To start, note that the WAS SCA FeP InfoCenter does not assume the use of RAD SCA Tools to develop SCA FeP applications.

    From the WAS SCA perspective, a service interface may either be declared explicitly through an <interface.java> element in the composite file, or implicitly. In the implicit case, no <interface.java> or <interface.wsdl> element appears in the composite file and the interface is introspected from the implementation, in this case from the OSGi application.

    As mentioned further down in the article you referenced, the presence of an explicit <interface.java> means that the interface must be packaged within your SCA Asset (JAR).

    <excerpt>

    Interface definition

    It is not required to specify an interface element on a component service or component reference. You can specify an interface to enforce a given contract with the implementation...If you specify an interface.java or interface.wsdl element, it must refer to a Java class or WSDL file that is packaged in the SCA asset, or that is imported from a shared asset.

    </excerpt>

    And, as you noted in quoting from the Annotations section of the article, it must also then have a @Remotable annotation (or @WebService, a synonym in this case).

    So it is not simply the fact that the OSGi application is exposed as an SCA service which requires the @Remotable interface, but the fact that it is specified explicitly with <interface.java>, using the RAD tooling.

    I hope that explanation helps.

    Regards,
    Scott Kurz
    WAS SCA FeP Development
  • izhd
    izhd
    27 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-13T17:20:25Z  
    Hi izhd,

    It seems that it is the RAD SCA tools function which requires you to include the @Remotable annotation on the interface.

    So while the bottom-line is to follow Victor's instructions, I can explain the reason in a bit more detail.

    To start, note that the WAS SCA FeP InfoCenter does not assume the use of RAD SCA Tools to develop SCA FeP applications.

    From the WAS SCA perspective, a service interface may either be declared explicitly through an <interface.java> element in the composite file, or implicitly. In the implicit case, no <interface.java> or <interface.wsdl> element appears in the composite file and the interface is introspected from the implementation, in this case from the OSGi application.

    As mentioned further down in the article you referenced, the presence of an explicit <interface.java> means that the interface must be packaged within your SCA Asset (JAR).

    <excerpt>

    Interface definition

    It is not required to specify an interface element on a component service or component reference. You can specify an interface to enforce a given contract with the implementation...If you specify an interface.java or interface.wsdl element, it must refer to a Java class or WSDL file that is packaged in the SCA asset, or that is imported from a shared asset.

    </excerpt>

    And, as you noted in quoting from the Annotations section of the article, it must also then have a @Remotable annotation (or @WebService, a synonym in this case).

    So it is not simply the fact that the OSGi application is exposed as an SCA service which requires the @Remotable interface, but the fact that it is specified explicitly with <interface.java>, using the RAD tooling.

    I hope that explanation helps.

    Regards,
    Scott Kurz
    WAS SCA FeP Development
    Thank you Scott, I guess that explains it.
    I felt like <interface.java> is not right for OSGi implementation.
    So if I have component with <implementation.osgiapp>, I don't need to define <interface.java> (leaving aside RAD tooling)? But how would I define bindings in that case?
    Currently I have
    <ns1:implementation.osgiapp applicationSymbolicName="App" applicationVersion="1.0.0"/>
    <service name="DocumentServiceExt">
    <interface.java interface="com.document.api.DocumentService"/>
    <tuscany:binding.http>
    <tuscany:wireFormat.jsonrpc/>
    </tuscany:binding.http>
    </service>
    ...

    How would binding be matched with right interface exposed by OSGi application if there's no <interface> element?
  • SystemAdmin
    SystemAdmin
    126 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-13T18:29:12Z  
    • izhd
    • ‏2011-07-13T17:20:25Z
    Thank you Scott, I guess that explains it.
    I felt like <interface.java> is not right for OSGi implementation.
    So if I have component with <implementation.osgiapp>, I don't need to define <interface.java> (leaving aside RAD tooling)? But how would I define bindings in that case?
    Currently I have
    <ns1:implementation.osgiapp applicationSymbolicName="App" applicationVersion="1.0.0"/>
    <service name="DocumentServiceExt">
    <interface.java interface="com.document.api.DocumentService"/>
    <tuscany:binding.http>
    <tuscany:wireFormat.jsonrpc/>
    </tuscany:binding.http>
    </service>
    ...

    How would binding be matched with right interface exposed by OSGi application if there's no <interface> element?
    Hi izhd,

    The service is uniquely identified by the @name attribute of <service>, so you can go ahead and configure bindings without specifying the interface.

    As this article explains, when an OSGi application is used as an SCA component impl, the service @name value ends up corresponding to the blueprint bean's service @id value.

    Note the Java interface must also be exported using "Application-ExportService" within the
    META-INF/APPLICATION.MF file.

    So you can use something like simply:
    
    ...   <ns1:implementation.osgiapp applicationSymbolicName=
    "App" applicationVersion=
    "1.0.0"/> <service name=
    "DocumentServiceExt"> <tuscany:binding.http> <tuscany:wireFormat.jsonrpc/> </tuscany:binding.http> </service> ...
    

    It is a bit tricky to have the SCDL variation have this packaging consequence, so hopefully this helps explain things better.

    Regards,
    Scott
  • izhd
    izhd
    27 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-13T20:11:45Z  
    Hi izhd,

    The service is uniquely identified by the @name attribute of <service>, so you can go ahead and configure bindings without specifying the interface.

    As this article explains, when an OSGi application is used as an SCA component impl, the service @name value ends up corresponding to the blueprint bean's service @id value.

    Note the Java interface must also be exported using "Application-ExportService" within the
    META-INF/APPLICATION.MF file.

    So you can use something like simply:
    <pre class="jive-pre"> ... <ns1:implementation.osgiapp applicationSymbolicName= "App" applicationVersion= "1.0.0"/> <service name= "DocumentServiceExt"> <tuscany:binding.http> <tuscany:wireFormat.jsonrpc/> </tuscany:binding.http> </service> ... </pre>
    It is a bit tricky to have the SCDL variation have this packaging consequence, so hopefully this helps explain things better.

    Regards,
    Scott
    Awesome, thank you for clarification
  • Graham_Charters
    Graham_Charters
    2 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-14T08:06:06Z  
    • izhd
    • ‏2011-07-13T20:11:45Z
    Awesome, thank you for clarification
    My apologies for this very late comment - I've only just seen this thread. I just wanted to add a bit more background as to why implementation.osgiapp is how it is...

    Annotations are not commonly used in OSGi, which is why @Remotable is not used. Instead, we use the OSGi Remote Services (from the Enterprise 4.2 specification) equivalent, which is to add the service.exported.interfaces property to the OSGi service registration. We consider any interfaces identified by that property to be "remotable". So the doc statement [1], is actually misleading. Only services that are registered with service.exported.interfaces are treated as remotable, and only OSGi service references that look for the service.imported property (also from the Remote Services spec) will be able to find services provided by SCA.

    Regarding RAD and interface.java for components with implementation.osgiapp, IMO the best practice is to not include interface.java and I have suggested RAD not generate them when doing "Refresh from Implementation".

    I hope this helps.

    Regards, Graham

    [1] "When an OSGi application is used as an SCA component, its service and reference interfaces are automatically treated as remotable. The @Remotable annotation is not required. However, if you want to use the same Java source interface in other contexts, it might need to contain the @Remotable annotation:"
  • izhd
    izhd
    27 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-07-14T17:02:13Z  
    My apologies for this very late comment - I've only just seen this thread. I just wanted to add a bit more background as to why implementation.osgiapp is how it is...

    Annotations are not commonly used in OSGi, which is why @Remotable is not used. Instead, we use the OSGi Remote Services (from the Enterprise 4.2 specification) equivalent, which is to add the service.exported.interfaces property to the OSGi service registration. We consider any interfaces identified by that property to be "remotable". So the doc statement [1], is actually misleading. Only services that are registered with service.exported.interfaces are treated as remotable, and only OSGi service references that look for the service.imported property (also from the Remote Services spec) will be able to find services provided by SCA.

    Regarding RAD and interface.java for components with implementation.osgiapp, IMO the best practice is to not include interface.java and I have suggested RAD not generate them when doing "Refresh from Implementation".

    I hope this helps.

    Regards, Graham

    [1] "When an OSGi application is used as an SCA component, its service and reference interfaces are automatically treated as remotable. The @Remotable annotation is not required. However, if you want to use the same Java source interface in other contexts, it might need to contain the @Remotable annotation:"
    Thank you, Graham.

    I found out about service.exported.interfaces property from some tutorial or RAD sample(?)
    I guess there're some gaps in RAD tools. One of them is related to interfaces, another, as you mentioned, when refreshing from implementation it will get all services, confirming to interfaces exported in OSGi application, regardless of service.exported.interfaces property (in one of the tutorials it was stated that OSGi bundle should have different services for SCA and for internal OSGi usage). Apparently if I call those services w/o service.exported.interfaces call will just fail.

    Regards,
    Igor
  • SystemAdmin
    SystemAdmin
    126 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-08-04T20:48:35Z  
    • izhd
    • ‏2011-07-14T17:02:13Z
    Thank you, Graham.

    I found out about service.exported.interfaces property from some tutorial or RAD sample(?)
    I guess there're some gaps in RAD tools. One of them is related to interfaces, another, as you mentioned, when refreshing from implementation it will get all services, confirming to interfaces exported in OSGi application, regardless of service.exported.interfaces property (in one of the tutorials it was stated that OSGi bundle should have different services for SCA and for internal OSGi usage). Apparently if I call those services w/o service.exported.interfaces call will just fail.

    Regards,
    Igor
    Hi.

    Something worth to mention. I tried the scenario where having an OSGi app with two services (both listed with the Application-ExportService header in Application.MF file) but only one of them is actually being exported using "service.exported.interfaces" entry. On the SCA side, I refreshed the component implementation to get the actual exported services and The Refresh From Implementation action is actually reflecting ONLY the services that are exported in the blueprint.xml file (service.exported.interfaces) and have a corresponding service exported in the Application.MF file (Application-ExportService).
    Would you mind to develop a bit more how is your Refresh from implementation scenario?
    "Software development has been, is, and will remain fundamentally hard"
    - Grady Booch
  • izhd
    izhd
    27 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-08-08T17:01:09Z  
    Hi.

    Something worth to mention. I tried the scenario where having an OSGi app with two services (both listed with the Application-ExportService header in Application.MF file) but only one of them is actually being exported using "service.exported.interfaces" entry. On the SCA side, I refreshed the component implementation to get the actual exported services and The Refresh From Implementation action is actually reflecting ONLY the services that are exported in the blueprint.xml file (service.exported.interfaces) and have a corresponding service exported in the Application.MF file (Application-ExportService).
    Would you mind to develop a bit more how is your Refresh from implementation scenario?
    "Software development has been, is, and will remain fundamentally hard"
    - Grady Booch
    Hi Victor,

    I have 2 services defined in blueprint.xml that implement the same interface. one of them has "service.exported.interfaces" property, other doesn't. Since it's the same interface, Application.mf has one entry. When I "refresh from the implementation", I can see both services in the dialog.

    <service ref="SecurityServiceImplBean" id="SecurityService" interface="com.security.api.SecurityService">

    </service>
    <service ref="SecurityServiceImplBean" id="SecurityServiceExt" interface="com.security.api.SecurityService">
    <service-properties>
    <entry key="service.exported.interfaces" value="com.security.api.SecurityService"></entry>
    </service-properties>

    </service>
    Regards,
    Igor
  • SystemAdmin
    SystemAdmin
    126 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-08-09T16:40:02Z  
    • izhd
    • ‏2011-08-08T17:01:09Z
    Hi Victor,

    I have 2 services defined in blueprint.xml that implement the same interface. one of them has "service.exported.interfaces" property, other doesn't. Since it's the same interface, Application.mf has one entry. When I "refresh from the implementation", I can see both services in the dialog.

    <service ref="SecurityServiceImplBean" id="SecurityService" interface="com.security.api.SecurityService">

    </service>
    <service ref="SecurityServiceImplBean" id="SecurityServiceExt" interface="com.security.api.SecurityService">
    <service-properties>
    <entry key="service.exported.interfaces" value="com.security.api.SecurityService"></entry>
    </service-properties>

    </service>
    Regards,
    Igor
    Hi Igor.

    I've reproduced the problem you see. Yes, this is an error, because in the OSGi context, you are exporting only one service, the other service is consumable only within OSGi. I've notified the RAD team about this.

    Thanks for using the tools and reporting the problems to IBM!

    "Software development has been, is, and will remain fundamentally hard"
    - Grady Booch
  • izhd
    izhd
    27 Posts

    Re: implementation.osgiapp and interfaces

    ‏2011-08-09T18:30:56Z  
    Hi Igor.

    I've reproduced the problem you see. Yes, this is an error, because in the OSGi context, you are exporting only one service, the other service is consumable only within OSGi. I've notified the RAD team about this.

    Thanks for using the tools and reporting the problems to IBM!

    "Software development has been, is, and will remain fundamentally hard"
    - Grady Booch
    Hi Victor,

    Thank you for your help.

    Regards,
    Igor