This is a rather cryptic report on the 2001 designfest group, in the
tuesday full-day session, that worked on the flextier problem. Except
for me all the guys had a first name starting with an "A", and the
girls where colleagues.
- Deliveries are within the context of the Mobile Telephone Network Operators. But the larger purpose is to extend the solution to go across other domains.
- Customers are persons, instead of entities or companies.
There are 2 actors - top and bottom; so how to make flexible?
Missing authentication and validation.
What does flexible mean?
Is easy to change individual service must not change service API?
API is extendible?
Easy to add services?
from the Presentation Tier
- Customer Representative
- Service Configuration
- Legacy Systems
- ** No time based actors
- ** No external Systems
- Create Customer
- Maintain Customer
- Maintain Contract
- Search Customer
- Add Contract
- Customer Address validation
- Blacklist Validation
- Define current services
Create configuration file
- start service
- start all services
- stop service
- stop all services
- System presents services
- Actor chooses appropriate service
- Actor defines service sequence
- To store information about a service
- Be available to be called
- Know its properties
- Apply its properties to its behavior??
- Manipulate its properties
- Service set
- To group a number of services together that creates some sort of domain or module?
- Also to be able to know the order of service invocation (which is kind of business rule in itself?)
- To be able to be called just like a simple services (and the presentation tier isn't aware of it)
- Lists services that make up a certain set or domain
- Order the services
- Just about all other candidates (customer, contract, blacklist)
- Hold client data
- Validate input/output
- Know representation?
- Service Set
- Hold address data
- Validate io
- Know representation
- This candidate keeps or maintains all information about blacklists
- Creates an empty blacklist
- searches for a customer in the blacklist. Equality is by value
- Delete customer blacklist, delete customer from blacklist
- Retrieves how many elements the blacklist has
- Confirms whether a blacklist is empty
- Confirms whether the customer is in the blacklist or not
- Adds elements (customers) to blacklist, no repetitions allowed
- Gets the reason of why the customer is in the blacklist.
- Customer (either identified by customer id or the whole customer object)
- Reason (is it a class or property?)
- Is history something that is required, i.e. was this customer in the blacklist before?
- Contains information about what kind of features are available for the "customer" and what the responsibilities of the customer are
- Contracts for the customers are to be accessible through services (?)
- Defines the phone numbe (ID)
- Constraint: has to be created before added to the customer
- Service (?)
Calling the GetProperties method brings up a complexity concerning the mapping of properties to services. The issue is: Are you calling GetProperties for a hierarchy of services, or are you calling GetProperties as you traverse the hierarchy of services.
Service Specification annotation:
If we make it that flexible, it knows what kind of information
it needs (because it does the lookup). The issue is that we
don't pass any parameters to it, because again it is THAT
The ice-cream presentation