Once a user has successfully registered and activated their account, they can log into oBay. This will take them to their homepage from where they can choose to start selling or bidding on items.

Once a user has successfully registered with oBay, they are ready to start selling. The first step is to create a listing for the item that they want to sell. To do this, the user will need to enter the following details about the item:

Once submitted the system will perform a number of validations on the listing, including a check that:

The final part of the validation is to check whether the item being listed meets the criteria for what constitutes an acceptable item; for example the item isn't one that is prohibited by law.

In addition oBay may also decide that certain items do not fit within the morals, beliefs, or spirit of oBay and therefore are also not acceptable; for example tickets for a charity rock concert.

Ideally the system is required to do an initial automated check on the listing to identify potential suspect items. If an item is flagged as suspect then a task will need to be created for an oBay administrator to check whether the item is suitable for sale.

Whether an item is acceptable is not always black and white. The solution will need to allow for questionable items to be submitted to a panel who will vote on whether to accept it or not (assuming there is a majority vote then the item will be deemed acceptable).

For valid non-questionable items, the system will calculate the listing fee and return this to the user, who can then confirm whether they wish to proceed with the listing or not. Upon confirmation, the item will be listed immediately, unless a start time has been specified, in which case the item will be held in a queue until the specified start time.

Listing fees are calculated according to the starting price (or reserve price if specified), as shown in the following table:

If the item is suspect, the user will be informed that the listing requires manual vetting before it can be approved for listing. Upon completion of the manual vetting, the user will be informed of the result by email. If the item has been approved, the user will be informed of the listing fee and can then choose whether to proceed with the listing.

For various reasons a user may want to cancel a listing. However, whether they are permitted to do this will depend on the listing's current status. If the auction has not yet begun, either because it is still waiting approval (due to it being flagged as a suspect item) or it is a scheduled listing, then it can be cancelled and any paid fee will be refunded.

However, if the auction has begun, then it can be cancelled up to 12 hours before the end of the auction; unless it has no bids against it. In this case, it can be cancelled any time and the listing fee will not be refunded.

The auction will end automatically after the specified duration. The user with the highest bid (subject to it meeting the reserve price if specified) will be declared the winner.

Once completed, the listing will proceed through the following steps to complete the sale:

Upon successful completion of the sale, a seller's fee, based on the final price as set out in the following table, will be charged to the seller's account.

If there are no bids or the reserve price isn't met, the auction will just finish without a winner. In this case a seller's fee will not be charged to the seller's account.

Whenever a user lists an item they will be charged a listing fee. Upon successful sale of an item, they will be charged a seller's fee, based on the actual sale price.

Each of these charges will be billed against the user's oBay account, then on a monthly basis oBay will automatically charge the user's credit card for the outstanding amount.

The first step in bidding for an item is to find something that you're interested in. oBay will provide buyers with the ability to search for items listed on oBay. The user will be able to search on a combination of Category, Sub-category, Title, and Condition.

The search will return all items that match the criteria, which will be displayed 10 items at a time.

Once a user has found an item of interest, they can view all details of it, including existing bids. They can then choose whether to place a bid.

oBay uses an auction format which lets a user bid the maximum amount they currently want to go up to. However, their bid will only be increased by a sufficient amount required to beat the current winning bid.

When the first bid is placed, it must be at least equal to the starting price set by the seller. However, regardless of the amount actually bid, the current winning bid will be equal to the starting price of the item.

After this, any future bids must be at least equal to the current winning bid plus one bidding increment, where the bidding increment is determined by the amount of the current winning bid as shown in the following table:

When a new bid is placed, oBay determines the winning bid by comparing the maximum amount of the current winning bid with the new bid; whichever is highest is determined to be the winner. However, the amount of the winning bid is determined by adding one bidding increment to the maximum amount of the losing bid.

If the calculated winning bid is greater than the maximum bid of the winning bid, then the winning bid is set equal to the maximum bid.

In the event of a tie, whoever placed the bid first is deemed to have the winning bid and the winning bid is set to their maximum bid amount.

At first glance this might sound quite complicated, so let's look at an example to clarify. If the minimum amount set by the seller is $1.00, then the winning bid would be worked out as follows:

