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>
*To:* service-orientated- architecture@ yahoogroups. com
*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
