MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia] [wsia-req] Configurator Scenario
Title: Message
Dan,
Just to clarify... Kingston is not a customer of
WebCollage - I just pulled the example since memory configuration was brought as
a scenario.
As for your question, we as in WebCollage often
implement what we call ASAP (Assortment, SKU numbers,
Availability and Pricing).
Implementation architecture is typically divided into
one of the following three options:
1. (Most common) As the Producer page is being
created/rendered, Syndicator (our product) shoots an XML message to the Consumer
application, requesting real-time data. You can think of it as the Producer
invoking a Consumer Web Service and/or as an event-based paradigm in which the
Producer generates events (such as "give me up to date pricing") and the
Consumer returns some data. Variations differ in binding between the producer
and the consumer, the protocol used (SOAP/XML/...), size of dataset,
etc.
2. (Common) A Web-based tool within our environment is
used for the Consumer to manually upload pricing, etc. This data is made
available as a dataset to the Producer application while it's generating the
page. Variations differ in the data acquisition UI, the data formats used (e.g.,
manual update or upload of tab-delimited data).
3. (Less common, we don't have this within the product
yet). The Producer periodically "pulls" data from a Consumer data store and
stores it into its database. The Producer application uses the data to render
the pages. Variations differ in the protocol (HTTP/FTP), security, data formats
and data sizes.
Having said all this, I am not sure whether this is
under the scope of the WSIA committee or whether we should leave it to be
implementation-specific, as above. The only scenario which seems to be "generic"
in the above is the first one, as the concept of "events" (in our product we
call it plainly "messages") seems to be pretty common and has been around in
component architectures for a while.
Hope that answers the question... we can also take it
offline if there are specifics which you feel are beyond e-mail
correspondence.
Eilon