Recently started the Oracle program: Are You The Smartest.
For me it is an opportunity to test my current knowledge level and to extend my knowledge.
After every session I follow, I will write a brief summary as part of the preparation for the test.
I also follow some of the 2012 sessions. These sessions are not part of the test.
I will continue with the summary of the following session.
ARCHITECTS TRAINING – SERVICE INTEGRATION – Oracle’s Approach to SOA (by Jeff Davies) – Guiding and Accelerating SOA Success.
This session (not part of the tests) was divided into the following three parts.
- Service Landscape (90 minutes)
- SOA and BPM Suite (20 minutes)
- Service Versioning (30 minutes)
Service Landscape
In the presentation 7 questions are answered. The questions and answers are listed below.
Q1: At what level of granularity should I write my services?
A1: At all levels. Part of the discussion is loosely versus tight coupling. But this is not really an operational thing. Nobody chooses this on purpose.
Q2: I have 500+ services in production, not one of them is reused. Why? What happened?
A2: Have the possibility to find it. Otherwise you can’t reuse it. Or you created highly specialized services that could not be reused. You lack the tools to manage the problem space at scale (Governance suite)
Q3: How do you draw SOA?
A3: using the Service Landscape notation
Q4: How do I move from a point-to-point architecture to SOA?
A4: Use the Service Landscape technique as a guide for organizing and planning your services.
Q5: How do I avoid merely service enabling my existing point-to-point architecture?
A5: Know the difference between SOI and SOA. Use Service Landscape to perform SOI only in the context of an overall SOA goal.
Q6: Do I need to rewrite my enterprise to achieve SOA?
A6: no. you leverage your existing p2p integrations and only creating services when and where they make sense.
Q7: How does SOA align my IT with my business?
A7: by creating an explicit set of services that focus solely on achieving business objectives without the constraints of individual applications blocking the way.
Business Agility
The characteristic of a business being able to change rapidly, adapting to changes in its business environment.
Requires three enablers:
- Standards (Components can be composed if they provide standard interfaces and have little or no technical knowledge about each other).
- Composition (Begin with reusable core business functions, Compose them into higher level business processes).
- Abstraction (Abstraction allows human beings to deal with complex systems in simple, familiar, describable ways).
Software Patterns in Applications
These patterns represent best practices for solving common problems in software design common problems in software design.
- Facade Pattern (Hides the complexity on the underlying subsystems by providing a simplified interface).
- Adapter Pattern (Adapts interfaces of existing systems to “standardized” interfaces).
- Abstract Factory Pattern (Used to create “families” of related classes).
- Observer (Monitors objects for changes -think events).
- Singleton (Used to represent objects with a single instance).
- Command (Encapsulates invocations)
- Template Method (Generalizes algorithms, making them selectable at run time)
- Iterator (Selects objects one at a time).
- Composite (Build functionality by aggregation/composition of smaller objects and classes)
- State (Alter behavior when an internal state changes based on well defined rules).
There is one dominant pattern in architecture today: Point-to-Point.
If the enterprise is the application, why don’t we build our enterprise architectures as well as we build our applications? Where are the patterns?
The Service Landscape Technique
On the vertical ax the Service Landscape Abstraction is used.
Defining the Abstraction Layers
- Enterprise Services – Implement the core functions of the business that will always maintain no matter how often the implementation changes. This is the most logical of all service layers: highly aligned with business purpose, very little technical detail.
- Business Services – Lower level services business services that are composed into the Enterprise services. Builds on the Technical layer. Acts as a façade over geographic and business unit distinctions. Services here still, “make sense” to business people.
- Technical – The lowest level of functional capability that you control. Often application specific. Always highly technical
- Applications – This is the software applications and systems layer. External services like SalesForce.com or COTS software packages like SAP and Siebel. Also includes software that you have developed that is not service enabled.
On the horizontal ax the Business Domains are used (don’t do this on people locations because it’s not change prove).
Putting these axes together results in the Service Landscape Coordinate System.
The following pictures shows an example of this, including the use of naming conventions on each level.
Logical SOA
Communication Principles
- Each service layer “knows” about the layer below it.
- Service calls are routed to the appropriate sub layer
- Domain services have no knowledge about peer domains.
- Every layer/component/application is allowed access the Enterprise Layer
- Services that cross functional group boundaries are always Enterprise services
- Web Services are used at the Enterprise and Business service layers
- Enables a rationalized monitoring strategy
- Promotes re-use
- Provides an enterprise standard for high level integration
- A Business Domain exists to categorize our services.
- Similarly, abstraction layers are another form of service categorization.
- Enterprise level services orchestrate and aggregate the Business level services.
- Business level services orchestrate and aggregate Technical services.
- Technical services exist to service enable applications (or parts of an application) in a manner that we control.
- Technical services in different Business Domains can access the same application. Each would publish a different aspect of that application’s functionality, according to functional group.
- ETL, Data-Cubes and Data Mines are always considered a Application level, but the information they provide can be service enabled via Technical services.
- Any application/service/shell script can access the Enterprise layer.
SOA is not OO
Loosely coupling
Every level has it’s own WSDL and XSD. Do not copy them from another level. This creats a tight coupling. Use a transformation between them.
e.g. every application could have a different definition for ‘Customer’. On a Business or enterprise level the all share a common definition.
SOI versus SOA
Service Oriented Integration
- Focused on addressing the immediate integration needs
- No long-term vision / strategy
- Uses web services for interfaces
- Results in Service Enabled Point-to-Point architecture
Service Oriented Architecture
- Focused on meeting business needs
- Integration is a part of an overall strategy
- Uses web services for interfaces
- Results in true, sustainable architecture.
- Enables the business to change naturally Enables the business to change naturally
The Complete Technique
- Distill the business requirement
- Derive the logical service architecture
- Perform the service analysis
- Define the process
- Add the service overlay
- Add the technology overlay
- Derive the physical service architecture
- Derive the component service list
- Derive the logical deployment diagram
- Derive the physical deployment diagram
SOA and BPM Suite
This presentation was the marketing story about the SOA suite, the BPM suite and how these tools work together.
Service Versioning
In the presentation the question ‘How do I version a service’ is answered.
Changes to physical location
The URI doesn’t change because we use either DNS or Oracle Service Bus to resolve the physical address.
Changes to the service implementation
Non-functional code change (e.g. comment). Bug Fix. Functional code change.
Service vs. Implementation
While it is important to manage changes in the source code, those changes are managed separately from the service definition. From that simple fact we can draw a broader conclusion:
- The service and its implementation are completely separate and must be managed separately.
- Changes to an implementation file are managed by traditional source code control systems.
Therefore: Implementation is NOT a part of the service!
Changes to the WSDL
- Changes to operational arguments
- Changes to operational return values
- Adding operation
- Deleting operations
- Changing namespaces
If the change affects existing clients, then you either update all clients for a simultaneous release with the changed service, or you create a new service to run in parallel with the original service.
Changing the URI means changing the service, but its not a new version, its really a new service.
Concurrently Running Services
There is no need to “version these services. Its easier to treat them as separate services, completely independent of each other.
Adding a field to contain a version number provides no value at all.
The “deprecates” relationship between the services is best handled by an SOA Governance tool and not a version number in the service itself. Such a tool would best handled by an SOA Governance tool and not a version number in the service itself. Such a tool would also manage other important information about the deprecated service, such as expected retirement date and a link to the newer service that supersedes the deprecated service.
Conclusions
There is no point or benefit to ever embed a version identifier in a WSDL or as an operation in the web service itself.
It is far simpler and more productive to treat any change that affects a service consumer as being an entirely new service.
Use tools like the SOA Governance Suite to manage the deprecated / supercedes relationship and all of the Use tools like the SOA Governance Suite to manage the deprecated / supercedes relationship and all of the other important meta data.
A service is changed only if it requires the service consumer to change. If your local power company changes the source of your electrical service tomorrow from hydroelectric to coal, nuclear or geothermal, they have not changed your electrical service, merely their implementation details.
