I think often as developers we overdo things and while better we
implement patterns and solutions whose benefit is extremely marginal.
However as a concept SOA and loose coupling provides a lot of benefit,
being a concept also there are no right answers.
With regard to SOA I follow 2 rules.
1. SOA = Chunky calls
2. SOA must be autonomous. eg One method must not depend on the result
of an other.
Techniques for managing the type of consumer.
- Get the login UserID. From this the server can gain a lot of
information such as location, type of user, roll etc.
- Send a parameter record or a parameter with the type. Note I
use parameters that are clear, commonly used business concepts.
- Expose multiple methods. If they do different things sometimes
it is better to have multiple methods.
None of these result in any real increase of the tightness, except maybe
a complex parameter record, which would be the least preferable.
Regards ,
Ben
> -----Original Message-----
> From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Bill Bassler
> Sent: Friday, 1 July 2005 12:01 AM
> To: [email protected]
> Subject: [ADVANCED-DOTNET] SOA and the consumer-specific request
message
>
> I've been working with web services/SOA for about a year now. I've
been
> trying to keep a watchful eye on the overall issues I've encountered
and
> how they effect SOA design; or an attempt at SOA design. One thing
that
> has
> become very apparent over the last year is that it seems that there is
a
> very difficult to manage line between service orientation and just
plain
> old (somewhat tight) itegration between business parteners that happen
to
> use web services as a messaging technology.
>
> One of the issues that I've struggled with time and time again with
any
> actual requirements and a resulting design are the principles of
service
> autonomy and loose-coupling between service provider and consumer;
> specifically how these issues relate to a scenario where a request is
made
> to service by a specific type of service consumer. For example, I
often
> run
> into situations where requirements dictate that the service needs to
be
> designed so that it has the capability to determine the "type" of
consumer
> that is making the service request because the request needs different
> processing steps based on the "type" or consumer context. While there
are
> many ways to handle this requirement, this issue often results in a
> tighter
> coupling between the service consumer and provider due to the fact
that
> both the consumer and provider must share this contextual knowledge so
> that
> the provider can appropriately process the message. It seems to me
that
> this violates some of the basic SOA principles. To make matters worse,
> existing decentralized implementations that backend many web service
> processing are based on unexposed/private, non-federated user
identities
> or
> domain specific support data. It is often that case that it's required
> that
> services accept various private system identifers and identifier
mappings
> so that the service provider can process a specific request in a way
that
> appropriately interacts with the consumer.
>
> One might imagine that these kinds of issues could be remedied by
exposing
> addtional contextual information based services so that the consumer
can
> use them to discover provider specific information or that in some
cases
> the provider might be given the ability to internally determine this
info
> via something like content enricher processing but these
implementations
> also have their consumer/provider coupling and partener support data
> synchronization issues.
>
> Does anyone have any experience/opinions to share that shed some light
on
> how to best handle these issues? Am I just confusing SOA
design/wishful
> thinking that I might be able to implement an SOA given the
circumstances
> with what is really a just a systems integration in my real-world?
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
