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

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
    ACCEPTED ANSWER

    Re: implementation.osgiapp and interfaces

    ‏2011-07-13T14:52:25Z  in response to izhd
    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
      ACCEPTED ANSWER

      Re: implementation.osgiapp and interfaces

      ‏2011-07-13T15:27:45Z  in response to SystemAdmin
      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
        ACCEPTED ANSWER

        Re: implementation.osgiapp and interfaces

        ‏2011-07-13T15:52:38Z  in response to izhd
        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
          ACCEPTED ANSWER

          Re: implementation.osgiapp and interfaces

          ‏2011-07-13T17:20:25Z  in response to SystemAdmin
          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
            ACCEPTED ANSWER

            Re: implementation.osgiapp and interfaces

            ‏2011-07-13T18:29:12Z  in response to izhd
            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
              ACCEPTED ANSWER

              Re: implementation.osgiapp and interfaces

              ‏2011-07-13T20:11:45Z  in response to SystemAdmin
              Awesome, thank you for clarification
              • Graham_Charters
                Graham_Charters
                2 Posts
                ACCEPTED ANSWER

                Re: implementation.osgiapp and interfaces

                ‏2011-07-14T08:06:06Z  in response to izhd
                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
                  ACCEPTED ANSWER

                  Re: implementation.osgiapp and interfaces

                  ‏2011-07-14T17:02:13Z  in response to Graham_Charters
                  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
                    ACCEPTED ANSWER

                    Re: implementation.osgiapp and interfaces

                    ‏2011-08-04T20:48:35Z  in response to izhd
                    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
                      ACCEPTED ANSWER

                      Re: implementation.osgiapp and interfaces

                      ‏2011-08-08T17:01:09Z  in response to SystemAdmin
                      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
                        ACCEPTED ANSWER

                        Re: implementation.osgiapp and interfaces

                        ‏2011-08-09T16:40:02Z  in response to izhd
                        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
                          ACCEPTED ANSWER

                          Re: implementation.osgiapp and interfaces

                          ‏2011-08-09T18:30:56Z  in response to SystemAdmin
                          Hi Victor,

                          Thank you for your help.

                          Regards,
                          Igor