Re: [soa-blueprints] > Client Patterns

[<marchadr@wellsfargo.com>]

It would in essence be different actors to a service.

An actor can be:
- service client
- portal
- orchestrating service
- service broker
- etc...

These can have actors themselves that can follow similar patterns of consuming the service.

My 2 cents.... More to follow as I have time to comment.

- dan





-----Original Message-----
From: Mark Cowan <mcowan@adobe.com>
To: Marchant, Dan R. <marchadr@imc.wellsfargo.com>; soa-blueprints@lists.oasis-open.org <soa-blueprints@lists.oasis-open.org>
Sent: Wed Nov 30 14:01:19 2005
Subject: RE: [soa-blueprints] > Client Patterns

Hi,

	I would go beyond it being a devilish detail by saying that it
could present equal complexity  to the patterns being defined on the
back end.  Consider a long running process in the context of a portable
client that is sometimes connected to the back end.  How does the static
nature of service react to being not always being in contact with the
environment that it is part of?
	
	Going further - how does the client side orchestration of
services define what happens in the back end?  Are there patterns that
define how these should interact with one another.
	
	Perhaps another way to ask this - is the client another SOA
container that defines how services interplay?
	
	Breaking this apart I see three classes of blueprints.  
		1. User patterns
		2. User/System patterns
		3. System patterns	

Thoughts?	

Mark

MRC

-----Original Message-----
From: marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com] 
Sent: Wednesday, November 30, 2005 11:54 AM
To: Mark Cowan; soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] > Client Patterns

This is a good point.

The devil is in the details of the client is come respects.
The blueprints should cover the client variations as well since in some
camps a portal is a type of service the customer is invoking that
orchestrates and coordinates information from other services through a
service client contract with the service providers of the backend.

I'll try and incorporate this into an area of the wiki to talk more
about.



- Dan

-----Original Message-----
From: Mark Cowan [mailto:mcowan@adobe.com]
Sent: Wednesday, November 30, 2005 8:38 AM
To: soa-blueprints@lists.oasis-open.org
Subject: [soa-blueprints] > Client Patterns


Hello,

	I see much of the discussion focused on how the interplay of
processes at the back end can/should be or not be defined.  However
nothing about what happens on the glass.  Noting that the majority of
the patterns and anti-patterns are expressions of how services work
together but then are surfaced up to users through two mechanisms -
portals and clients.   I find myself questioning much about the patterns
used to describe how services should even interoperate on the back end.
Meaning - by focusing only on the back are we missing a big part of the
landscape? 
	
	
Mark

MRC

Mark Cowan
Adobe
e - mcowan@adobe.com
p - 613.940.3974
w - www.adobe.com