Re: [sca-j] ISSUE 95: Scenarios for SCA conversations

["Meeraj Kunnumpurath" <mkunnumpurath@googlemail.com>]

Simon,

 

These are some use cases from applications we have been working on, these are fine grained tightly coupled conversations.

 

1. DAO used to write a large dataset to the database

 

@Conversation

public interface PaymentDao {

 

    void writePayment(PaymentInfo paymentInfo);

    void flush();

    @EndsConversation void close();

 

}

 

@Scope("CONVERSATION")

public class PaymentDaoImpl implements PaymentDao {

 

    @PersistenceContext(unitName = "paymentStore") protected EntityManager entityManager;

 

    public void writePayment(PaymentInfo paymentInfo) {

        entityManager.persist(paymentInfo);

    }

 

    public void flush() {

        entityManager.flush();

    }

 

    public void close() {

        entityManager.close();

    }

 

}

 

There is nothing in PaymentInfo, from a business context, to identify it to be in a specific batch of payments coming in. We get payments in the order of a million within one stream, the component that receives the payments calls the DAO to persist payment, however, it may periodically flush to decrease resource usage in the session cache. So the caller needs to get the same instance of the DAO, every time it persists a payment or flush the cache within the context of processing a given batch of payments. We rely on the container to provide instance management implictly.

 

We have run into a number of similar scenarios across multiple projects. Another example is in CEP, where you may be receiving a series of related/unrelated events, on which you may want to do some kind of processing based on analysis/aggregation etc. The events themselves may not have a common business context to link them.

 

I understand, above scenarios may be addressed using a UUID in the parameter list and getting the client to pass it explicitly. However, it may not be ideal as it corrupts the service contract. 

 

IMHO, I think there is plenty of scope for both implicit and explicit correlation, based on granularity and asynchrony of conversations. I see parameter based explicit correlations more prevalent with coarse-grained interactions primarily on the edge of the domain, whereas implicit container managed conversations quite heavily used with fine grained interactions within the domain.

 

Thanks

Meeraj   

 

 

 

 

On Fri, Jan 9, 2009 at 1:30 PM, Simon Nash <oasis@cjnash.com> wrote:

On Monday's call I took an action item to find scenarios that
have previously been put forward for SCA conversations so that
we could use these to compare and contrast the proposals from
Jim and myself.

As I suspected, most of the scenarios that we have discussed were
created to illustrate callbacks rather than conversations.  However,
these often involve stateful interactions, so they might be relevant.

I have been though all the examples I could find and they are
all variations on the shopping cart / order entry theme.  The
following interface is a synthesis of various different examples.

public interface Order {

   String create();
       // returns an orderID for use in subsequent calls
       // could pass some information, such as customer info
       // for implicit correlation, this method might not be needed

   void add(String orderID, String itemID, int quantity);
       // the orderID might be explicit as shown here, or implicit

   void remove(String orderID, String itemID, int quantity)
           throws ItemNotFoundException;
       // throws exception if specified number of items not in the order
       // the orderID might be explicit as shown here, or implicit

   void submit(String orderID) throws EmptyCartException;
       // throws exception if cart is empty
       // the orderID might be explicit as shown here, or implicit
}

Can anyone suggest additional scenarios where SCA conversations
would be used?  Jim has mentioned that he has some.

 Simon



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php