GIGX Options Chart
A great introduction to Mobile Push over the most common networks (Apple, Android, Windows, Blackberry) by Mike Willbanks.
Using Aspects in a Service Pipeline
Here is a diagram of how a service pipeline works with aspects applied. Basically a method (service operation) is invoked on an interface (service contract), that is mapped (via IOC) to a concrete implementation which derives form a base service class which has aspects applied to it. The implementation that derives from the base service class only needs to focus on implementing the business logic for providing a response to a give request. All other concerns can be handled by the base service(s), as show in this sequence diagram by the application of aspects at various levels of abstraction.
When developing secure services you often have the requirement to support transport, message, or both encryption schemes. Transport encyption is encyption of the data that flows over a connection (typically between a client and a web server endpoint). This is usually enabled by using TLS/SSL.
Message encryption goes beyond encryption provided by transport. It actually encrypts the payload in the message. If you using SOAP services, this would be the message body. The SOAP headers however can be kept unencrypted if they are needed for routing purposes, etc.
Message level encryption helps protect against a man-in-the-middle attack, where someone might compromise the transport security and be able to look at the messages - all they would see is an encrypted message. It also helps protects against inspection of the message one it reaches the application process (after offloaded from the web server). There is a small performance hit because all messages have to be encrypted and decrypted before they can be used. Of course once the message is finally unencypted it can be viewed, but that’s more of a application security concern.
“Most of the technology involved in the web, like the hypertext, like the Internet, multifont text objects, had all been designed already. I just had to put them together. It was a step of generalising, going to a higher level of abstraction, thinking about all the documentation systems out there as being possibly part of a larger imaginary documentation system.”
Tim Berners-Lee
How to cache service responses
Is your system slow because of all the service calls you are making to other systems? Have you considered caching some of the responses from these calls? If you don’t actually need to get a fresh response for each call, then you should probably be caching the responses. This should both increase your performance while at the same time taking load off the 3rd party service. See model above for the basic pattern to implement.
The Challenge
Today system integration often requires mapping identities between systems. System A usually has a different way of representing an identity than system B. Further system C could be different than A and B both. If system A wants to talk “in a specific identity context” with system B, then a identity translation has to happen. This article aims to provide a model and processing context to address this scenario.
First we’ll define a model for representing relationships between identities on various systems. Then we’ll populate our model with some instance data to see how the model can be used to resolve identities from one system to another. Finally we’ll discuss some aspects of implementing the model in a processing context.
Identity Mapping Model
Graphic View
Table View
The Identity is a class meant to be sub classed by more specific types of identities. This means a Remote Deposit ID is a specialization of Identity, specifically for a Remote Deposit system. Likewise an Online Banking ID is a specialization of an Identity, specifically for an Online Banking System.
The ID Maps To property is meant to represent mappings between different Identities. This property is a specialization of the Maps To property, which is a generic base property for representing transitive mapping between resources. This property allows us to ask questions like “given identity r on system q, what is the equivalent representation of this identity on system x”?
The transitive aspect of the Maps To property means we don’t have to write direct assertions between systems q and x. If there is a Maps To relationship between q and b and another Maps To relationship between b and x, when we can infer that q and x are equivalent - because they are related through the transitive Maps To property.
In this example we are only focusing on mapping identities, but we could easily extend this model to include other mapping concepts, like account mapping. We could introduce a new property called Account Maps To, with a domain and range of Account. Because the Account Maps To property is a sub property of the Maps To property it would inherit the transitive aspect of the parent property. This would allow us to ask our model something like “given account x on system a, what is the equivalent representation of this account on system g”?
Identity Mapping Sample Instance Data
Graphic View
Table View
In this example we show that U389JP is a Mobile Banking ID that ID Maps To 3827-03KD-3903KKS9, an Online Banking ID. That online banking ID in turn maps to other Identity types on various systems. Because the Maps To property is transitive we can infer that the Person to Person Payment ID of P2P778UXB is equivalent to the Mobile Banking ID of U389JP. This means we can infer Identities on other systems, without knowing a direct relationship ahead of time.
Building The Graph
The example inferences above only work if the assertions in the graph are populated enough to make an inference. Let’s consider the scenario where the assertion graph needs to be dynamically loaded as part of a banking session. The first system to interact with the graph would load assertions it was aware of, perhaps the Mobile system would assert a relationship between it’s ID and the Online Banking system. At that point the Online Banking system could load relationships it’s aware of, like identity mappings to a Remote Deposit system for example. This pattern of “load the relationships your system knows about” would apply for each system represented by the graph.
The loading of the assertions could be lazy, meaning a assertion provider pattern could be put in place to only get assertions if a query including a given system is executed. This means you would only load assertions related to the Remote Deposit system if a query is asking to resolve a Remote Deposit ID. This assertion provider pattern could be abstracted into an interface that could be invoked on demand in process.
The graph itself could be based in memory and each assertion can have it’s own time to live (or cache timeout), just like DNS. This model is in someways analogous to the DNS system.
Where system System A might be a root name server, and System B might be a top level delegated subzone. Each “zone of authority” only knows about relationships it has with direct peers, but when chained together one can infer an IP address based off a domain name. The same concept applies with the above model, where each system only knows about it’s relationships with direct peers, but when chained together one can infer an identity on system X based off an identity on system R.
Conclusion
In this article we looked at a conceptual model for mapping identities between systems as well as some guidance for implementing the model in a processing context. This should give you a way to simplify the mapping aspects of your system integration challenges by allowing systems to focus on what they know, while leveraging models to make inferences between external systems.
In a previous post I showed how you can generate service contracts using XSLT with a visual studio template. I have since then posted the XSLT files online so you no longer need to use a VS template. Instead just make a XML file using the following format: http://macrowebservices.com/codegen/ContractDefinition.xml
Just modify the above XML to use your companies XML and CLR namespaces.
Next you can run your contract definition through 2 different XSLT scripts:
- This one will generate the C# partial classes/interfaces, base classes, etc. http://macrowebservices.com/codegen/ContractGenerator.xslt
- This one will generate documentation for your contract. You will need to update the XSLT to use your companies domain names, etc. http://macrowebservices.com/codegen/ContractDocumentor.xslt
Now you simply run your ContractDefinition.xml file through the above scripts and start implementing the other partial parts of your contract (the parts that only a human can do).
You can use W3C’s online based XSLT transformer.
- Click here to generate the C# source code. View the source, then copy the C# code into your VS project.
- Click here to generate the contract documentation (HTML).
Service Versioning Flowchart
When developing a service contract, you often run into questions like:
- Should a new function be put into an existing operation or should I make a new operation?
- Should I create a new contract interface for a new operation or should I add the operation to an existing contract interface?
- If I add a new property will it break existing users of the service.
Here is a quick and easy template for deciding what to do based on any of the following above scenarios.
This flowchart was developed by Craig McMurtry, for versioning WCF services.
