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
