[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]