If I want to develop a high performance application on multi-core architecture, but my application doesn't use SOA, would Software Pipelines help? Or Software Pipelines is most suitable to use in SOA applications?
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
This is a great question, and yes you can use it for non-SOA applications (in the traditional sense anyway).
One thing we realized early on is that SOA is an architecture, and most people confuse it with Web services and related standards. These are really protocols, distinct from the concept of how to organize your application code.
The thrust of Software Pipelines is that you can scale your application code by packaging your code as service components, but how you invoke them and by what protocol is completely outside the realm of developing the service component itself. For example, if I have a service "foo" and a message it needs "bar", you can think of a service invocation as a method call: foo.send(bar) (send the message "bar" to service "foo").
In fact, here is an interface method from the pipelines reference framework:
Now, the location of the service, how it is invoked, is complete abstracted from the developer. This is defined in a config file for use at runtime.
Based on this a "service" can be invoked locally in the same server or process (which is implemented efficiently with a direct method call and threading code that is encapsulated in the framework), or it can be invoked across your LAN or anywhere in the world via the Internet. The idea is that is a deployment decision, based on load, not a functionality concern of the service developer.
The reference framework is easy to work with, but of course you can extend it to do a lot more things than it does -- still without changing how you build the services components themselves.