CS

Core Services

Core Services
Core Services is basically data services. Typically they evolve to become the master repository for the most important business objects in the enterprise. Typical examples are Customer and Product. You will also find that it often makes sense to split a service for a domain object into a CRUD (master) service and a accompanying Query Service to keep the complexity to a manageable level, and to allow a more feature rich query interface.

Characteristics

Data access services
Domain object repositories
- SOA as an integration strategy
- Single repository of domain objects
- Decoupling the client from persistence technology and strategy
Granularity
- <MyDomainObject>DomainRepository
- <MyDomainObject>QueryService
Stable long term contracts

Code-Patterns for Core Services

Technology/Implementation strategy (Java)

Technology

Code-centric ESB/integration products (connectors & mapping)
Space-Oriented Architecture
EDA products
Open-ended mapping of Core Domain Objects and Integrated Applications

Implementation and products

Java code
Use mobile code if you can
- XML/XSLT mappings
- Jini/ JavaSpaces
Repository with code-centric integration products
- OpenESB/Glassfish
- Mule
- Esper (EDA)

Technology/Implementation strategy (.NET)

Technology

.NET 1.0/2.0 ASMX
.NET Remoting
Windows Communication Foundation (WCF)
IIS Hosted
Windows service / Self-hosted
In-process

Implementation and products

.NET code
BizTalk orchestrations can do a good job for mapping and high throughput

Design Rules

P1. A service shall have one named owner	P2. A service shall provide documented business value	P20. All services shall be in the service universe	P21. A service shall be categorized (OW SOA category)	P22. A service shall have an "authentication, authorisation, endpoint strategy"
P23. A service shall document its Service Level Agreement SLA (response time, availabillity++)	P3. A service shall do one only thing, and one thing well	P30. A service shall have a versioning strategy (ACS, CS)	P30. A service shall have a versioning strategy (ACS, CS)	P31. A service shall provide for audit and monitoring of service usage
P31. A service shall provide for audit and monitoring of service usage	P32. A service shall document its Service Level Agreement SLA (response time=30ms, availability=99.995%)	P32. A service shall document its Service Level Agreement SLA (response time=30ms, availabillity=99.995%)	P40. A service shall provide at least one Evolving Service Endpoint	P40. A service shall provide at least one Evolving Service Endpoint
P41. A service shall provide heartbeat and traffic monitoring	P42. A Core service shall have orthogonal functionality	P42. A Core service shall have orthogonal functionality	P90. A service shall have a documented coupling to the contractual and requirement for service usage

Design-time Governance for CS

Other technical details

Focused on getting an agile architecture to support both the complexity in today's deliverance and infrastructure, and also to build a platform that will give faster time-to-market than the competitors. Central in this architecture lays the concept of Master strategy. Per today the following central domain objects have been planned implemented using the master-service-strategy:

CustomerMaster (including customer relation an contact persons)
ProductMaster (including mastering of instantiated products/services towards ordering and delivery track)
ServiceMaster (both CustomerFacing and ResourceFacing - technical building blocks that connects product to resource/provisioning)
ResourceMaster (management and control on all components in the infrastructure that there will be an shortage off/expense to scale further)

The Master strategy works like this:
A Master-Service is established and made available for all systems in our enterprise

The Master-Service has the responsibility to collect and aggregate master-domain-objects across the under laying systems
The Master-Service will master merging of elements in e.g. customer objects on the field level, based on a rule set of which changes are allowed in the different systems (a contact person with invoicing responsibility is 'owned' by the order system, and will not be updated by a mistake by the portal or the CRM system).
The Master-Service can be expanded with its own persistence/storing to make sure of optimal uptime, so SLA will not be impaired if one or several of the systems falls out.
The Master-Service will establish triggers in the different systems, and will there for detect by them self out-of-bounds updates and merge this by applying the same rule set as described above.

See EDR and EDR-MDS for more in-depth of the mastering strategies.

CS