Hi Mark,
I have been playing around with this for a while, and here are my findings
for further discussion.
It is possible to change the IConnection interface to use the following
generic types:
ISession CreateSession(System.Enum acknowledgementMode);
System.Enum AcknowledgementMode { get; set; }
This would allow for passing in a generic enumeration. However, I think
that it will force more code to be written using explicit casting in order
to deal with the AcknowledgementMode property in the most general cases.
Since using provider specific acknowledgment modes is the outlyer case, I
think using casting to show specific intent to deviate from standard modes
is preferred. The C# enum type system is robust enough to support the
following using the existing interface definition without reverting to
generic System.Enum:
interface IConnection // SNIPPET
{
ISession CreateSession(AcknowledgementMode acknowledgementMode);
AcknowledgementMode AcknowledgementMode { get; set; }
}
enum MyAckModes
{
IgnoreDups,
Transactional,
Explicit
}
IConnection connection = GetConnection();
// Set the default ack mode
connection.AcknowledgementMode = (AcknowledgementMode)
MyAckModes.IgnoreDups;
// Set session-specific ack mode
ISession session = connection.CreateSession((AcknowledgementMode)
MyAckModes.Explicit);
As can be seen from this snippet of code, the existing code base allows the
use of provider specific enumerations while providing type-safety and
non-casting for the general case. When a user of NMS wants to have
low-level access to a provider's unique acknowledgment modes, then they can
do so and the C# enum system will carry their values through, even if that
acknowledgment mode value is outside the range of the original
AcknowledgmentMode enumeration. I have created a sample C# app that
demonstrates basic casting of enumerations to show that provider specific
enumeration values can be "carried" inside the existing AcknowledgementMode
enumeration. Since these values only make sense to the individual
providers, they will be the ones who will cast when setting/getting the
AcknowledgementMode property.
using System;
public class EnumTest
{
enum MyEnum { First, Second, Third }
enum ProviderEnum { Fourth, Fifth }
static void ShowEnum(System.Enum baseEnum)
{
Console.WriteLine("base = {0}", baseEnum);
ProviderEnum derived = (ProviderEnum) baseEnum;
Console.WriteLine("derived = {0}", derived);
}
static void Main()
{
ShowEnum(MyEnum.Second);
ShowEnum(MyEnum.Third);
}
}
I hope that this addresses the concerns about using provider specific
extensions to the acknowledgment mode enumeration. Let me know if I didn't
explain anything clearly. I am interested in your comments on this
proposal.
- Jim
On Mon, Jun 9, 2008 at 12:27 PM, Mark Pollack <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Just a ping to see if we can get closure on an approach...
>
> Mark
>
>
> -----Original Message-----
> From: Mark Pollack [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2008 10:09 AM
> To: 'dev@activemq.apache.org'
> Subject: RE: NMS API design question regarding AckMode
>
> Hi,
>
> My suggestion is to have the base enumeration class, System.Enum, be used.
> I suspect that all .NET messaging providers have used enums for ack modes
> and if they didn't, the NMS implementation for that provider could supply
> one.
>
> In the case of the EMS binding, this would read
>
> connection.CreateSession(SessionMode.NoAcknowledge)
>
> This seems more natural than using a literal string. All the general
> arguments of enum vs. string apply here.
>
> I used this approach with System.Data.DbType, the base enum for data types
> in ADO.NET. All ADO.NET providers have their own custom enum (for
> 'advanced' data types like xml, arrays etc.) This has seemed to work out
> well, at least no complaints.
>
> Cheers,
> Mark
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Rob Davies [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2008 2:32 AM
> To: dev@activemq.apache.org
> Subject: Re: NMS API design question regarding AckMode
>
> +1 on Strings
>
> On 29 May 2008, at 05:47, Jim Gomes wrote:
>
> > Hi Mark,
> >
> > I like the idea of having providers extend the session modes to what
> > makes
> > sense for them. For instance, MSMQ may ignore transactional, but
> > have some
> > additional acknowledgment mode. However, what do you propose as a
> > solution
> > such that provider's individual extensions to the acknowledgment
> > mode do not
> > "pollute" the global API space? I like your suggestion of having a
> > loose
> > and flexible API, and I would think that an acknowledgement mode as a
> > string, versus an enumeration, would be the "loosest". But that may
> > not be
> > the best way to go.
> >
> > Changing to a string might work. The current enumeration could be
> > changed
> > to readonly strings. This way providers would be free to support
> > custom
> > acknowledgment modes through the single parameter. Thoughts?
> >
> > Regards,
> > Jim
> >
> > On Wed, May 28, 2008 at 7:24 PM, Mark Pollack
> <[EMAIL PROTECTED]
> > >
> > wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> I'm digging into the NMS API a bit more as I plan to release NMS
> >> support in
> >> Spring.NET in the coming months (which James had a hand in as well)
> >> and I
> >> have a question regarding the AcknowledgementMode enum. The
> >> current values
> >> are those in the JMS spec (DUPS_OK_ACKNOWLEDGE, AUTO_ACKNOWLEDGE,
> >> CLIENT_ACKNOWLEDGE) and an additional one Transactional.
> >>
> >>
> >>
> >> Vendors typically provide additional ack modes for increased
> >> performance,
> >> TIBCO EMS is the case I'm familiar with which also has
> >> ExplicitClientAcknowledge, ExplicitClientDupsOkAcknowledge, and
> >> NoAcknowledge.
> >>
> >>
> >>
> >> At the moment the NMS API can't support these modes, making it a
> >> lowest-common denominator solution, something I feel that must be
> >> avoided
> >> if
> >> it is to gain widespread use. I've had a similar experience
> >> writing a
> >> database wrapper class for ADO.NET and the use of vendor specific
> >> enums
> >> for
> >> data types. I ended up leaving the API very 'loose', i.e. method
> >> signature
> >> just has 'Enum' in it and internally implementations can check to
> >> see if it
> >> makes sense for them. This has worked out well as far as I can tell.
> >>
> >>
> >>
> >> Is it possible to follow the same approach in this case?
> >>
> >>
> >>
> >> Cheers
> >>
> >> Mark
> >>
> >>
> >>
> >>
>
>
>
