Example of @Embeddable and @Embedded in Hibernate Annotation

Here is shown the JPA approach of fine-grained object model in practice. It is implemented by JPA annotations @Embeddable and @Embedded. Nice real example is shown here:
http://www.concretepage.com/hibernate/example-embeddable-embedded-hibernate-annotation

HTTP sessions - way of working

The basic premise of sessions is that only a session ID is stored on the client. On the server, that ID is associated with other "real world" information such as a user name, shopping cart etc. (This is a difference compared to using "raw" cookies to store information such as a user name on the client.) HTTP sessions typically operate is as follows:

• when a client first requests a page where we need to start a session (e.g. the "login" page), our server allocates a random session ID;
• that session ID is then communicated back to the client;
• whenever the client subsequently requests a page from our server (or relevant path from our server), it sends back the same session ID;
• on the server, we can associate information with that session ID;
• on the server, we can eventually decide that the session has "expired", and/or provide the user with a means to manually

Test Doubles - most clear definition

Test Double Type	Description
Dummy	The simplest, most primitive type of test double. Dummies contain no implementation and are mostly used when required as parameter values, but not otherwise utilized. Nulls can be considered dummies, but real dummies are derivations of interfaces or base classes without any implementation at all.
Stub	A step up from dummies, stubs are minimal implementations of interfaces or base classes. Methods returning void will typically contain no implementation at all, while methods returning values will typically return hard-coded values.
Spy	A test spy is similar to a stub, but besides giving clients an instance on which to invoke members, a spy will also record which members were invoked so that unit tests can verify that members were invoked as expected.
Fake	A fake contains more complex implementations, typically handling interactions between different members of the type it's inheriting. While not a complete production implementation, a fake may resemble a production implementation, albeit with some shortcuts.
Mock	A mock is dynamically created by a mock library (the others are typically produced by a test developer using code). The test developer never sees the actual code implementing the interface or base class, but can configure the mock to provide return values, expect particular members to be invoked, and so on. Depending on its configuration, a mock can behave like a dummy, a stub, or a spy.

Source: microsoft