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
