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 <[email protected]>
*To:* [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
