Skip to content

Core Services

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 - DomainRepository - QueryService - Stable long term contracts Code-Patterns for Core Services - Enterprise Domain Repository Pattern - Evolving Service Endpoint Pattern - Recording Command Pattern - Recording Proxy Pattern - Smart Service Proxy Pattern --- 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

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. |