7 Replies Latest reply on Jul 1, 2011 1:19 AM by Jiri Pechanec

    BPM Component - need to define empty implementation class

    Jiri Pechanec Apprentice

      Hi,

       

      I looked at the demo workflow of new BPM component (just the code, I have not a chance to run it yet).

       

      I'd like to ask about HelpDeskServiceProcess class. I understand the reasoning behind separating service interface and implementation. But at the same time I can imagine that there will be many cases when there will be one interface per process. Would not it be user friendly to allow a shortcut to allow using @BPM annotation on a method of interface that will execute the associated process?

       

      It would also allow to define multiple operations, each associated with different process.

       

      J.

        • 1. Re: BPM Component - need to define empty implementation class
          Keith Babo Master

          The @BPM annotation is not required.  It's a convenience mechanism available to allow developers to configure the BPM details through a Java annotation.  At build-time, a scanner picks up that annotation and generates the SwitchYard config.  We will be introducing a forge command which generates the config for you.

           

          If you think this might have issues with scaling to multiple processes, could you take a stab at a sample app which demonstrates the problem?  That would be very helpful (just like your last thread with a sample app).

           

          cheers,

          keith

          • 2. Re: BPM Component - need to define empty implementation class
            David Ward Master

            FYI, there doesn't have to be an implementing class.  In fact, if you didn't care about having a BPM-free service interface, you can put the @BPM annotation directly on the interface.  The scanner can handle that.

             

            Aside, you make me think that it would be pretty nice to be able to do something like this:

             

            @Process
            public interface MyService {
            
                @StartProcess
                public Response kickThingsOff(Request req);
            
                @SignalEvent(eventName="foo", eventType="bar")
                public void addInfo(Info event);
            
                @AbortProcess
                public void iGiveUp();
            
            }
            

             

            PS: I've gone back and forth on calling the annotation @BPM vs. @Process.  The more I think about it, I really like the above....

            • 3. Re: BPM Component - need to define empty implementation class
              David Ward Master

              I'm even liking these annotations more now... 'Cause with them, we wouldn't need to have the ProcessActionType (START_PROCESS, SIGNAL_EVENT, ABORT_PROCESS) in the Exchange Context (and upstream from that, in the SOAP Headers). Just by the particular interface method being invoked, we know what should happen to the process.  This is good. Very good.

              • 4. Re: BPM Component - need to define empty implementation class
                Keith Babo Master

                Insofar as the interface annotation establishes a mapping between an interface operation and a process behavior (start, signal, abort), I think it's a convenient feature.  But this is a detail that is relevant only to the BPM implementation and, in IMHO, really shouldn't be exposed on the interface that's registered for the service.  Take the following example:

                 

                app1 - BPM process with a service interface annotated with @Process, @StartProcess, etc.

                app2 - CDI bean service which consumes the service in app1

                 

                When app2 is written, it will import the Java interface exposed in app1.  To compile, the application will have to include a dependency on BPM annotations, which exposes implementation details in the service interface.

                 

                I think this situation is handled by the approach you took with extending the public service interface with another, BPM-specific interface which includes the annotations.  This shields external consumers from implementation details while preserving the convenience of specifying these mappings via annotation.  Now, this may be exactly what you were describing above, so I apologize if I'm restating things.  Just want to make sure that it was clear to other folks reading this thread.

                • 5. Re: BPM Component - need to define empty implementation class
                  David Ward Master

                  What if we don't enforce, but allow? To be specific, the developer is free to put the @Process, etc. annotations on the service interface, but by doing so they are introducing their own dependency. If they don't want to do it, they follow the Best Practice of putting the annotations on a sub-interface (or class) of the service interface.

                  • 6. Re: BPM Component - need to define empty implementation class
                    Keith Babo Master

                    That sounds like a reasonable approach to me.

                    • 7. Re: BPM Component - need to define empty implementation class
                      Jiri Pechanec Apprentice

                      David, this is exactly what I had in my mind, thanks.