> -----Original Message-----
> From: korosh afshar [mailto:[EMAIL PROTECTED]
>
> I have a application that needs to use Service A to read messages off of
> the messaging bus and fill up the Queue of service B with certain types
> of those messages.
>
> Now, keeping in mind some of the best practices of service oriented
> design of ensuring each service does one thing and does it well, I
> don't want Service A to have to know about Service B, as I'd like to use
> Service A with other non-Queue based applications.
The trick is in how you define your service interfaces. It's not that you
don't want Service A dependent on Service B, it's that you don't want the A
_implementation_ dependant on the B _implementation_. In other words,
Service B is NOT a queue. The queue is an implementation detail. The
service is what Q provides.
Simple Example:
public interface ServiceB {
Message getMessage();
}
This doesn't say _anything_ about where Service B gets the message. Of
course, you can probably come up with an interface definition that is more
specific and better suited for your application. What you don't want is
something like:
public interface ServiceB {
Message getMessageFromQueue();
}
So you're issue here is not about service dependencies (which is fine), it's
about implementation dependencies and making sure you define your services
in an implementation agnostic manor.
Here's another thought: You want to use Service A with other non-Queue
based applications right? Well, what will all these non-Queue based
application + the queue based application have in common? What common
methods could/should they have? The answer will be the proper definition of
your Service B.
J. Aaron Farr
SONY ELECTRONICS
DDP-CIM
(724) 696-7653
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
