From http://www.psdn.com/library/thread.jspa?messageID=8212—
If it is stateless, this seems to me that any one agent is also identityless,
meaning that it is not dedicated to any particular type of service.
Therefore, anything that we are going to call a service has to be at least
one level down from the agent. This raises the question of how it is that the
agent locates and "attaches" to or communicates with the service.
If this is done using Sonic, then it is pretty clear how a service publishes
its identity, how work is directed to it, how one communicates, how things are
routed, etc. The question I have is whether Sonic alone is sufficient.
I know I want it there for workflow management, distributed computers,
interface with external systems, etc., but it seems to me that I either
need large multi-threaded sessions or I need a very high performance method
of communicating among multiple sessions on the same box ...
creating, in essence a virtual AVM out of multiple sessions
I think you're looking for an Application Service Bus instead of an Enterprise Service Bus (sonic). I think the old ADM provided such a service through it's broker mechanism.
ESB is in my opinion great for transforming messages and queing up and tracing requests. It allows you to orchestrate the underlying services by declaring the flow in a visual designer.
ASB is about the inter application communication and a loosely coupled internal organization of objects. When you want a credit check, why do you need to know that you have to call class X and method Y. Maybe all you want is to post the request on the ASB and wait for it to be serviced. With so much dynamics going on, complexity increases for the developer, since tracking down the flow will become painfully hard. Thomas you're thinking about using Sonic for this, right?
And for the workflow-part: we still have the poor man's version of Sonic:
- a request table in the database (queue)
- a batch service monitoring the database table dispatching the requests (broker)
This used to work in the old days....
Conceptually, my preference would be to use Sonic throughout, both because using a single tool instead of two tools would be simpler, but because Sonic ESB is a very rich environment including things like the workflow engine which I would like to use throughout the application. But, I confess to being a bit frightened by the possible overhead for smaller scale interactions. As I just expressed on your AppServer thread, the core issue here is that other OO environments provide at least two or three levels of interaction between components, i.e.,
1) multiple threads within a single VM;
2) simple, direct connections between VMs; and
3) bus connections like Sonic.
With the AVM, we really only have the last one, unless one counts cobbling together something with sockets or pipes to be the equivalent of the other two layers. My instinct is that at least two layers are necessary, but I'm not sure how we should provide the second one.
Conceptually, my preference would be to use Sonic throughout,
Keep in mind that not all sites or situations require the cost that goes with using Sonic.
When I say Sonic, I say it based on the faith that PSC will eventually figure out the licensing so that it makes sense for use as an application architectural tool versus an EAI tool. With EAI, development costs are extremely high, so Sonic delivers substantial value and the current pricing is justified in that context. PSC understands that, if they want to see widespread adoption in the OpenEdge world, they have to figure out a way to package it so that people can use it in contexts where that kind of price will never fly. They shouldn't give up the value and price they get in the one context, so it is not going to be easy to figure out how to package it for this context, but my understanding is that this is under consideration.
If it doesn't happen, then one would have to use a different tool. JMS is certainly not hard to come by and there are open source ESB suites. They aren't as capable as Sonic ESB, but that doesn't mean that they might not be adequate for a more limited purpose.
When I say Sonic, I say it based on the faith that PSC will eventually figure out the licensing so that it makes sense for use as an application architectural tool versus an EAI tool.
I would hope so as well, I can think of some places where it'd be a nice addition if not outright replacement for other solutions currently in play.
Here's hoping!