Re: [ebsoa] Ben's document

["Chiusano Joseph" <chiusano_joseph@bah.com>]

I've added to David's excellent list of patterns below. I'm headed back
to New Orleans next Wed morning to present SOA (general concepts,
benefits, etc.) at a DOD conference, and I'm considering incorporating
the notion of patterns into my presentation.

Joe

David RR Webber wrote:
> 
> Duane,
> 
> OK - done - synopsis - this is the programmers eye-level view
> that fits into that world of people using UML to create
> enterprise integration applications with J2EE et al today.
> 
> So - in addition to this - following Ben's usage - we need
> the SOA BUP - Business Use Patterns, as the overarching
> view here - that introduces what ebSOA is all about -
> and most important - how people can use SOA BUP
> to develop their own solution rapidly.
> 
> That way we can dispense with the history lesson in
> OO et al -(well OK - that's NTH - so we'll keep it
> as an Appendix "The Evolution of SOA components").
> 
> The SOA BUP will allow business integration designers
> to pick models and patterns, and create new patterns
> for their own for industry uses.
> 
> Typical patterns would include:
> 
> 1) Classic ebSOA - this is the ebXML pattern around BPM.
> 
> 2) Holistic ebSOA - blends use of BPM with webservices.
> 
> 3) POA - process-oriented architecture.
> 
> 3) SOA - EAI service oriented architecture.
> 
> 4) EPR - bespoke solution pattern(s) for particular
>     sector domains - in this case eGovernment services
>     and citizen-facing applications.
> 
> and so on.

How about these possibilities:

5) Infrastructure - utilizing an SOA for infrastucture-type services
such as security, logging, discovery, etc. 

6) Calculation - where part of the SOA provides a calculation result
based on input values (such as calculation of APR for a loan); but this
would be a pattern for a "segment" of an SOA, rather than an SOA
overall.


*** Maybe we need to think about "sub-patterns" as well? ***

7) Transactional - utilizing an SOA for transactional-based processing,
such as the submission/processing of a PO to receive an Invoice.

8) Notification - utilizing an SOA for notification-type services such
as a calendar service that sends notifications to other calendars when
an appointment is changed;

9) Others?

> What I'm chiefly after here is avoiding being button-holed.
> 
> Ben's approach to SOA - while good for todays programmers
> can also suffer from rapid obsolescence - as witnessed from
> people touting POA, and varients already today.  You are
> then yesterdays news.
> 
> We need to have an adaptive model here - that can then
> assimulate the latest in-vogue programming components
> as they emerge.
> 
> Therefore POA with ebSOA patterns
> keeps you right abreast of a new development. Hence
> SOA BUP is essential IMO.   But more important
> it allows you to precisely define what a POA is in
> terms of your proven known value set of components.
> An erector kit.
> 
> Thanks, DW
> 
> ----- Original Message -----
> From: "Duane Nickull" <dnickull@adobe.com>
> To: <ebsoa@lists.oasis-open.org>
> Sent: Tuesday, June 08, 2004 6:55 PM
> Subject: [ebsoa] Ben's document
> 
> > I also urge each and every one of you to read Ben's PDF document
> > uploaded to our members section.  This reads very well.
> >
> > Duane
> >
> > --
> > Senior Standards Strategist
> > Adobe Systems, Inc.
> > http://www.adobe.com
> >
> >
> >

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton