[EMAIL PROTECTED] wrote:
Hi Mats
Sorry for the delay getting to you, been a bit hectic lately...
I can understand why :) How many projects are you involved in at the
moment? :)
On 16 Aug 2005, at 15:36, Mats Norén wrote:
Either is possible. Though where possible its always good to reuse
components to avoid having too much cut and paste and plumbing code.
We're trying to put in place reusable base classes or full components
you can configure to do what you need.
In CVS HEAD we've a reusable BindingServlet together with implements
like HttpInOutBinding, HttpInOnlyBinding and a useful base class,
HttpBindingSupport.
Ok, I'll take a look at them.
If you could use either of those directly you could just use either
dependency injection or inheritance to switch in a different
HttpMarshaler to handle different ways of dealing with the S/MIME
encoding and deciding how to turn them into a NormalizedMessage and
back again. i.e. you could extend HttpMarshaler to decide how to
extract the body & attachments and what NormalizedMessage properties to
set and so forth.
To handle validation, you could put this into your HttpMarshaler or add
it in a pipeline using a ValidationComponent.
And when you say pipeline you mean the servicemix.xml where I configure
the JBI-container with components and services?
The part I'm a little confused by is "Based on a property in the header
of the first mime-part the request is either async. or sync.". Inside
a Servlet call, you can either perform an InOnly (one way) request into
JBI or you can perform an InOut, blocking until the result comes back,
then returning the answer to the HTTP client. In both cases the Servlet
is synchronous, as Servlets have to be. So when you said sync/async did
you mean InOnly v InOut right? i.e. fire and forget versus blocking
request response?
Exactly. I'm thinking about creating two different services, Sync and
Async and route the NMS to the appropriate service. In your opinion,
would it be best to just let the servlet create an InOut to a router
component that does the switch between sync and async based on the NMS?
I mean is it preferable to decouple the sync/async routing further from
the BindingServlet?
If I create an InOut in the Servlet and then decide to do async
processing I would have to create a new MEP using InOnly and copy the
received message, right?
I'd be tempted to keep things fairly granular; the overhead of extra
pipeline hops should be fairly minimal, they're fairly lightweight
things. If down the road we find some common areas that need
optimisation I'm sure we can come up with solutions on a case by case
basis; for now I think keeping things easy to reuse is a good thing.
Ok, the attachments in the messages can be > 100MB in worst case scenarios.
Thanks for the reply and keep up the good work!
/Mats
