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

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....

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.

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.

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.

That sounds like a reasonable approach to me.