<<Reuse is a core part of SOA, so much so that several strategic goals
associated with enterprise-wide SOA transitions are directly linked to
successfully achieving the repeated reuse of automation logic. As a
result, we need to ensure that the services we deliver do not just
possess reusable logic, but are also capable of being reused once
subjected to the real world.
In general, we are encouraged to foster and maximize reuse
opportunities. Each service classified as "reusable" is made available
to a potentially large number of consumer programs. The results are
predictable. Over time, the same service will need to facilitate the
automation of different business processes or tasks and may become
part of numerous service compositions.
This eventuality translates into high usage volumes, unpredictable
usage scenarios and a runtime condition we are especially interested
in preparing for: Concurrent access. When a service is accessed at the
same time by two or more service consumers, instances of the service
are spawned. How this happens is, to a large extent, determined by the
vendor runtime platform responsible for hosting the service.
However, there are important steps we can take in shaping the design
of the service in order to structure the underlying service logic to
best facilitate the condition of concurrent access and other
reliability-related concerns.
This leads us to the two design principles we'll be briefly explaining
in this article:
* Services are autonomous
* Services are stateless
If I'm building a program designed to consume a particular service, I
may not know or care about how many others are already using this
service (and how many more will use it in the future). I will have an
expectation as to what the service is capable of doing, based on what
is expressed in its service contract and perhaps in a supplementary
SLA. Therefore, I will be relying on the service's ability to provide
a predictable level of behavior, performance and reliability,
regardless of how else it is being utilized. The application of these
principles ultimately helps support a stable and, most importantly, a
predictable service inventory.>>
You can read this in full at:
<http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1192369,00.html?track=NL-130&ad=556009&ad=555322>
Gervas
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get to your groups with one click. Know instantly when new email arrives
http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
