...
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
When Things Appear To Get Out Of Control
Let’s look at a stack run wild. Even with our shared connection pool, each layer will checkout and close the SQL connection (up to 5 times in the illustration below). Some connection pools are not very efficient and may have their own conversation with the database just to check if things are still OK from a few milliseconds ago.
| Gliffy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Let’s look at some possible remedies.
Use a Really Fast Connection Pool
Transactions
Aside: When Does Separation Of Concerns Warrant A New OSID Provider?
It may be tempting to build a lot of distinct OSID Providers to separate concerns within an OSID Provider. The top-level OSID Consumer only cares about the entire service. Programmers tend to care more about micro-separation of concerns. These concerns can be separated without going through an OSID boundary where the implementation details of the underlying OSID Providers become opaque.
This is not to say that we should go completely the other way and build monolithic OSID Providers. The trade-off involves asking the question if anyone other than the programmer cares. In other words, using layering techniques are great, but it is a separate decision to surface every layer as its own OSID Provider managed independently in the OSID Runtime. Here are some things to think about.
Is The Provider The Same?
We always use the term OSID Provider, not OSID implementation. The term provider is found in osid.OsidManager identified by an Id. If I am providing you a complete service, I am responsible for all parts of it. How I sort it is my concern.
On the other hand, if I am consuming a different OSID Provider developed somewhere else and want to change a few things, all I can do is to front it with an OSID Provider (adapter) of my own.
Using the above diagram, here are my made up thoughts…
Metering Implementation: Someone gave that to be to help analyze my performance. It’s a separate OSID Provider and I have no idea who they are.
AuthZ Implementation: This is part of my responsibility, but I also want the flexibility of throwing it on top of someone else’s OSID Provider. I want my cake and eat it too here.
Virtual Map Cataloging: This is part of my responsibility and specific to my implementation. It was too complex to get it caught up with my other code.
Metadata Implementation: I want to be able to get this information dynamically from other OSIDs, so I separated it. This too is part of my responsibility.
Spatial Unit Calculation: This too is part of my responsibility and specific to my implementation. It was too complex to get it caught up with my other code. Perhaps other people will find it useful though.
Resource Orchestration: Since the Resource Ids have to resolve from a known place, I suppose it’s part of my implementation. But it didn’t feel right to mix it up.