RE: Need advise on concept ???
- From: Patrick Simpe-Asante <PatrickSimpeAsante@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 10 Apr 2007 04:12:02 -0700
Hi Serge,
Apologies, didn't mean to confuse, I highlighted a specific solution for a
problem as an example of what can be done, rather than something should be
adopted as a concrete design to your problem :-)
For my case everything will work first on the same computer BUT I wold likeThere are many options for achieving what you want including web services,
to design it so that if one day or even a customer request means that i need
to run it from different computer then I should be able to.
TO sunmmarize my case, I have an OEM application ( on which I have no
control, not build by me) which is collecting different type information from
machine. Machine information are based on alarms ( imagin your ca with a red
light or warning displayed on your dashboard) that I have to record in
database. When the OEM application gets an alarms, it is capable to post a
message than new alarms occurs, then my .NET library should be able to catch
that alarm, store it to database and then send nformation back to the OEM
aplpication to informed that data has been stored, please send me the next
one.
remoting, messaging etc - I think your time might be better spent by
initially putting the technology to one side, and working out exactly what
*your* requirements are without consideration to tools. That way, you can
then go through the distributed tools one by one, taking time to understand
what unique feature each tool brings to the table, and evaluating them
against *your* requirements, and deciding which aspect of what distributed
tool can be used to solve which portion of your requirements.
The messaging mecanism is nt yet define between that application and my .NEtPerhaps you could add workflow to the list of tools to evaluate against your
library. As I have never made such kind of things yet, I was simply wondering
what type of technology should I use for that case. (MSQ, simple remoting).
I was even thinking if I could use Workflow fondation for that.
requirements...
At first I was thinking of having a Windows service which will initializingA windows service is ideal in scenarios where you want your component to
that message stuff, then OEM wil right into and my lib will read it ..
But dos a windows service is really he solution here?
automatically start and be available after a machine reboot (possibly before
a user logs in), so again if this is a requirement of yours then a building a
windows service might be the thing for you - however as with the above, you
need to test this theory against your requirements...
hope this helps,
Patrick
--
Patrick Simpe-Asante
MCAD, MSCD.Net
"calderara" wrote:
HI patrick,.
I have to say thnaks for your huge description and I have to admit that I
get lost after a while.. :-(
For my case everything will work first on the same computer BUT I wold like
to design it so that if one day or even a customer request means that i need
to run it from different computer then I should be able to.
TO sunmmarize my case, I have an OEM application ( on which I have no
control, not build by me) which is collecting different type information from
machine. Machine information are based on alarms ( imagin your ca with a red
light or warning displayed on your dashboard) that I have to record in
database. When the OEM application gets an alarms, it is capable to post a
message than new alarms occurs, then my .NET library should be able to catch
that alarm, store it to database and then send nformation back to the OEM
aplpication to informed that data has been stored, please send me the next
one.
The messaging mecanism is nt yet define between that application and my .NEt
library. As I have never made such kind of things yet, I was simply wondering
what type of technology should I use for that case. (MSQ, simple remoting).
I was even thinking if I could use Workflow fondation for that.
At first I was thinking of having a Windows service which will initializing
that message stuff, then OEM wil right into and my lib will read it ..
But dos a windows service is really he solution here?
Does the messaging MSQ is the right choice ?
Do I hev to use serviced component ?
All those question I ma still aking them and are quite fuzzy simply ecasue I
know what I need but I do not know which technology best suite my need simply
because of lack of knowledge of them. Even reading some article on msdn did
not ring my bell for the time beeing...
Regards
serge
"Patrick Simpe-Asante" wrote:
Hi Serge,
I've had to solve a similar problem to what you have, and I also used
something along the lines of a dispatcher service in conjunction with
remoting and MSMQ messaging.
The requirements I had were that each responding component (or assembly in
your case) had to be 'hostable' on a separate server, and in addition if
required, each could be hosted in a server cluster (fronted by a load
balancer). One other requirement I had (may not apply to you) was that the
functionality had to be extensible (in addition to being distributed) after
the deployment phase.
To solve this, I created two interfaces IClientPlugIn and IServerPlugIn,
whose implementing assemblies/classes were hosted in designated folders at
the client and server computers respectively. Each plug-in pair (client &
server) had a matching task id (using attributes to decorate the plug-in
classes). Also, each IClientPlugIn was a subclass of a generic class that
provided methods for remoting.
To 'trigger' execution on the server, a special "initiator" console exe
located on the client would be passed a task id at the command line - this
task id was then used to locate an IClientPlugIn assembly/class (using
reflection to match the task id), which in turn utilised its base class
remoting functionality to connect to the server, and stream an XML document
containing any required parameters over to the server. Note that each client
plug-in had an accompanying configuration file (named the same as the
assembly, but with ".config" appended) that included the address of the
target server that hosted the component, as well as parameters wrapped/passed
via the XML document.
At the server, a message dispatcher service would receive the remoting call,
unwrap the XML received into an MSMQ message, and place this on an MSMQ
queue. As an aside, to place the received params inside the MSMQ message, I
constructed a XmlMessageFormatter passing in new Type[] { typeof(string) },
and assigned that to the message's "Formatter" property.
A second service running on the server, which was blocked on the messaging
queue, would pick the message off the queue, retrieve the target task id and
adorning parameters, and again using reflection, match the corresponding task
id on the appropriate IServerPlugIn assembly/class and then execute the
appropriate action as required.
One advantage with this approach was that to start off with, all components
were hosted on the same server, however as loads increased, the components
began to be spread across different physical servers (each with a dispatcher
service installed) without the need for code changes, just configuration file
edits. We are not there yet, however in the near future, it will be fairly
straightforward task to utilise a load-balancer and have the same component
hosted on multiple physical servers). In addition, use of the plug-in
pattern meant that after deployment,it was simple to extend system
functionality by creating new IClientPlugIn/IServerPlugIn pair assemblies and
xcopying these into appropriate folders on the client and server, to be
triggered as normal via the console initiator exe.
A few points to note:
- in our set up, client's were not allowed to have MSMQ installed, hence use
of remoting from client to server - this had the obvious drawback that
servers had to be up-and-running to service remoting requests. Without this
restriction, clients will likely have used messaging (instead of remoting) to
the dispatcher service, which would have meant that message requests would
have been placed on server queues for later processing even if the server
components were down.
- our set up did not require asynchronous execution of receieved messages,
so you'd have to do some extra work/thinking there
- use of this solution was in a closed environment so for remoting etc, it
was acceptable to use tcp transport & normal messaging etc (which is not
secure). Clearly, you'll need to re-think parts of this solution if high
security is especially an issue.
Here's to hoping that this helps you somehow :-)
Kind regards,
Patrick
--
Patrick Simpe-Asante
MCAD, MSCD.Net
"calderara" wrote:
Dear all,
I have different .NET libraries which should answer and execute proper
operation based on external application message. Each assembly should listen
from its own messages.
Messages are coming from an external application and my own assenblies
should answer to those incomimg messages.
For that I was thinking to build a service that I could named "Message
dispatcher". That service will listen to incoming message and then send it to
proper assembly for processing.
Note that message will be asynchrone and as a first step all assemblies will
be on the same machine.
For message handling I was thinking first to use this Message queue from
COM+ component but I have no experience at all on those messaging process.
My questions are:
1 - Does the message dispatcher as a service is a good approach ?
2 - Does MS Queue under COM + is a good approach ? is it har to set up
Thnaks for all
regards
serge
- References:
- RE: Need advise on concept ???
- From: calderara
- RE: Need advise on concept ???
- Prev by Date: Re: Middle Tier Dev for legacy app
- Next by Date: Remoting - Multiple chanels not working
- Previous by thread: RE: Need advise on concept ???
- Next by thread: Microsoft Enterprise Library Cryptography Application Block
- Index(es):
Relevant Pages
|
