Service Proforma
Middleware Workshop
Notes
• Please complete as much of this proforma as
possible – it will help make the workshop more
informative & productive for us all.
• If you will be talking about more than one service
feel free to add an overall architecture diagram
showing the relationship between services.
• Also, please provide a motivation slide for
developing/using the service set.
Service: Economic Services
• Web Services supporting pricing negotiation
and payment transfer
• Markets Project
• http://www.lesc.ic.ac.uk/markets
• <SOA Model:WS>
Service Operations NegotiationPortType
• GetNegotiationDomain
– Description:
– IN: extensibility type
– OUT: list of negotiable terms and their initial
domain
Service Operations NegotiationPortType
• Negotiate
– Description:
– IN: Constraints Document representing the
proposal
– OUT: Constraints Document representing the
counter-proposal
Service Operations NegotiationPortType
• Commit
– Description:
– IN: Constraints Document representing the
final proposal
– OUT: Signed Constraints Document
representing the agreement
Service Operations PaymentProviderPortType
• GetPaymentSystem
– Description:
– IN: None
– OUT: Document representing the set of
supported payment system
Service Operations PaymentProviderPortType
• verifyUserTransaction
– Description:
– IN: user information
– OUT: return a signed proof that the
PaymentProvider can verify the user identity
Service Operations PaymentProviderPortType
• AuthoriseTransaction
– Description:
– IN: TransactionDetails
– OUT: Transaction Code
Service Operations PaymentProviderPortType
• CompleteTransaction
– Description:
– IN: TransactionCode obtained from
AuthoriseTransaction
– OUT: None
– Faults: InsufficientFund, SignatureFailed, etc..
What do you use to build your service?
(i.e. How ‘standard’ is your service?)
NB:A low score means less risk & more mainstream
•
Widely Implemented Standard Specification (1pt)
– <Demonstrable Multiple Implementations, e.g. SOAP, WSDL>
•
Implemented draft specification (2pt)
– <Specification in standards body and supported by most/many companies. One/few
implementations exist (e.g., WS-Security, BPEL)>
•
•
•
Implemented draft specification (3pt)
– <Specification in standards body but alternatives exist. Industry is divided. One/few
implementations exist. (e.g., Transactions, coordination, notification, etc.).
Implemented proposal (4pt)
– An implementation of an idea, a proposal but not submitted to standards body yet (e.g.,
WS-Addressing, WS-Trust, etc.)
Non-implemented proposal (5pt)
– <An idea that exits as a white paper, but no code and no specification details>
•
Concept (6pt)
– <An idea that exists only as power point slides!!>
•
TOTAL: (SOAP, WSDL, XML-Signature, XML-Encryption) = 1, (WS-Security)=2. Total = 3
Service Dependencies
• What else does your service depend on (i.e.
external dependencies)?
– RDBMs - transaction record
– Logging
• What does your implementation depend on?
– Java J2EE
– Sun J2EE Appserver v.8
AAA & Security
• What authentication mechanism do you use?
– Bespoke? From the infrastructure?
• What authorisation mechanism do you use?
– Gridmap file, CAS, From service or infrastructure?
• What accounting mechanism do you use?
– Is interaction audited? Is usage run against quotas?
• Does service interaction need to be encrypted?
• If these are not used now, will they be in the future?
Exploiting the Service Architecture
• What features from your ‘plumbing’ do you
use in your service?
Service Activity
•
•
•
•
Multiple interaction or single user?
Throughput (1/per day or 100/per second?)
Typical data volume moved in
Typical data volume moved out
Service Failure
• Required Reliability
– Failure semantics?
• Positive ack
• Required Persistence
– Transaction persistence
• Required Availability
– One of many or unique requirement
Required Service Management
• Remote access to:
– Performance
– Progress
– Diagnostic and repair interfaces