foundations of serviceoriented architectures

1
foundations of service-oriented architectures

• kenneth a. faw
• president
• pillar technologies, LLC

2
what is a service oriented architecture?

• a different way to think about enterprise
  software design
• previous thoughts involved disparate systems
• these systems often contained duplicate
  functionality
• computational variances and inconsistent workflow
  may result
• data replication is often the first silver
  bullet, but is no panacea
• now, focus on composable business services
• each service provides a piece of the enterprise
  puzzle
• introduces new capabilities and new complexities

3
building up to SOA
a hypothetical company (like my own)
Ken Faw
unfortunately, data replication and
synchronization is not the end of the
story Which systems might allow me to create a
new employee, or a new customer???
Excel?
Ken Faw
Clipper
Ken Faw
SQL2K
GM-Onstar
Oracle
GM-Onstar
Benefits
Resource Management
GM-Onstar
Accounting
Human Resources
Billing
Payroll
Ken Faw
MS Access
Project Tracking
GM-Onstar

• you know it cant actually be my own, because IT
  consultancies never actually work on their own
  internal systems. ?

4
what about component architectures?
Resource?
when we select a system to serve up Customer or
Employee components, things change
systems speak to Systems using standard
interfaces
Excel?
Clipper
SQL2K
Oracle
Benefits
Resource Management
Accounting
Human Resources
Billing
Payroll
MS Access
Project Tracking
the need for data replication also changes
5
promises of the service-oriented architecture
Excel?
Clipper
SQL2K
Logical Enterprise Data Model (perhaps disparate,
perhaps EII)
Oracle
Benefits
Resource Management
Accounting
Human Resources
Service Provisioning
Billing
Payroll
MS Access
Project Tracking
6
a more comprehensive case for SOA
added

• complexity
• the Internet business model integrates business
  partners
• growth through MA creates integration and
  migration problems
• legacy applications and infrastructure are
  cost-prohibitive to replace
• redundant/non-reusable programming
• multiplicity of interfaces
• n applications directly connected need n(n1)
  interface connections
• adding the n1 app requires 2n more

7
the reusability continuum
added
8
the three-layer architecture
added

• we often think of web services from a provider
  and consumer perspective
• provisioning in the service layer itself is
  extremely important to consider
• it is the primary differentiator of the SOA
• composability (covered later) involves combining
  features at the service layer
• security, discovery, scalability, life cycle,
  transactions, etc.
• previous architectures which ignored the service
  layer required us to code features into the
  provider
• note that this does not detract from additional
  options within service provider or consumer
  layers, e.g., EII

9
giving the service layer its due
added

• hence, the service layer is not simply an
  interface
• it is a first-order deliverable in addition to
  the service provider and its consumer(s)
• nearly every architectural consideration of a
  SOA involves, or is directly composed in, this
  layer

10
wrap embrace,not rip replace
added

• existing systems can rarely be thrown away
• services allow existing systems to be tactically
  integrated
• over time, they can be componentized or replaced
• the result is more manageable, incremental
  project structures

11
three big examples of SOA in our experience

• the merger of Daimler-Benz and Chrysler
  Corporation (PA/CDM)
• integration of PeopleSoft and SAP human identity
• also security systems, payroll, HR, phones,
  network, etc.
• Chrysler Financial Services (WebAMS-Tax)
• over 7 variance in tax computations from system
  to system for remarketing asset management
  functions
• gradual evolution of Onstar from its initial
  startup systems (CCA, VA migration, Vehicle
  services)
• little authority for core data ownership
  (subscriber, vehicle)
• no cohesiveness in enhancements for new features
  (VASC)
• significant human expense in manual processes
  (CCA)
• additional examples come from experience with
  Cintas Corporation, The Accident Fund Insurance
  Company and Gordon Food Service

12
how much experience can anyone really claim?

• understanding of SOA is evolving, as in the
  earlier transition slide
• was PA/CDM actually a SOA?
• SOA is an architecture
• it transcends technology
• in a perfect world, SOA is independent of
  technology
• todays standards and technology make SOA more
  meaningful
• but you have to choose which elements of SOA are
  important to you

13
simplified list of benefits

• services are designed around business concerns,
  not simply for the sake of one application
• granularity provides agility to react to business
  change
• consistency reduces system variances and
  simplifies workflow
• reuse improves maintenance and administration
• SOA is technology agnostic, improving integration

14
more detail added benefits of SOA

• discoverable, dynamically bound
• interoperable
• designed by contract
• location transparent
• loosely coupled
• coarse-grained
• understandable (cohesive)
• maintains continuity during change
• protection/isolation from propagating defects
• problem domain mapping

• self-contained, modular
• composable, reusable
• decomposable
• quality of service
• service-level agreements
• monitoring and self-healing
• available
• reliable
• accessible
• integrity (transactional)
• performance
• secure
• testable

we owe many of these concepts to developments in
the wireless space
15
unfortunately

• most existing systems do not use the SOA
  metaphor, so we cannot just switch over
• remember the disparate data sources
• consider the pervasive coding required on nearly
  every system
• moreover, the added benefits of the previous
  slides are not free or necessarily simple
• nevertheless, they are achievable through tools,
  training and experience
• there is also significant hype these days about
  SOA implementations

16
SOA hype

• actually, we have had precursors of SOA for
  several years, starting with RPC, DCE and CORBA
• so where does the SOA hype come from?
• web services promoted by .net and J2EE fuel the
  debate
• regardless, those with past history in other
  architectures can bring some of their knowledge
  to bear in both cases
• the fact that you do web services, J2EE session
  beans, or even EAI does not mean you have a SOA
• rest assured, you CAN implement all the SOA
  features outlined earlier
• however, you will not achieve all these features
  out of the box today, but have some decisions
  to make
• not all those features may be desirable

17
recommendation

• because of the hype and the complexity in
  migrating to SOA
• pillar recommends careful planning according to
  value management principles
• guarantees continuous progress toward SOA at a
  pace the business can handle
• preserves adaptability to priorities of a
  changing marketplace
• mitigates risk during transition
• this planning aligns the value of your business
  goals with your technical solution

18
moving to SOA undervalue management

• many problems that involve integration or
  transformation may map to SOA solutions
• what is valuable?
• perhaps not SOA itself
• SOA may just be a pattern
• which capabilities of SOA are desired or required
  to realize desirable value?
• most, if not all, SOA capabilities come at a cost
• lets cover those capabilities in more detail

19
foundations of consistency

• if our enterprise were a collection of disparate
  services
• specification of service-level interfaces could
  include semantic information
• they should describe parameters and results using
  interoperable types
• parameter meaning and validation rules would be
  understood
• they would follow standard strategies for
  exception handling and logging
• this, along with other best practices, is called
  design by contract

20
service interface standards

• of all the options you have for SOA, why include
  design-by-contract?
• because many SOA options depend on consistency of
  service interfaces
• design-by-contract, or component contracts are
  custom decisions
• you must make and agree to support them
• they may not be the same from one company to the
  next

21
examples of component contract standards

• documentation standards
• pre- and post-conditions, exceptions and other
  interface semantics
• logging guidelines
• for troubleshooting
• exception handling practices
• to confine disasters and for better
  troubleshooting
• monitoring framework and guidelines
• for application support
• unit testing framework and standards
• for regression, change management and momentum
  (refer to Borcon session)
• development process standards
• source control standards
• is the repository for work-in-process?
• build framework and guidelines
• service changes must build on the fly
• continuous integration standards
• interestingly, what is the difference between a
  standard and a guideline???
• configuration management guidelines
• deployment framework and guidelines

22
interface semantics

• suppose you have a service with the following
  interface (in Java)
• interface Reactor
• public ReactivityDelta pullRods(
• double distance) throws Oops
• how would you feel writing an app to consume this
  service interface?
• what is missing to make you feel better?

23
abstract, yet precise
added

• web service interface specifications should
  include
• sequencing rules if methods must be called in
  order
• pre- and post-conditions
• careful... preconditions may inhibit flexibility
  and robustness
• consumers couple to interface semantics, but not
  the implementation
• providers should not make assumptions about
  consumer behavior, outside of this specification

24
additional semantics on interfaces
added

• WS-Policy documents can be composed with WSDL to
  add info regarding
• method security
• transactional requirements
• WS-MetadataExchange can also provide descriptive
  information
• may be used to query or to load UDDI resources

25
other component contract considerations

• many other considerations in a component contract
  will be covered later in this session
• monitoring guidelines, self-healing
• isolation and exception handling
• configuration management and deployment framework
• test harnesses

26
finding a service

• if our enterprise were a collection of disparate
  services
• applications would lookup and locate those
  services
• service replicas could share load and failover
• adding replicas may dynamically repartition the
  load
• failover policies could be contract-based or
  codified
• as new services become available, they could
  broadcast (or register) their availability
• applications could dynamically make use of their
  functionality
• this is called service discovery

27
options from the past for enhancing service
discovery

• location services
• clustered JNDI
• SmartAgent technology
• global registry
• UDDI or ebXML
• LDAP
• IIS service replication

• load balancing
• SmartSwitch
• virtual IP
• reverse DNS
• management agents
• custom alternatives
• dynamic proxy

28
building our architecture service discovery
29
business service buses

• one practice is to group service registrations by
  business domain
• like HR, logistics, etc.
• often groups of services share similar security
  policies, transactions, document schemas, etc.
• sometimes, service groups form business platforms
• enables better application management,
  enhancements and support
• multiple UDDI registries could facilitate this
• can include low-level supporting services for a
  level of service abstraction in the domain

30
WS-Addressing

• provides endpoint info within the message header
• can even include resources within a service
• allows endpoint identification through
  intermediary hops and firewalls
• may specify a different return endpoint than the
  original sender
• can be used for routing like workflows

31
substitutability

• if our enterprise were a collection of disparate
  services
• two services conforming to the same interface
  semantics should be substitutable
• except perhaps for quality of service differences
• substitutable implies throw-away-able, sort of
• moreover, a client of a service should not care
  where the service is actually executing
• clients should not be dependent on using the same
  service each time
• this is called location transparency

32
discovery versus location transparency

• transparency is not just another view of
  discovery
• nothing in the consumer needs to change based on
  where the service implementation is located
• VisiBroker identified three distinct service
  locations
• same process
• different process, same machine
• different machine
• regardless where the service was, the client
  functioned without modification
• even better VisiBroker nevertheless optimized
  the invocation for where the service actually
  was!!!
• this could be a serious benefit of using BES (if
  this were a product pitch ?)

33
services services

• if our enterprise were a collection of disparate
  services
• each service would provide guarantees of its
  uptime, for example
• reliability service execution produces correct
  and consistent results according to requirements
• availability e.g. the service is running 24x7
  or 5x9
• accessibility the service has capacity to
  exceed specified peak demand request levels
• robustness the service is free from defects,
  under usage defined by its component contract
• these are some of the items described in
  service-level agreements

34
quality of service

• service-level agreements and implementation
  substitutability allows varying quality of
  service
• two invocations from distinct clients may be
  handled by different service implementations
• not just different physical services, but
  different algorithms
• the decision of which request gets which
  implementation is a matter of differentiating
  policy
• contract or product model year
• the requestors role within the company
• willingness to pay for better service levels
• execution of the policy must be consistent

35
service granularity

• if our enterprise were a collection of disparate
  services
• a single network invocation should kick off
  large-volume processes
• service interfaces should make use of bulk and
  group operations
• service tokens allow clients to preserve
  intermediate state
• of course, the service preserves its
  interoperable types
• this is called coarse-grained

36
what about the canonicalstock quote service?

• double getLastPrice(String tickerSymbol)
• it seems to be fine-grained
• fine-grained services do exist
• much like quick, distributed function calls
• should be VERY responsive
• are often read-only or subscription-like
  services, like the Quote service
• most coarse services perform high-level or
  complex operations, versus smaller functions
• they map to externally observable system
  behavior, not typically the steps within

37
concerns aboutfine-grained services
added

• as a rule, fine-grained services imply a greater
  number of services
• require more time and money to develop, deploy,
  administer and enhance
• cause increased network traffic
• may produce too many right combinations
• produces inconsistent workflow in high-level
  processes
• this is one of the reasons we moved to SOA in the
  first place

38
fine-grained and type-less services gone awry
added

• Onstar Chordiant CRM A-Service
• fear of the future produce one service with
  business functions and CRUD methods
• over 3500 methods in one object very
  fine-grained
• completely exposed and coupled applications to
  the internals of enterprise data
• better decompose into several services, only
  expose functionality as needed, implement better
  life cycle
• GE Transportation Systems (Railway Management)
• type-less controller forced clients to generic
  List of Vector parameters and results
• custom marshaling code significantly complicated
  both client and server
• any change to meta-structure required changes
  everywhere
• better use XML for parameters and results it
  is a simple string, but self-describing consider
  decomposing real service interfaces

39
deployment concerns

• if our enterprise were a collection of disparate
  services
• we could bring banks of replica services online
  and offline with minimal outage
• including carefully planned maintenance windows
  and ops support procedures
• solid LBFO policies also facilitate this
• we could partition banks of services across
  physical points of failure
• this is called maintaining continuity during
  changes

40
testing, rollback and continuity

• under the best testing conditions, defects
  sometimes get through
• in a continuity situation, you must be able to
  rollback a deployment very quickly
• you should also be able to roll forward your bug
  fixes as soon as possible
• again, your component contract standards can come
  to the rescue
• on the next slide, these standards can reduce
  deployment time to seconds or minutes, while
  preserving your ability to rollback

41
standards for obtaining continuity

• continuous integration
• reduces untested code collisions
• maintains the source repository in a
  production-ready state
• test-first and automated regression test
  harnesses
• quality starts at 100 and improves as the system
  evolves
• truth as we know it is captured and irrefutable
• automated build
• reduces deployment inconsistencies between code
  promotion states
• automated or one-line deploy and configuration,
  with rollback (uninstall)
• reduces or eliminates deployment and
  configuration errors

42
increasing stability

• if our enterprise were a collection of disparate
  services
• defects resulting in inconsistencies in one
  service should not cause other failures
• again, these are specified in the component
  contract
• requires rigorous exception handling standards
• requires clearly prescribed failure semantics on
  service interfaces
• often these semantics require ability for
  services to take themselves out of service
• alternatively, this could involve a solid
  monitoring interface
• service failures requiring restarting do not take
  other services offline
• this is called service isolation

43
isolation in practice
retry same or different service
service a
service b
service c
service d
what can service b do?
service d
service c
service d
service d
service e
44
an interesting observation exception handling
standards

• several .net standards espouse not using
  exceptions for valid alternative flows
• many Java standards prefer using exceptions to
  trigger important issues
• should you throw an exception for the following
• setting object properties with invalid data?
• attempting to login with the wrong password?
• overdrawing a checking account?
• exceeding your limit on cell phone minutes?

45
some additional exception handling ideas

• in our Java component contract, we specify these
  additional standards
• to eliminate a high percentage of silly errors
• methods returning collections should return empty
  collections rather than null
• methods returning objects should return a Null
  Object (pattern) rather than null
• to make troubleshooting easier
• follow strict logging rules when handling
  exceptions, and use log levels intelligently
• (we provide an example in a few slides)
• transform exceptions into the appropriate level
  of abstraction

46
special notes about Java RuntimeExceptions in EJBs

• unchecked RuntimeExceptions cause EJB containers
  to mark beans invalid
• this is a non-deterministic state
• the container cannot tell what it should do next
• remove/ejbRemove is not safe to call
• even the finalizer may be unsafe
• in most cases, vendors invalidate references to
  these beans
• they are orphaned without cleanup, producing
  potentially serious process resource problems ?

47
logging exceptions

• again, in our component contract we specify
  logging levels for different states in the
  exception cycle
• general logging is at a DEBUG level
• log interesting steps in processing at an INFO
  level
• when throwing an exception, log at a WARN level
• when catching an exception
• log at an ERROR level if it is unexpected and
  will propagate (or be transformed into a
  different exception type)
• log at a WARN level if it is handled

48
final notes on isolation
added

• isolation is made most simple when services are
  either
• stateless
• monitors can inspect and recreate any request and
  determine its intent
• easier to troubleshoot when something goes wrong
• easier to isolate a single service failure
• easier to recover from a partial service failure
• idempotent
• allows consumers to simply repeat any request if
  a single invocation fails

49
service building blocks

• if our enterprise were a collection of disparate
  services
• we could combine several finer-grained services
  into coarser-grained services
• often decisions about which services to combine
  are based on quality of service guarantees
• we could involve multiple intermediaries together
  in multi-party transactions
• this is called composability

50
an example of service composition
Account Management Service
Automated Renewal Service
Subscription Processing Service
Automated Cancellation Service
Merchant Service
51
an updated architecture
52
an alternative definition for composability
added

• Things should be made as simple as possible, but
  no simpler Albert Einstein
• a goal of web services standards is to preserve
  the clean, simple nature of web services, adding
  functionality on top
• SOAP does not proscribe any required headers
• standards allow adding headers for security,
  addressing, transactions, etc.

53
taking advantage of composability
added
WSDL
WSDL
consumer
service provider
message
data
WS-Policy
WS-Policy
WSDL
WSDL
message
consumer
service provider
security hdr
txn hdr
data
54
service refactoring

• if our enterprise were a collection of disparate
  services
• high-level services may be refactored into
  combinations of lower-level services
• this allows composability with other services as
  fundamental building blocks
• as in any other refactoring case, using test
  harnesses preserves semantic correctness
• this most often results in service services
  which would not be called on their own
• this is called decomposability

55
an example of decomposability
Audit Service
Account Management Service
Account Management Service
Authorization Service
Some Other Service
CRM Connector Service
56
physician, heal thyself

• if our enterprise were a collection of disparate
  services
• they should be able to figure out if they were
  sick
• they could be healthy, burdened, degraded or in a
  fault condition
• the service may provide industry-standard
  interface (SNMP) for COTS monitoring tools
• they could take definitive action based on their
  health
• a state machine for the service could identify
  what to do when an invalid state exists
• SOA infrastructure could redirect demand away
  from failing or degraded services
• coupled with location transparency, continuity
  and some quality of service measures, this is
  called self-healing

57
an engineering view of self-healing

• consider a controller for a stoplight
• it implements the patternRR-RG-RY-RR-GR-YR-
• where should it start when it first turn on?
• what would be most conservative?
• what do we (humans) do when all lights are off?
• what should it do if the pattern ever reaches GG?

58
monitoring guidelines

• in general, service interfaces should incorporate
  business and monitoring functionality
• interface SubscriptionService extends EJBObject,
• SubscriptionServiceBusiness,
  Instrumentation
• service implementations and clients should only
  invoke business methods
• security authorization measures can ensure
  appropriate semantics
• instrumentation interfaces provide hooks for
  management systems and service health metrics

59
instrumentation interfaces

• each instrumentation interface may provide the
  following
• a ternary indicator of general health - the
  service either performs as advertised, is unable
  to fulfill requests, or offers degraded service
• a method that performs complete regression test
  of service features
• regression tests should return detailed fault
  information and timing
• special precautions must be taken if these tests
  will execute in production (test customer
  numbers, credit card info, etc.)
• every effort should be exhausted to make these
  methods idempotent
• self-tests are not required to perform all
  functional or unit tests, but should be
  comprehensive enough to test service health
• standard monitoring agents may be layered over
  regression test methods to use timings and other
  results for indicators of degrading performance
• a typical component contract may specify a
  standard class to hold information such as
• an indication of pass/fail
• the elapsed time to complete the service test,
  from the service perspective
• a collection of exceptions encountered by the
  service test

60
transactions

• if our enterprise were a collection of disparate
  services
• transactional semantics would be guaranteed
  across any high-level service operation
• the trick here is in the presence of
  intermediaries, multi-party transactions and
  one-way invocations
• if there is no transactional guarantee, then an
  appropriate SLA must be published and agreed
• this is called service integrity

61
support for transactions
added

• the .net architecture supports using the DTC
  declaratively
• WebMethod(TransactionOptionTransactionOption.Req
  uiresNew)
• within the service implementation, use
  System.EnterpriseServices.ContextUtil.SetAbort()
  or SetComplete()
• in Java, transactions are supported declaratively
  in EJBs, but not in web applications
• this disparity highlights the need for an
  interoperable security mechanism
• WS-I defines transaction support as in the
  following slide

62
WS-I transactions
added

• WS-Coordination provides a coordination service
  as a web service, which
• generates XML coordination contexts passed as a
  header in participating messages
• the context contains the address of the service
• receiving parties that wish to participate can
  invoke the service to register
• starts and terminates transaction tasks
• allows participants to register in a task
• provides a callback interface for notifying
  registrants when the transaction is complete
• WS-AtomicTransaction extends WS-Coordination for
  distributed 2-phase commit
• WS-BusinessActivity implements long-running
  transaction protocols (with WS-SecureConversation)

63
reliability

• how do we ensure our message was ever delivered?
• how do we ensure our messages arrive in order?
• WS-ReliableMessaging
• unique message IDs and sequence numbers, again
  as SOAP headers
• allows retransmission and identification of
  duplicate messages
• allows vendors to implement reliability in their
  products (outside your code)
• like many other WS- specs, allow
  interoperability with proprietary messaging like
  MQ series or JMS

64
intermediaries
a typical e-business scenario
using intermediaries
send a complete order, with credit info to the
vendor and bank
send a complete order, with credit info
vendor
client
client
vendor
bank
proxy credit info to the bank
in this case, both parties receive the full
order, but XML Encryption ensures that the vendor
only sees the PO, and the bank only sees the
credit info
bank
65
a note on intermediaries

• web services promote an open, interoperable
  architecture
• the presence of intermediaries introduces serious
  security concerns
• this issue was not as prevalent when systems used
  proprietary protocols
• be careful that you do not think your SOA is
  secure just because your clients use SOAP/HTTPS
• nevertheless, this pattern could be very powerful
  for conducting b2b exchanges

66
security

• if our enterprise were a collection of disparate
  services
• they would satisfy enterprise security concerns
• obviously, intermediaries are a problem
• also consider
• how much of a channel should be open to each
  party in a multi-party transaction?
• how do you guarantee integrity and
  non-repudiation?
• what are the implications for authentication and
  authorization across multiple hops?
• what about trust?
• how much is enough, or too much, security?

67
security standards foundations
added

• WS-Security
• applies XML Signature and XML Encryption to SOAP
  format
• defines standard elements for optional headers in
  support of the standard
• WS-SecureConversation
• allows longer duration security conversations
  between consumer and provider
• validating security in each request is
  time-consuming
• using the same key repeatedly increases the
  chance of hacking

68
trust security standards
added

• WS-Trust
• the basis for all security is trust in some root
  Certificate Authority
• Security Token Service is a distinguished web
  service
• issues exchanges and assertions
• validates security tokens
• can federate X.509 and Kerberos, for example
• WS-Federation
• establishes virtual security domains between
  parties
• users authenticate against the domain
• incorporates WS-Trust and WS-SecureConversation
• supports member property space pseudonyms

69
yet more architecture
70
summary of added benefits

• discoverable, dynamically bound
• interoperable
• designed by contract
• location transparent
• loosely coupled
• coarse-grained
• understandable (cohesive)
• maintains continuity during change
• protection/isolation from propagating defects
• problem domain mapping

• self-contained, modular
• composable, reusable
• decomposable
• quality of service
• service-level agreements
• monitoring and self-healing
• available
• reliable
• accessible
• integrity (transactional)
• performance
• secure
• testable

71
overview ofstandards support
added

• WS-Addressing
• WS-Policy
• WS-Security
• WS-Trust
• WS-SecureConversation
• WS-Federation
• WS-ReliableMessaging
• WS-Coordination
• WS-AtomicTransaction
• WS-BusinessActivity

72
BPEL4WS
added

• future goals involve integrating even WS- specs
  into an even higher-level standard
• Business Process Execution Language for Web
  Services
• with WS-Policy, enhances describing high-level
  business operations
• composes web services in support of business
  processes
• allows hiding private helper services
• prescribes sequencing, activities and workflows
• defines variables for high-level processes

73
back to value management

• while everything is possible, not everything is
  necessarily valuable
• after carefully evaluating your situation, first
  steps may differ between companies
• some may see starting as an EAI problem
• some may carve out services for
  reverse-integration
• some may be planning ahead (beware the crystal
  ball)

74
conclusion

• pillar has several years experience advising,
  teaching and implementing SOA in CORBA, J2EE and
  .net
• the full benefits of SOA can be realized today
• however, they must be driven by business value
• simply using web services does not mean you have
  a SOA
• you may not even need SOA if you cannot determine
  where business value exists
• value management will help to identify the value
  of SOA and create an implementation plan

75
finally
added

• consider that the benefit of SOA is not simply
  the integration of enterprise apps, but the new
  efficiencies and possibilities that arise after
  having done so

76
QA

• Contact information
• Bob Myers (bmyers_at_pillartechnology.com)Regional
  Manager, Ohio Valley
• Chris Beale (cbeale_at_pillartechnology.com)
  Regional Manager, Great Lakes