Upon placing a bid the user will be informed if they have been successful or not and the amount of the current winning bid. If successful, the previous highest bidder will be emailed to inform them that they have been outbid.

On completion of the auction, the winning bidder will be notified by email and requested to provide shipping details and any preferences on postage. Once provided they will subsequently receive an invoice from the seller, confirming the amount to pay (that is the winning price plus shipping and packing costs) and instructions on how to pay it.

Once paid, the buyer should notify the seller that they have made the payment. Once the seller has received the payments, they will then ship the item to the buyer.

Upon receipt of the item, the buyer should then notify that they have received the item.

When we look at the various layers within a service-oriented architecture, each layer typically builds on the layer below. However, at some point we need to hit the bottom. This is the layer we have termed the Application Services Layer. The layer is typically where the core service is actually implemented, or if you like where the real work happens.

We refer to it as the application service layer since most services are typically provided by existing applications. These could be packaged applications, such as Oracle e-Business Suite, Siebel, Peoplesoft, SAP, or custom applications developed in-house using technologies such as Java, C#, Oracle Forms, PL/SQL, and so on.

Many modern day applications are web service enabled, meaning that they provide web services out of the box. For those that aren't then adapters can be used to service enable them (as we have already discussed in Chapter 3 — Service Enabling Existing Systems).

The key here is that from our perspective this is the lowest level of granularity that we can go down to, and also the actual control we have over the interface of services at this level is limited or non-existent. This tends to be the case regardless of whether or not we have control of the application that provides the service, as the actual interface provided is often a reflection of the underlying application.

It's for this reason (i.e. lack of control over the service interface) that we also include in this category native web services provided by other third parties, for example services provided by partners, suppliers, customers, and so on as well as software as a service(SaaS).

This is a relatively thin layer that provides a façade on top of the Application Services layer. The key driver here is to achieve our goal of de-coupling the services provided by the underlying applications (over which we have varying degrees of control) from any consumers of that service.

The simplest way to illustrate the criticality of this layer is to demonstrate the potential impacts of trying to bypass it, which during the pressure of a development lifecycle can be easily done (and often is).

