impact 2008 1994a - exposing services people want to consume: a model-driven approach

© 2008 IBM Corporation

Brian M. Petrini WebSphere Business Integration Architect Kim Clark WebSphere Business Integration Specialist TBP-1994

Exposing services people want to consume Model-driven SOA implementation

© 2008 IBM Corporation 2

Outline •  What makes a service consumable? – service provider meets the

requirements (both functional and non-functional) of the service consumer

•  Problems with services today

•  Principles of SOA (published - multiple consumers)

•  Identify initial consumers (must be more than 1)

•  Identify consumers requirements (ISO 9126 – qualities of software) – Explain ISO 9126: Functionality, Reliability, Usability, Efficiency, Maintainability,

Portability (having difficulty putting these in perspective of interface vs. implementation)

•  Doesn’t meet? Is it mediatable? Can a composite service be created?

•  Summary


Problems with current services

Custom built (single consumer)

Can’t identify if a service will meet all of the functional and nonfunctional requirements

Many behaviors not defined – i.e. error handling

Not scalable

Doesn’t do exactly what I need

Who pays?


Solution Context Diagram with Integration Detail

Process Order Billing

System

Data Warehouse

Credit Checking

Shipping

Product Catalogue Order

Management

Printing

Order (JDBC)

Customer/Credit Rating (Web Service/HTTP)

Order Confirmation (Web service/JMS)

Order Summary (JDBC)

Customer/Order (Flat file, batch)

Customer/Order (Flat file, XML)

Product Details (RMI/IIOP)

Order Details (MQ Series)

1

2 3

4

5

8 6

7 9

Customer Relationship Managemen

t

Customer Relationship Management


Interface Characteristics

•  Interaction type •  Transport •  Protocols •  Data formats •  Principal data objects •  Re-usability •  Reliability •  Availability •  Volumes

•  Time windows •  Response times •  Service level agreements •  Message size •  Throughput •  Batch or real-time •  Data Ownership •  Privacy •  Integrity


Qualities of Software •  Meeting the functional and non functional requirements1 of an enterprise application is inherently

complex:

•  Let’s take a quick look at how the code “evolves” when these additional requirements are considered…

1 From ISO 9126 Software Characteristics

Transactional Request Functional

Efficient

Enterprise Solution

(Services)

User Session

Business Process

Runtime Resource

Application Component

Standard Platform

Design focus

Requirement focus1


Functionality requirements… •  Action performed or data retrieved – both normal and functional error conditions

–  Operation Name –  Parent Interface Name –  Interaction Type –  Request Message –  Response Message

•  Error conditions –  Fault Message –  Idempotent –  Error Resolution [offline|online]


Reliability requirements…

•  How often does the function complete normally –  Assured Delivery –  Stateful –  Transactional –  Potential Participant –  Availability –  downtimeProfile


Usability requirements…

•  How easy is it to invoke the service –  Data Format –  Protocol –  Transport


Efficiency requirements

•  Use of resources (time, processor, memory, IO, storage, cost) –  Request Rate Capacity –  Response Time Average –  Response Time Profile –  Maximum Message Size –  Interaction Cost


Maintainability requirements –the bad…

•  A homegrown (proprietary) runtime framework requires tooling for:

–  Development and unit testing of each component –  Configuration of an end-to-end functional application –  Functional verification testing and debugging –  Deployment into system test or production environments –  Operations, including admin, monitoring, debugging and tuning –  Must build documentation and training program for each role

•  Building a proprietary framework puts your programmers in the middleware business!

–  Takes time and attention away from developing the mission critical applications


Portability requirements –the good •  Use standards from organizations like ISO, OMG, W3C, & Sun to support

multiple platforms and keep your team out of the middleware business: –  DHTML/JavaScript for web pages that execute on browsers –  Java for write once run anywhere logic components –  HTTP Servlets for Java components controlling dynamic web content –  Java ServerPages for scripting page layout –  JNDI for managing the namespace –  JTA for transaction management –  Session EJBs for distribution –  Entity EJBs, JDBC or SQLJ for persistence –  JMS and Message Driven EJBs for asynchronous programming –  JCA for connectivity to arbitrary back end logic and data access


Service Level Agreement Definitions •  Operational (Availablity, Reliability) •  OperationDefinition •  operationName •  parentInterfaceName •  interactionType •  assuredDelivery •  isStateful •  isIdempotent •  isTransactional •  isCallableConcurrently •  isPotentialParticipant •  dataFormat •  protocol •  transport •  requestStructure •  responseStructure •  averageMessageSize •  maximumMessageSize •  sequencePreservation or invocationIsolation •  errorResolution [offline|online] •  interactionCost

ExpositionDefinition serviceDomain

ExpositionPolicy (aka “Service Level Agreement”)

reliability

availability

downtimeProfile

requestRateCapacity

responseTimeAverage

responseTimeProfile

AuditingPolicy

SecurityPolicy


Service Exposure Characteristics - candidates for registry meta-data

•  Soft attributes – ID – Short name – Description of service – Description of operations – Expected re-usability

•  How do I use it? – Interaction type – Transport – Protocols – Data formats – Principal data objects – Physical Address – Validation – Error responses

•  Service level agreements – Response times – Expected processing time. – Reliability – Availability – Downtime windows

•  Governance – Consumers/subscribers – Versioning strategy – Notification strategy – Ownership – Privacy


Solution View

<<component>>

<<component>>

<<component>>

<<component>>

<<component>>

<<component>>

solution context boundary

<<actor>>

<<actor>>

<<actor>>

<<component>>

Consumer and provider of traditional interface

Consumer and provider of an Enterprise Service interface


Service Dependency Model

•  Shows the expected consumers of each service (if known), and any inter-dependencies between services

•  Shows only the relevant dependencies for a given solution, not all dependencies for all solutions

•  Notes any hierarchical “tiers” in the service model •  Provides the service boundaries to contain the effects of within-service

changes •  Often necessary to show dependencies at service operation level rather than

service level (not shown above).

AccountService

AddressService

DocumentPreparationService

QuotationService

CustomerService ProductTypeAService

ProductTypeBService

Utility Services Generic Business Services Specific Business Services Other consumers

Customer facing application

Call centre application

Business support application

CreditVettingService

Batch fed application PaymentService

CardNumberValidationService


Summary


Silo Services Composite

Services Virtualized Services

Dynamically Re-Configurable

Services Componentized Integrated

Level 1 Level 4 Level 5 Level 6 Level 7 Level 3 Level 2

Applications

Methods

Organization

Infrastructure

Architecture

Business View

Modules Services Process

Integration via Services

Dynamic Application Assembly

Components Objects

Structured Analysis &

Design

Service Oriented Modeling


Grammar Oriented Modeling

Component Based

Development

Object Oriented Modeling

Ad hoc IT Governance

Emerging SOA Governance

SOA and IT Governance Alignment






Process Integration

via Services

Platform Specific

Platform Specific

Platform Neutral

Dynamic Sense & Respond

Platform Specific

Platform Specific

Monolithic Architecture

Emerging SOA Grid Enabled SOA

Dynamically Re-Configurable Architecture

Component Architecture

Layered Architecture SOA

Platform Specific

Function Oriented

Service Oriented

Service Oriented

Service Oriented

Function Oriented

Function Oriented

Service Oriented

Service Integration Maturity Model (SIMM)


Example integration challenges •  The service must appear event driven, but

actually is a batch process on the back end •  We can only make 10 requests per hour to

the back end, but can contain as many events in a single request as you like.

•  Connection pooling is required but we want to preserve the identity of the caller

•  The data format is “similar” to Comma Separated Values

•  We don’t know what the request is until we inspect various aspects of the message header and body. In some cases even the data format is unknown at this stage.

•  Due to optimistic locking, the backend system requires the exact timestamp/rowid that was returned in the retrieve at the beginning of the business process.

•  The backend system is often not available. Retries should happen automatically and should not be considered an error condition.

•  We must never call the back end system when it is down. The availability of the backend system can be determined by the xxx function call.

•  We have written our own security mechanism

•  For testing, we need to be able to wire in our (proprietary) test harness mechanism

•  Any changes to code require a lengthy validation process. We want everything possible to be configurable.

•  We used powerful features of XML Schema in definition of our object model.

•  We have our own integration framework. Most of the work is done by a few common classes and applications. New services are added via configuration rather than code.

•  The adapter was missing one feature that we needed, so we’ve decided to integrate using custom code instead.

•  We only want to send the changes/deltas to the back end system, not the whole original message

We can only make 10 requests per hour to the back end, but can contain as many events in a single request as you like.

The backend system is often not available. Retries should happen automatically and should not be considered an error condition.

Due to optimistic locking, the backend system requires the exact timestamp/rowid that was returned in the retrieve at the beginning of the business process.


iSeries Integration – Options! 1.  Launching 5250 screen 2.  Web page using HATS 3.  Portlet using HATS portlets 4.  Web page using IBM WebFacing Tool 5.  Web service via HATS 6.  Web service using WAS on iSeries 7.  Web service using IBM WebFacing Tool 8.  JavaBean/Web service via WAS through JT400/JTOpen 9.  JavaBean/Web service via ESB through JT400/JTOpen 10. Web service via ESB via iSeries Adapter using RPG call 11. Web service via ESB via iSeries Adapter using Data Queue calls 12. MQ/XML to an RPG proxy. 13. WebService via ESB, via MQ/XML to RPG proxy. 14. JDBC stored procedure through WESB using JDBC adapter. 15. JDBC "events" using JDBC adapter. 16. JDBC stored procedure calls directly from WAS 17. JDBC views through WESB using JDBC adapter 18. JDBC views directly from WAS 19. Expose RPG directly as a web service using iSeries administration

facilities (new in 2007/8) 20. Expose RPG directly as a web service via iSeries administration facilities

(new in 2007/8) and front with ESB.

Design is about understanding the key characteristics of the problem, and matching those with the technical capabilities at hand.


Zone: Enterprise Service Bus

<Service Consumer>

<Service Provider>

<Service Provider>

<Service Provider>

Connector

<Service Consumer>

<Service Consumer>

Evolving integration architecture

Connector

Hub

ESB G

ateway

Integrated Level 2

Services Level 4

Service Registry

<Service Provider>

<Service Consumer>

Connector

Connector Connector

Connector

Componentized Level 3


© IBM Corporation 2008. All Rights Reserved.

The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising

out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the

amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. The following are trademarks of the International Business Machines Corporation in the United States and/or other countries. For a complete list of IBM trademarks, see www.ibm.com/legal/copytrade.shtml AIX, CICS, CICSPlex, DB2, DB2 Universal Database, i5/OS, IBM, the IBM logo, IMS, iSeries, Lotus, OMEGAMON, OS/390, Parallel Sysplex, pureXML, Rational, RCAF, Redbooks, Sametime, Smart SOA, System i, System i5, System z , Tivoli, WebSphere, and z/OS. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

impact 2008 1994a - exposing services people want to consume: a model-driven approach

Software

ibm corporation brian

reliability requirements

usability requirements

efficiency requirements

consumers requirements

additional requirements

nonfunctional requirements

service provider