For example, the answer to reliable asynchronous messaging might be to use JMS or MQ or another middleware that ensures guaranteed delivery of asynchronous messages.

[Sargent Juliana]

Most well architected business applications have a presentation layer, a
business logic layer and a database layer. Interaction MechanicsSo far
we have identified ways to categorize the overall intent of building an
integration solution and the mechanics of connecting to a single
application. The Metadata HubThe issue of data format translation raises
a new point. Typically something has been created and the next decision
builds on what already has been created. In order to do this, you have
to connect the application to some form of integration backbone so that
the application can participate in the exchange of information. The
Smart Proxy captures the message ID of the original request message and
stores it. It dramatically reduces the complexity of developing software
by allowing us to solve problems at a higher level of abstraction
without getting bogged down in the details. Fun with DoodlewareOrjan
Lundberg reminded me that I forgot to mention a very important aspect of
doodleware: using it to doodle when the system is down or the clients
can't make up their minds. Your Mileage May VaryIs Hub-and-Spoke the
answer to every integration scenario? In the world of messaging this can
happen in one of two ways:The component can subscribe and publish to one
or more channels of its choosing. In general, nothing really blew my
socks off. First of all, inserting a hub into the lines communication
can cause additional overhead. Because integration is such a broad and
varied field, there are definitely additional ways to categorize
solutions, for example by the topology, such as Message Bus, or
Hub-and-Spoke. Modeling such a system in a single tool seems to assume
that you have a clear understanding of how the individual pieces are
going to interact. IntermediariesHowever, using the Message ID as the
Request ID has at least one important limitation. In the absence of a
metadata repository we can capture all messages that flow through the
system in a central Message Store. Therefore, the implementation of this
type of Hub-and-Spoke architecture typically includes data format
translation capabilities. However, this approach is limited to detecting
static communication between components. It will take some time for
vendors to better understand the developer usage patterns and how to
make BPEL development more efficient. Conversation IdentifierSo how can
we avoid the unlucky "distributed call stack with messaging"
architecture? Also, a process definition tends to be much more driven by
data flow than by the association of data and behavior as it is common
in the object-oriented world. This decision tends to be a much more
global architectural decision than the decision of how to connect to a
specific application. A visual representation of the system is certainly
useful, especially if we deal with a system that is asynchronous and
concurrent by nature. I guess they had not heard about code behind
pages. I am a bit more on the fence on that aspect; one can't help but
wonder whether you should be using Web services in the first place if
your performance requirements force to use a fixed binary format. Your
Mileage May VaryIs Hub-and-Spoke the answer to every integration
scenario? This means we can use it synonymously with Conversation
Identifier. Every self-respecting developer can't help but spew out big
words like factory, decorator, or observer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 25200 bytes
Desc: not available
Url : http://zver.fsa-bg.org/pipermail/web/attachments/20070110/d8101638/attachment-0001.gif