A typical scenario is where a developer or architect will argue that it's only used in one place, and it's unlikely to change for a long time anyway, or we need to do it this way for performance reasons, and so on. And often it is the case that the FIRST time you use something it is only being used in one place. The trouble is that before long you may find it being used in many places (and often you don't always know where).

Then change happens. It may initially be a simple change, for example it may be just moving the application to a bigger box (as the amount of requests it is now processing has increased). Or the actual application itself may be changing. Maybe it's being upgraded to a new version, or maybe it's being replaced with a completely new application.

Either way the WSDL for the service is likely to change, requiring every caller of that service to be modified, tested and redeployed, and of course this needs to be coordinated across all users of that service.

This becomes even more complicated when you have multiple changes in the same time frame. You could very quickly end up with 100's of 1000's of changes to implement and coordinate. Suddenly change becomes very complicated and our systems far from agile.

As we mentioned earlier, the job of this layer is to provide a virtual service layer to decouple consumers of services from the underlying application and thus minimize the impact of change. It achieves this in two ways — first it provides a virtual endpoint for the client to call. Upon receipt of a request it then routes it to the underlying application service.

Secondly, it allows us to define an abstract description of the service, that is the operations provided by the service and its corresponding input and output messages, so that these are no longer dictated by the underlying application. This layer is then responsible for transforming an incoming input message from the format of our service contract to the one expected by the application service and vice versa for any response.

As the name suggests, this is a fairly generic term used to describe encapsulated business logic that is made available through a designed service contract. The keyword here is "designed". In particular, when it comes to exchanging data models, as each service will typically share a common data model defined in one or more XML Schemas. This is often referred to as the canonical model and is something we will look at in a lot more detail in the next chapter (Chapter 10 — Designing the Service Contract).

One of the implications of this is a virtual service, as discussed in the previous layer, which is in reality a specialized type of business service. As we will see in a moment that a business process is also a specialized type of business service. However, each of these has a specific role, and tends to gravitate towards a specific layer.

This still leaves us with a rather large category for all our remaining services, so from a design perspective it makes sense to break these down further into specific sub-categories.

There are many ways and many opinions on how exactly business services should be categorized. From a personal standpoint, we believe that there are two key perspectives to consider, the first being to look at the type of functionality contained within the service as this will guide how we may wish to implement the service.The second is to consider who is going to call or consume the service, in particular where they sit within our layered architecture as this will often drive other considerations such as granularity, security, and so on.

As we've already mentioned, you could argue that a business process is no more than just a specialized Business Service, especially when viewed through the eyes of the service consumer. However, it has a number of key differences that make it worth considering as a separate layer in its own right.

Before we look at why, lets take a step back. If we look at the traditional application architecture which splits out an application into its presentation layer, business logic and database layer, within that business logic, it is the business process that is more likely to change.

A business process is more likely to span multiple systems, which has led to the proliferation of point-to-point integration solutions, aimed at tying those bits of process together into an end-to-end business process. This can further obfuscate the business process, as a result making it more resistant to change.

Abstracting out business process into a separate layer gives us a number of advantages. Firstly, rather than having the process logic buried across multiple applications, we can now define a single end-to-end process with a far higher level of visibility and clarity than would normally be achievable. This makes it far simpler to monitor the end-to-end process, as well as to modify it in the future.

It also simplifies our underlying business services, since by extracting the business process specific logic from them, they naturally become more generic and therefore more reusable.

Another by-product is that since processes are long running in nature, whether for minutes, hours, days, months, or even years, they are inherently stateful. Thus, it often removes the need for other services to manage state, again simplifying them as well as making them more reusable.

As the top layer within our architecture, this is the layer which consumes the services provided by the Business Processes and Business Services layers. We have labelled this the User Interface layer, mainly because we are using our SOA architecture as the blueprint for building a composite application and this is the layer where the GUI (either web-based or thick client) would sit.

For the purpose of this book, we will not spend much time looking at this layer, as it falls outside the boundary of what is provided by the Oracle SOA Suite. Though for the purpose of delivering a fully working application we have provided a simple web-based user interface developed using JDeveloper.

The reality is that many users of the SOA Suite continue to develop the GUI component of an application using their technology of choice, as in most cases it dovetails very nicely with a SOA based approach.

You may have noticed, we have deliberately stayed clear of saying which parts of the Oracle SOA Suite are used for which areas within our architecture, and there is a good reason for this. Firstly, we wanted to produce a meaningful architecture that clearly demonstrated the key objectives and consideration of each layer, rather than just a piece of marketecture.

Secondly, it's not a simple one-to-one mapping, as many of the components can be used within multiple layers within the architecture and within most layers you have the luxury of choosing between multiple components. The following is a guide as to which technologies can be used where within our architecture:

Business Activity Monitoring is then used to instrument your business processes and any other relevant services, in order to provide you with a holistic view across your application.

Finally Web Services Manager is used to define, enforce, and monitor polices across your services around security, service level agreements, logging, and so on.

The Task, Identity, and Notification services are a subset of the services provided out of the box by the Oracle SOA Suite. Because we typically access these services via the Human Task activity within BPEL, it is easy to overlook their very existence.

The workflow services have documented API's, so can be invoked just like any other web service. We take advantage of these APIs to build the Order Management business service and look at how to do this as part of Chapter 15 — Workflow Patterns.

oBay makes use of a number of real world web services; we look at how to include these within our overall solution in Chapter 11 — Building Business Services.

Another key consideration when using external web services is what happens if they fail. We look at this as part of Chapter 13 — Error Handling.

As oBay is a start-up, it has rather limited applications in-house, so we are going to build most of these services from scratch. The great thing about SOA is that we can actually build these application services using whichever technology is appropriate to our organization.

To demonstrate this we've examined how these services could be implemented using a number of alternative technologies, namely Java and PL/SQL. We will cover this in detail in Chapter 11 — Building Business Services.

Effectively within oBay there are two key business processes: registering a customer and the end-to-end process of listing an item and selling it through auction. The, second of which we've split up into three sub-processes (for the purpose of reusability and agility should oBay change or extend its core business model at any point in the future).

It is also worth examining the Account Billing process; all our other processes are initiated to handle a specific request (for example, register a user, list an item for auction), while this is a scheduled process, which we will run nightly to settle the account of all users with outstanding monies. We examine how we do this in Chapter 14 — Message Interaction Patterns.