I think, Sun Tzu in his /T
<http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html>he
Art of War
<http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html>
/ has
given us the receipt for SOA implementation for downtime saying
"Nothing is as important as having the right way of thinking."
SO is about SO thinking; SO needs technologies and expensive
systems at the very last, if ever, moment. SO is not in
technologies like BPEL and others. You can build service
orientation into regular code if you think first about it.
For example, several years ago I had a problem to solve: our
Documentum server prepared Web content, which had to be used by
the Application/ Web Servers (ATG Dynamo that time) to publish
on the Web, but did not notify ATG Dynamo when the content was
ready. Our Business publisher authored the content but could
not manage the publishing time. In my SO Solution, I
placed Documentum' s meta-file about prepared content into
MOM/Topic and made all ATG Dynamo servers to subscribe to the
Topic announcements. The ATG Dynamo servers used to be
re-booted nightly but they were able to get all missed
information and the new one due to the durable subscription to
the MOM Topic. Where ATG Dynamo servers were shut down and
where they (or their replacements) came up on-line (i.e. their
IP address) did not matter to the solution. [When Documentum
learnt this solution from us, they provided a free integration
Documentum-ATG Dynamo via Web channel. In their
solution, Documentum not only updated the data-store with the
prepared content but also sentthe appropriate Web 'requests'
to the registered ATG Dynamo servers. It looked fine except for
the cases when ATG Dynamo servers lost all information when
being down and had to get on-line with exactly the same IP
address they registered with the Documentum server before. This
was pure integration solution while I can consider my solution
was much more service oriented.]
- Michael
------------------------------------------------------------------------
*From:* Hitoshi Ozawa <htshoz...@gmail. com>
<mailto:[email protected]>
*To:* service-orientated- architecture@ yahoogroups. com
<mailto:[email protected]>
*Sent:* Fri, December 25, 2009 10:56:29 PM
*Subject:* Re: [service-orientated -architecture] Descriptions
vs Contracts
I think you've hit the major difference we're having. I'm in an
actual project and tailoring my service so they can actually be
implemented with the current available technology, development
members, and other constraints. Also, with the economic slow
down, it is also necessary to reduce cost.
There was a mention of BPEL in the other thread, and I think
the basic technology is interesting, but the current situation
requires too knowledge of too many specifications that it
almost impossible to educate development members to complete a
project in time. Of course, in a small project, I can just do
it myself but in a large project, that's impossible.
SOA is dying not because the theory behind it is bad, but that
what most people are preaching can not currently be implemented
in a project. The tight economy is also sifting the emphasis
from "to be" more toward "can be".
Anne's cartoon showed a "SOA dinosaur", but IMHO the dinosaur
really isn't the concept of SOA itself, it more of us who's not
adjusting to the current economic market.
Happy Holidays,
H.Ozawa
2009/12/25 Steve Jones <jones.steveg@ gmail.com
<mailto:[email protected]>>
I'm designing them in this way but unfortunately in
implementation there isn't the technology to support this
stuff. WS-Contract or WS-SLA never happened and there
isn't anywhere near the formalism required.
Steve
2009/12/23 Hitoshi Ozawa <htshoz...@gmail. com
<mailto:[email protected]>>
So Steve, you're designing all your services these way.
H.Ozawa
2009/12/23 Steve Jones <jones.steveg@ gmail.com
<mailto:[email protected]>>
I can't see why not, although I'd reword it to be
In order to ship the carton a valid set of legal
constraints, written in French, must be agreed.
Take Air Traffic Control, there are two official
global languages for ATC there is English (used in
99% of the world) and there is French (guess where
that is used) but they are both official languages
at the service description level. Now some people
can constrain their description to say "we only
accept English" but this is still at the service
description level as an individual contract (with a
plane) has not yet been entered into.
Steve
2009/12/22 Hitoshi Ozawa <htshoz...@gmail. com
<mailto:[email protected]>>
We're talking about service description. Is it
alright to have "ship the carton with a valid
set of legal constraints in French"?
H.Ozawa
2009/12/23 Steve Jones <jones.steveg@ gmail.com
<mailto:[email protected]>>
I can't see why a contract of send invoice
via SOAP would be a problem with the
description being "send invoice", why would
it be a problem?
I think we are in danger of disappearing
into semantic holes. I could argue that if
the objective (service description) was to
woo a lady then the choice of the language
(service contract) could be either English
or French. In French we could take the
Cyrano de Bergerac approach while in
English we could fall back on the Bard of
Avon. Here the language is the piece that
seals the deal and is linked to the
specific consumer of the service, in other
words the language chosen (the contract) is
linked to the specific engagement between
the producer and consumer.
Steve
2009/12/22 Hitoshi Ozawa <htshoz...@gmail.
com <mailto:[email protected]>>
Hi Steve,
So are you implying "send invoice using
SOAP" is alright?
If you are, I sure would like to see
the system with such a design. :-)
French and English are languages people
use to rely concepts. British law is a
concept. Concepts described in the
British law does not (should not)
change whether it's written in English
or in French.
H.Ozawa
2009/12/21 Steve Jones <jones.steveg@
gmail.com <mailto:[email protected]>>
I actually think that French and
English is fine. It is like having
a shipping contract, there are a
huge number of different legal
jurisdictions that you could
potentially use to ship the product
from A to B (the description) but
when you formalise the contract you
pick a single legal country as your
escalation point.
So in other words the description
of A to B just says "ship the
carton with a valid set of legal
constraints" while the contract
says "ship the carton with British
Law as the legal framework"
Steve
2009/12/19 Hitoshi Ozawa
<htshoz...@gmail. com
<mailto:[email protected]>>
Andrew,
I think you're beginning to
understand the concept,
but your example is missing the
point.
Your analogy with French and
English is inappropriate unless
you're thinking of a
translation service.
Service description describes
the semantic capabilities of
the service while service
contract describes the set of
rules used in an instance of
an interaction.
H.Ozawa
2009/12/18 Andrew Herbst
<herbst_andrew@ yahoo.com
<mailto:[email protected]>>
Greetings:
Another question from an
SOA neophyte. Thanks for
responding to my earlier
questions.
So, roughly speaking, a
service description is like
me announcing to the
world: “I can interact in
French *or* in English”,
whereas, a service contract
is like me agreeing to
speak French with a
specific other person in
the context of some very
specific interaction.
I realize this is a very
basic question, and it may
well not really be the aim
of this group to deal with
such basic things. I will
therefore take no offence
if no one addresses this.
Thanks,
Andrew Herbst
